[00:02] Bug #1563117 opened: api: data race adding local charm. [00:14] Bug #1563117 changed: api: data race adding local charm. [00:17] Bug #1563117 opened: api: data race adding local charm. === axw_ is now known as axw [01:55] is it just me, or is reviewboard broken? [01:55] I'm not actually getting any diffs, just spinners that spin forever [01:57] Bug #1558769 changed: unable to create-model in azure

[01:57] hmm, no, maybe it's just the two specific reviews I was looking at. Weird. [01:58] natefinch: not just you [01:59] axw: ok, cool [01:59] natefinch: I got some errors about it being out of space [01:59] ahh [01:59] looks like /tmp is full [01:59] that would explain why some work and some don't, if some got cached or somethnig [03:30] Bug #1545589 changed: Destroying a model leaves stale current-model file

[03:46] thumper: https://bugs.launchpad.net/juju-core/+bug/1534627 -- what's expected here? I vaguely recall Jess saying that models hang around after being "destroyed", and aren't actually removed from the DB until some time later [03:46] Bug #1534627: Destroyed models still show up in list-models

[03:47] axw: yes, the actual docs stay around so they can be queries, retrieved [03:47] axw: we should either show the model as dead [03:47] or not show it by default [03:47] I think by default we should just show alive models [03:47] thumper: why do we do that? we don't do it for anything else [03:48] axw: because models are special, and it is handy to be able to watch them die [03:48] post mortemts etc [03:48] list models in apiserver should provide life or skip non-alive [03:49] okey dokey [03:49] thumper: and if someone tries to create a model with the same name? [03:50] I wonder if we shouldn't disassociate the name when it's destroyed, so you can still reuse the name [03:50] IIRC we were going to have dead ones possibly renamed or only look for alive ones... [03:50] it is expected that you should be able to reuse the name [03:50] somehow [03:50] ok [04:18] Bug #1538652 changed: MAAS doesn't assign DHCP IP to new Node and doesn't update DNS table

[04:51] https://bugs.launchpad.net/juju-core/+bug/1561375 [04:51] Bug #1561375: state: TestRegisterNoSecretKey unreliable [04:51] booo [04:51] this is an upsream break [04:51] go 1.6 is fine [04:52] i'll log a bug upstream and let them deal with it [05:23] could I get a trivial review from someone? https://github.com/juju/juju/pull/4906 [05:31] no bot ? [05:31] LGTM [09:32] morning o/ [09:37] fwereade_: space discovery... I was just trying to understand where this ended up in terms of when it was blocked... and not. I was running some git bisect script which added a container after bootstrap but my script often barfed because "spaces discovery is still in progress". [09:47] frobware, oops, sorry: how can I help? [09:48] frobware, I'm not sure what the current state of master -- I presume it's doesn't-block-logins-reliably? -- but MADE-model-workers doesn't try to block logins at all [09:49] frobware, and I haven't seen a merge conflict that looked related [09:51] frobware, IIRC that was where we left it when I hit it last time; I'm not opposed to login-blocking in itself, but if it doesn't actually block all problematic logins it's kinda pointless [09:53] Gah, any way to see chat messages from a hangout after one has left the hangout? :( I mean, I can remember --upload-tools but it seemed like there was probably other useful info in there. [09:55] fwereade_: can we briefly HO to talk about it? [10:01] frobware, sure, back in standup? [10:01] fwereade_: yep [10:26] Sweet, bootstrapped (although I got a warning about "space discovery still in progress" as well). [10:39] voidspace: trying to deploy juju-gui to my cloud, I get this: ERROR storing charm for URL "cs:trusty/juju-gui-52": cannot retrieve charm "cs:trusty/juju-gui-52": cannot get archive: Get https://api.jujucharms.com/charmstore/v5/trusty/juju-gui-52/archive: dial tcp: lookup api.jujucharms.com on 192.168.100.2:53: no such host [10:41] I can get that url on the maas controller (which is 192.168.100.2). I haven't been able to ssh into the juju controller (which is .17) - should I be able to? [10:41] Ooh, just trying juju ssh. [10:41] No, that didn't work. [10:44] I was specifying the node wrong. I'm in - seeing if I can get the file from there. [10:51] babbageclunk: yep, that's the thing to try [10:52] babbageclunk: I'm *still* trying to get maas 2 working on this VM after it broke [10:52] babbageclunk: a full remove kept failing, think I got it now and am re-installing [10:52] babbageclunk: if not I'll just blow away the VM and start again [10:52] babbageclunk: if this was automated it would be easier :-) [10:54] voidspace: Ok, so it looks like the problem is that 192.168.17 (the juju node) has its nameserver set to .2 (the maas controller), while the maas controller (where the charm store request succeeds) has .1 as the nameserver. [10:54] babbageclunk: how weird [10:54] babbageclunk: that's set by maas in cloud-init I think [10:54] babbageclunk: this is on 1.9 [10:54] voidspace: yes [10:54] frobware: ^^^^ is this something you've seen? [10:58] voidspace, frobware: maybe it's the fact that the cluster interface in the MAAS admin is set to be "DHCP and DNS"? Is that wrong? [11:01] babbageclunk: no, that's correct [11:02] babbageclunk: you could try just dhcp and see if that makes a different - I normally do both I think [11:04] fwereade_: http://rr-project.org/ [11:05] voidspace: ok. Best way to bounce a machine in juju? [11:06] voidspace: should I just restart it from the maas ui? [11:06] babbageclunk: try "juju reboot 1" [11:06] babbageclunk: I'm kind of guessing [11:06] babbageclunk: I normally bounce it in virt-manager [11:06] voidspace: doh, missed that in the list. [11:06] I knew we had a reboot command - for charms, wasn't 100% it was in the CLI [11:07] manually restarting the machine restarts the machine agent anyway, so that's what I do [11:08] voidspace: I went semi-scorched earth and did a destroy then bootstrap again. [11:10] babbageclunk, voidspace: I have a feeling that there's a bad interaction with juju-reboot, so I don't think you can juju run that, but you should be able to do something like `juju run --machine 2 "sudo shutdown -r now"` [11:10] babbageclunk, voidspace: hooks/actions can request reboots with juju-reboot though [11:12] fwereade_: ah, thanks [11:12] voidspace, fwereade_: despite being overkill, watching the bootstrap process again is giving me a bit better feel for what's happening (and which moving part is responsible for it), so it wasn't a complete loss. [11:13] babbageclunk, cool :) [11:13] babbageclunk, and ofc you could just `juju ssh 1` and do whatever you need there [11:14] fwereade_: cool, thanks [11:14] babbageclunk, (and that should work even if the agent's having trouble, which can stymie juju run) [11:20] hah, so MAAS was dying with internal server error [11:20] spelunking in the logs found that going to the accounts page causes the web ui to attempt to shell out to bzr - which wasn't installed [11:20] how odd [11:22] babbageclunk: the "changing maas to not do dhcp over the whole subnet" may be new in a more up to date version of maas 2 [11:22] babbageclunk: I'm using the experimental3 ppa and when I configured dhcp I have to provide the range (which defaults to the whole subnet) which I didn't have to do previously [11:23] babbageclunk: and I guess if it provides dhcp over the whole range then it has no static ips available [11:25] voidspace: OK, so why can't my juju controller get to api.jujucharms.com? Is having the nameserver be the maas controller right? [11:25] babbageclunk: that should be correct I believe [11:25] frobware: ^^^ [11:26] babbageclunk: I have maas 2 running (finally I think - just trying enlisting) so can't check on 1.9 [11:26] just yet anyway [11:31] voidspace, frobware: so presumably the problem is that the DNS server on the maas controller isn't responding correctly. I can see dnsmasq running on the maas controller. [11:32] babbageclunk: it's not a problem I've had though [11:32] babbageclunk: what if you try without maas providing dns [11:32] babbageclunk: can you deploy a node? If so, can you login to that node and resolve news.bbc.co.uk? [11:33] frobware: he can deploy, but he then can't connect to the outside world [11:33] I believe [11:33] voidspace, babbageclunk: where connect is just DNS? [11:33] voidspace, frobware: that's right [11:34] babbageclunk: what do you have in your MAAS setup for upstream DNS queries? [11:34] babbageclunk: from the UI, choose "Settings", then part way down that page is ... [11:34] frobware: checking now [11:34] babbageclunk: "Upstream DNS used to resolve domains not managed by this MAAS (space-separated IP addresses)" [11:35] babbageclunk: I have 192.168.1.1 (which is may gateway. You could add 8.8.8.8 [11:35] frobware: Aha - I've never seen that page before! [11:35] frobware: I'll add the gateway there. [11:35] frobware: (Also I'll add it to my setup notes.) [11:36] babbageclunk: it's not a gateway though (assuming we're talking about the same thing) [11:37] frobware: Sorry - sloppy terminology on my part. I think I mean it's the KVM switch? It's what's in the resolv.conf on the maas controller (where the name resolves fine). [11:38] babbageclunk: so presumably .1 [11:38] frobware: that's right [11:45] babbageclunk: any joy? [11:46] frobware: yes! juju-gui is deployed, but the service's still showing status: unknown when I do juju status. [11:47] frobware: If I ssh into the node I can see runserver.py running which seems to point to the gui charm [11:48] But if I click through the HTTPS warnings I can get to the gui" [11:49] Sweet, I'm in! [11:50] great [11:56] So I think everything's working, other than the "unknown" status in the cli (which isn't reflected in the gui). Probably I won't worry about that. [12:06] babbageclunk: yay [12:06] babbageclunk: I'm going on lunch [12:06] school holidays, so no school run for the next two weeks [12:13] voidspace: cool cool, I'm going for a run to celebrate. [13:19] voidspace, babbageclunk: are you guys using " maas | 2.0.0~alpha3+bzr4810-0ubuntu1 | http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages [13:19] " [13:23] voidspace, babbageclunk: I see there's an alpha4 in ppa:maas/next [13:27] fwereade_: with https://github.com/juju/juju/compare/1.25...dooferlad:1.25-proxy-state-server-bug?expand=1 I am getting API authentication errors. I assume I am missing something else that I should know, but don't. Do you have time to help? [13:31] dooferlad, looking [13:33] dooferlad, AuthClient means "is this a user". would probably be a good idea if we did s/Client/User/ across most of apiserver [13:34] dooferlad, I think you want auth.AuthMachineAgent() || auth.AuthUnitAgent() [13:35] fwereade_: thanks. Will give that a go. [13:37] frobware: yup, that's the version I'm running - sorry, had to spin up my 2.0 kvm to check [13:38] fwereade_: yeah, our use of "Client" in the codebase is quite confusing at times [13:38] frobware: do you think I should upgrade? [13:38] fwereade_: we have the Client API and then a client for the Client API, but also a client for the non-Client API [13:39] babbageclunk: I was trying to reach your feature parity. [13:39] babbageclunk: ... and I'm not there yet. Hmpf. [13:42] natefinch, really? which is the, uh, non-client client? [13:44] fwereade_: well, everything under api/ is a client wrapper for a facade [13:45] fwereade_: where client in this context just means "consumer of the API", as in, client-server [13:45] fwereade_: I guess mostly I find it confusing that we have an API facade called "Client" [13:46] fwereade_: and then there's api/Client, which is the client wrapper for the Client facade [13:47] natefinch, right, got you [13:47] natefinch, if we didn't overload Client it would all make much more sense [13:48] fwereade_: indeed. Was just thinking about it with your talk of switching client to user, which makes a lot more sense... the Client facade is really the user-facing facade, and the rest are the juju-facing facades [13:49] frobware: I've been using both next-proposed and experimental3 ppas [13:50] voidspace: going to try next-proposed [13:51] voidspace: I had problems with creating the admin account. not sure if that was just finger trouble. [13:51] frobware: heh [13:51] I would expect to [13:51] or it's another new bug [13:52] voidspace: like I said to babbageclunk, I wanted to get to your state-of-the-maas2-world. [13:52] frobware: ok [13:53] voidspace: I'd like to try this installation using LXD, but that may be adding yet more entropy... [14:00] natefinch, although really, the single monolithic Client facade is itself silly -- we probably ought to just explicitly separate internal/ from external/ [14:01] fwereade_: yeah, definitely. maybe call them private vs public. Private is just for juju, public is for anyone who wants to write a client [14:01] fwereade_: of course, if we call something a public API, we'd have to document it ;) [14:03] natefinch, that would... not be a bad thing ;) [14:12] frobware: oops, didn't reply [14:13] frobware: we're definitely *not* targetting container support in the first cut of MAAS 2.0 support [14:16] voidspace: ahh. I meant my MAAS 2.0 installation which was using LXD vs a VM. [14:17] Bug #1563335 opened: creating hosted model: could not create state for new model: cannot create index: read tcp 127.0.0.1:37017: i/o timeout

[14:17] frobware: you mean MAAS 2 *in* LXD? [14:17] voidspace: yep. [14:17] instead of KVM [14:17] voidspace: correct [14:17] frobware: ah cool [14:17] would be lighter weight than KVM [14:17] that's for sure [14:18] frobware: I had to blow away both MAAS 2 installs [14:18] frobware: I have it reinstalled in a fresh VM and am just updating that box [14:18] frobware: I've also looked over Tim's code - it's pretty threadbare but it's a start [14:19] frobware: as I said in my email I don't really understand what he means by his schema versioning stuff and I'm not convinced we need it anyway [14:37] voidspace: to look at Tim's fork of gomaasapi, should I just git clone it, or use go get? [14:40] babbageclunk: if you already have gomaasapi in your GOPATH, just git remote add Tim's fork and checkout his branch. if you don't have gomaasapi yet, go-get it first [14:40] natefinch: great, that makes sense. Thanks! [14:41] babbageclunk: welcome. It takes a little bit to understand the way to combine real-world git environments and go, but once you get it, it's not too hard. [14:42] Yeah, that was what I was fumbling with. [14:43] babbageclunk: go get is more for end-users than developers, per se. it's useful for setting up the right paths in your GOPATH for all the dependencies, but then to actually develop, you use the backing VCS to twiddle with what branches you're looking at. Helps a ton to have the git branch in your prompt, btw. [14:44] babbageclunk: clone [14:44] babbageclunk: or https://github.com/juju/gomaasapi/compare/master...howbazaar:controller-interface [14:44] babbageclunk: above link if you just want to see the differences [14:44] babbageclunk: actually - I fork then pull rather than clone [14:44] natefinch: Awesome, thanks [14:45] voidspace: Yeah, that makes sense too, given that I'm expecting to do work on it, [14:45] babbageclunk: what I actually do is fork gomaasapi, add howbazaar as a remote [14:45] babbageclunk: and then I can checkout his branch or merge it into mine [14:45] yeah, forking the original, then git remote add your fork to $GOPATH/github.com/juju/gomaasapi [14:46] er $GOPATH/src of course [14:46] voidspace, babbageclunk: so this time (alpha3) I managed to get into a state where I have no cluster to edit... Hmpf. [14:47] frobware: cool [14:47] I'm running alpha3 too [14:49] enlisted a node, now attempting to commission [14:49] looks like it's working rather than trying to enlist again (the old bug) [14:50] Bug #1563364 opened: UniterSuite.TestUniterSteadyStateUpgradeForce fails

[14:50] hmmm... not proven yet - it seems to have stalled [14:51] nope, done [14:51] *great* [14:51] * babbageclunk highfives voidspace [14:51] hah :-) [14:51] o/ [14:51] o/\o [14:55] voidspace: sorry to leave you hanging! Should have been watching more closely. [14:55] hah [14:55] no worries [14:55] next time [15:05] Bug #1563364 changed: UniterSuite.TestUniterSteadyStateUpgradeForce fails

[15:08] Bug #1563364 opened: UniterSuite.TestUniterSteadyStateUpgradeForce fails

[15:08] Bug #1563373 opened: bootstrap connection timed out

[15:08] Bug #1563380 opened: addresses for [] not found

[15:17] Bug #1563373 changed: bootstrap connection timed out

[15:17] Bug #1563380 changed: addresses for [] not found

[15:20] Bug #1563373 opened: bootstrap connection timed out

[15:20] Bug #1563380 opened: addresses for [] not found

[15:20] Bug #1563384 opened: could not exit restoring status: connection refused

[15:26] voidspace: did the drop-1.8 branch eventually happen? [15:33] frobware: nope, need(ed?) a blessed master to get a blessed run on drop-1.8 [15:34] still no bless on master [15:34] natefinch: ericsnow: hey, we can move the standup earlier for the next few weeks. what time works for you two? [15:35] Bug #1563384 changed: could not exit restoring status: connection refused

[15:35] katco: whenever (FWIW, I liked having it at the start of my day [15:35] ) [15:36] ericsnow: is the old time ok? [15:37] katco: we could do it an hour later...that way ericsnow doesn't have to start at 8 if he doesn't want to [15:37] natefinch: ericsnow: completely up to him [15:37] katco: I'm fine either way [15:38] ericsnow: natefinch: old time it is :) [15:38] ericsnow: natefinch: do you two mind if we do a quick standup now to catch me up? [15:38] Bug #1563384 opened: could not exit restoring status: connection refused

[15:38] katco: sounds good [15:38] katco: sure, I was going to suggest that, actually [15:50] Bug #1563400 opened: TestOneWorkerStartWhenStopping fails

[16:11] Bug #1563418 opened: TestModelDestroy fails

[16:23] gah, somehow github reviews got set to wrapping at 60 characters on my screen... no idea how to fix it, but it goes away if I use incognito :/ [16:23] ahh... it was the sourcegraph plugin... [16:31] voidspace: I'm reading through your and Tim's changes to gomaasapi, trying to understand what's going on there and trying to see how that would be used in the juju maas provider. [16:31] voidspace, babbageclunk: I can enlist, commission and deploy with alpha3 MAAS 2.0 [16:32] voidspace: also trying to match that up with the MAAS api docs so I can get a feel for it. Any other things I should be looking at? [16:48] ericsnow: ping [16:48] katco: pong [16:49] ericsnow: when you reach a stopping point, would you mind swinging onto 1560201 ? [16:49] bug 1560201 [16:49] Bug #1560201: The Client.WatchAll API command never responds when the model has no machines

[16:49] katco: k [16:50] ericsnow: ty... critical priority =/ === Spads_ is now known as Spads === meetingology` is now known as meetingology [17:11] Bug #1502158 changed: When HP DNS/service calls fail, juju could retry

=== hazmat_ is now known as hazmat [17:42] Bug #1184457 changed: Stores user configuration outside of $XDG_CONFIG_HOME

[18:19] hello, I wanted to do a quick sanity check for the Xenial archive in relation to juju. [18:19] As of today I see 3 juju packages, juju-core, juju, and juju2 [18:20] juju-core and juju both are pointing at 1.25.0-0ubuntu3, and juju2 pointing at 2.0-beta3-0ubuntu1~16.04.2~juju1 [18:21] at least on the s390 arch, thus for folks looking to install juju 2.0 on s390x in Xenial I am going to recommending to "sudo apt-get install juju2" [18:22] will this instruction change to "sudo apt-get install juju" for the 16.04 release? [18:22] sinzui: ^ ? [18:26] arosales: IIRC, 1.25 will stick with juju-core and 2.x will be juju... but I'm far from an authority on it. [18:26] arosales: sinzui is definitely an authority on this. alexisb may also have some answers [18:26] natefinch: ok, and sounds like juju2 may just point at juju [18:27] that make sense [18:27] katco: ack [18:27] arosales: that's my understanding [18:27] natefinch: ok, I'll run with that for now. [18:27] thanks katco and natefinch [18:29] arosales: we're working with the folks on this currently [18:29] arosales: juju will be the package everyone is to use and apt-get install to get juju [18:30] arosales: the others will be tweaked to point in ways to make sure the upgrade/etc works properly [18:32] rick_h_: and that the plan for 16.04 I take it, but today if folks want juju 2.0 from the archive they need to apt-get install juju2 [18:33] arosales: right, so your question is "will apt-get install juju2 move to apt-get install juju" and the answer is yes [18:34] rick_h_: ok thanks [18:54] Bug #1528932 changed: No images error when deploying services <2.0-count>

[18:54] Bug #1531878 changed: TestBootstrapImage fails on i386 and ppc64el <2.0-count>

[19:03]