[00:51] thumper, wallyworld: for the record, using a abstract domain socket path like "@juju-mutex-" doesn't work [00:51] Bug #1610239 changed: Race in src/gopkg.in/mgo.v2

[00:51] sad trombone [00:52] wallyworld: in fact, I can't even get it to work if I patch the path prefix to "/var/snap/juju-menno/current/mutux-" [00:53] hmmmm, well that is unfortunate [00:53] looks like we do need an interface [00:53] which makes sense... I don't think the path is an issue. it might be that juju isn't being allowed to use abstract domain sockets at all [00:53] menn0: damn [00:57] wallyworld: thumper: installing with --devmode works though [00:57] yep [00:57] that will do for my immediate use [01:30] Bug #1555969 changed: API server stops responding after juju add-unit

[01:30] Bug #1449044 opened: juju add-unit resets AWS security groups

[01:41] wallyworld: looks like the snappy developer namespace is used after all [01:41] oh, right, ok [01:42] wallyworld: i've just uploaded my snap and the name in the store is now "juju-menno.menno" (where .menno is the developer namespace) [01:42] wallyworld: so including your own suffix in the name isn't really necessary [01:42] menn0: ah, did try that (juju.wallyworld) but still got a clash [01:43] i think it's all a bit in flux [01:43] wallyworld: ok fair enough... maybe there's still a global check [01:44] Am I doing something wrong or does the cs:ubuntu application have no content in status or anything? I want to know when it's gone/cleaned up [01:46] wallyworld: actually... I have no idea what's going on - I get "snap not found" when I try to install juju-menno or juju-menno.menno [01:46] wallyworld: the store website says it's there and published though [01:46] menn0: you need to use --devmode [01:46] wallyworld: I am [01:46] and --edge [01:46] sudo snap install juju-menno --edge --devmode [01:47] get rid of the dev namespace, that screwed me up as well [01:50] wallyworld: i'll ask on #snappy in case there's something i'm doing wrong [01:50] or u1-internal [01:51] ok [02:04] wallyworld: why u1-internal? [02:34] wallyworld: hey juju-mongodb2.6 is just there for upgrades, right? [02:34] wallyworld: can we lose it from yakkety? [02:35] mwhudson: yeah, and now that we wil not be upgrading from 1.25 to 2.0 directly, but via model migration, we don't even need it t all [02:35] wallyworld: this is the best kind of bugix [02:35] *bugfix [02:35] yep :-) [02:35] fixing mongo 3.2 seems not too bad [02:37] wallyworld: can you comment to this effect on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb2.6/+bug/1610778 [02:37] Bug #1610778: please remove this package from yakkety [02:38] ok [02:41] wallyworld: do we need juju-mongodb (i.e. 2.4) in yakkety? [02:41] only if we need to support juju 1.25 in yajjety [02:42] which i think we do as we have committed to 12 (or 18?) months of support [02:42] but that should be confirmed [02:49] veebers: does QA have a vsphere set up that I can test some changes with? [02:50] wallyworld: ok [03:03] axw: I'm not sure off the top of my head, let me have a look [03:05] axw: is vsphere known as anything else? [03:05] veebers: vmware vsphere? [03:05] veebers: not that I know of otherwise... [03:05] I'm not very familiar with vmware tools tho [03:06] axw: sorry the only thing close to a mention I can see is "VMware vCenter Server Appliance" [03:06] veebers: that might be it [03:06] wallyworld: do you know about vsphere? [03:06] no :-( [03:06] that was eric et al [03:09] veebers: I don't see anything about it in cloud-city, so I guess it's not part of CI at the moment... [03:09] axw I saw that mention in consoles.txt but that's all, I don't know if or how it's used. [03:10] veebers: no worries, thanks for checking [03:10] axw: sorry I couldn't be immediately helpful. I'll follow up tonight/tomorrow if we don't come across anything else [03:10] axw: would you have any insight to my previous query re: status and cs:ubuntu application? [03:11] veebers: sorry, which query was that? [03:12] axw: I'm unable to see any status re: the cs:ubuntu charm/application. i.e. I want to see if it's been removed, but I can't seem to see it when It's been deployed [03:14] veebers: don't know sorry. you didn't rename the app (juju deploy cs:ubuntu )? which user is the test logged in as when running status? [03:15] axw: (this is for the test) I do rename the application to a timestamp, but don't see it mentioned in any status. The user is the one that just successfully deployed it (not sure at the moment which it is) [03:15] I just know that if it happens quick it errors due to "the application 'ubuntu' is already deloyed" [03:17] veebers: you're definitely deploying to and running status on the same model? [03:18] veebers: if you push your branch I might spot something, otherwise I'm stabbing in the dark [03:18] axw ack, let me dig around a bit so I have answers for you. [03:48] http://reviews.vapour.ws/r/5388/ [03:48] menn0: if you feel like a break ^^^ [03:49] Bug #1595155 changed: new systemd and dbus dependencies are broken

[04:02] thumper: i'll get there soon... want to finish battling with this snap first [04:06] axw: btw I figured out what I needed to do :-) [04:07] veebers: cool [04:30] axw: talking about vsphere :) [04:30] anastasiamac: ? [04:30] axw: bug 1588390 has a question about how to specify host and datacentre.. [04:30] Bug #1588390: 2.0 beta7: can't bootstrap with vsphere cloud provider - ERROR invalid config: host: expected string, got nothing

[04:31] axw: could u comment? [04:31] anastasiamac: sure [04:31] axw: \o/ [04:32] menn0: ack [04:34] Bug #1575797 changed: AddressableContainerSetupSuite.TestContainerInitialised lxc-net: no such file or directory

[04:37] Bug #1592366 changed: Juju machines failed to die, with added storage

[04:50] wallyworld: I've just emailed you with those instructions, can you try running through them please? [04:50] ok [04:52] Bug #1592366 opened: Juju machines failed to die, with added storage

[04:56] thumper: ship it [05:02] wallyworld, axw: Re: model config tree. Does this start of a test plan make sense? Does it cover concerns? https://pastebin.canonical.com/162579/ [05:04] veebers: yes, but you really need to set up an environment with controller defaults also, using clouds.yaml [05:04] Bug #1592366 changed: Juju machines failed to die, with added storage

[05:04] veebers: as a start, I think so. we'll also want to cover controller- and region-inherited config [05:04] and you also need to check the dynamic nature of the source values [05:05] ie a value may come from "model" but if the controller default is changed to match, it will say "controller" [05:05] wallyworld, axw; good feedback. Is there any docs re: the region stuff? [05:05] only the spec [05:05] ack [05:06] https://docs.google.com/document/d/1PWUwx9kITQajQQgvHnweUuqTGmBo9p35bVwd-uLKAi4/edit?ts=57626636 [05:07] Bug #1524572 changed: Azure provider: bootstrap results in error "PUT request failed: BadRequest - XML Schema validation error in network configuration at line 24,18."

[05:15] menn0: something's wrong, after the controllers got set up (looking at watch and running the setup script), there's no juju home created under ~/snap/juju-menno and the controllers can't be found [05:19] veebers: do you know which, if any, of the QA MAASes I can use to test a bootstrap change? [05:20] axw: I should but I don't sorry :-\ that's 0-2 for today [05:20] veebers: no worries :) [05:21] axw: I see "munna-maas-slave (A machine capable of running kvm, and maas 1.9)" in the agent configs, but that's as much as I can tell from there [05:21] veebers: yeah just don't want to step on anyone's toes [05:23] axw: I've given myself 2 action points to sort out for tomorrow (vsphere and maas). I'll add that to the information that I intend to add to the wiki etc. [05:23] veebers: thanks :) [05:29] wallyworld: hmmmm... works for me... are you running juju-menno.juju instead of plain old juju? [05:29] menn0: i tried juju as well [05:29] but how could plain juju work? [05:30] the snap doesn't write to ~/.local/share/juju [05:31] wallyworld: indeed. I was making sure you *weren't* running juju [05:31] menn0: right [05:31] wallyworld: I'm just running through the instructions again. [05:31] the email says "juju", but i did use /snap/bin/juju-menno.juju [05:32] wallyworld: so the boostrap starts? [05:32] yeah, and the watch output is fine. then when I ^C once everything is started, there's nothing there [05:33] well, there's a ssh file but no controller.yaml [05:33] ssh directory [05:33] i'll try again [05:33] I get all the usual stuff in ./juju-menno/2/snap/juju-menno/2/.local/share/juju [05:34] yeah, all i got was an ssh directory [05:34] wtf [05:35] menn0: there's an extra level of directories [05:35] ls ~/snap/juju-menno/2/snap/juju-menno/2/.local/share/juju/ [05:35] that has all the stuff in it [05:36] wallyworld: yep, that's where everything is [05:36] when i run juju from snap, everything is in ~/snap/juju-wallyworld/2/.local/share/juju [05:36] yours has an extra bit of the path duplicated [05:37] and in ~/snap/juju-menno/2/.local/share/juju i have just an ssh dir [05:37] maybe it's a race or something starting 2 controllers at the same time? [05:38] I wonder if it's because the setup script is in the snap and is running another thing in the snap [05:39] I might just distribute the script separately if that's the case [05:39] mwhudson: the bug 1570650 u commented on deals specifically with 2.6 for 1.25 on xenial... could u please clarifywhy you think that yakkety approach is inconsistent with this bug? [05:39] Bug #1570650: Use juju-mongodb2.6 for 1.25 on xenial

[05:40] wallyworld: I've got to stop for now but I'll play around with it some more later on [05:40] wallyworld: thanks for trying it out [05:41] menn0: no worries, i'll try again later if i can, try starting one controller at a time [05:42] anastasiamac: 1.25 is only getting critical fixes. i doubt upgrading mongo is a critical fix, but i could be wrong [05:42] and i think 1.25 support is xenial or trusty only, but again, i could be wrong [05:44] wallyworld: i completely agree. did u read the bug? [05:45] i did, may have misunderstood it. it seems to be asking for cganges to 1.25 to support mongo 2.6 [05:46] wallyworld: so if this fix goes into 1.25 is yet to b decided by leads. my question ws with respect to michael's commnet about yakkety :) [05:48] wallyworld: m not sure how this relates to whther we r going to suport mongo2.6 on 1.25 on xenial and wanted to clarify in case I missed something: "Ian just told me that it would be safe to remove juju-mongodb2.6 from [05:48] yakkety, which seems inconsistent with this." [05:48] ok. i very much doubt we'll be expending effort on mongo 2.6 in 1.25,unless people have changed their minds or we get a bunch of new resources [05:48] wallyworld: this decision is not related to my question [05:50] yeah, i'm a bit confused by the "inconsistent" bit [05:50] wallyworld: the bug is about xenial. why are mentioing yakkety here? [05:50] don't know [05:50] wallyworld: k. i'll ask Michael tomorrow ;0 NZ must be coming offline \o/ [05:56] wallyworld: There is support for --upload-tools within juju-ci-tools, the abrupt removal of it would trip up some tests. [05:56] veebers: yeah, i grepped the source just before, i'll add an alias [05:56] thanks for looking, doesn't look like there's too much to change, but it will take some time [05:56] wallyworld: ah sorry had meant to get back to you earlier. You intend to fully remove it at some poitn? [05:57] no, not much to change, but might need some mechanism to make it backwards compat. [05:57] yeah, once everyone agrees, right now it's a spike [05:57] we have a mechanism for 1.25 vs 2.0 tests i think [05:58] wallyworld: Ah ok. If you could ping the qa list closer to the time to warn of intentions (i.e. we intend to remove/rename/revamp upload-tools arg within x time) [05:58] veebers: on my list - en email will be going to a wider audience than just qa [05:58] yeah there is (also, every beta revision release too) [05:59] wallyworld: awesome, thanks. [06:20] axw, wallyworld: what requirements (config, cloud etc.) is required to get the regional config tree options? i.e. the apt-mirror example in the spec: [06:20] Attribute Default Controller [06:20] apt-mirror: archive.ubuntu.com - [06:20] aws/us-east-1: us-east-1.aws.ubuntu.com - [06:21] veebers: I don't think it's implemented yet -- right wallyworld? [06:22] veebers: yeah, the initial work is still pending: http://reviews.vapour.ws/r/5339/ [06:22] veebers: yep, still wip [06:22] only the controller inherited config is done [06:22] ah ok, I'll ask that question at a later date then :-) [06:22] veebers: what's done is documented in the release notes, as is what is still todo [06:23] Ok, I'm just trying to figure out the clouds.yaml and how it can be used in a test [06:23] release notes contain that info too [06:24] are latest release notes always found here: https://jujucharms.com/docs/devel/temp-release-notes [06:27] hmm, nvm. I see that it is [06:35] wallyworld: Cool, the release notes pretty much outline a test where having a controller default, setting it to a model value then unsetting should revert back to the controller value (not the default) [06:37] veebers: yep, but there's then additional nuances. eg change a controller value to be the same/different to a model value and see the source get updated each time model-config is run; create new models with different varioations of config etc [06:37] Bug # changed: 1402696, 1568181, 1568185, 1568190 [06:39] wallyworld: how does one change a controller value after a bootstrap? Or is it always read from clouds.yaml? [06:39] juju set-model-default [06:40] that sets a controller default? or am I getting confused [06:40] also juju unset-model-default [06:40] there is base default config, model config and controller config right? [06:40] it sets the default value for a model attribute, which just happens to be a controller wide default [06:41] it will grow the ability to set a region default also when that bit is done [06:41] juju set-model-default --region=us-east-1 http-proxy=foo [06:41] or something liek that [06:41] ah ok. [06:42] I'll update that testplan I shared earlier and bother you again about it tomorrow :-) [06:42] there's current 3 sources of model config: default, controller, model [06:42] it will soon be 4 [06:42] the order goes: default, controller, region, model === frankban|afk is now known as frankban [07:07] Bug #1605770 changed: firewallerSuite.TearDownTest inst.Dial() failed

[07:07] Bug #1610260 changed: AWS Error fetching security groups EOF/timeout

[08:01] Bug #1610880 opened: Downloading container templates fails in manual environment [09:02] fwereade__: hey, do you think upgrading from e.g. 2.0-beta14.1 to 2.0-beta14 should be allowed? [09:03] fwereade__: currently the upgrader does not compare patch or build numbers when deciding to upgrade (or downgrade, which is more puzzling - see allowedTargetVersion's doc comment in worker/upgrader/upgrader.go [09:05] fwereade__: i.e. I was wondering if there's a good reason not to just compare versions with version.Number.Compare() in the upgrader [09:06] dimitern, thinking... but *mainly* thinking that if we're not supporting upgrades during beta it's somewhat moot [09:07] fwereade__, dimitern: take another look at http://reviews.vapour.ws/r/5365? [09:07] fwereade__: the issue I'm trying to fix is outlined in bug 1607749 [09:07] Bug #1607749: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too)

[09:07] babbageclunk: will do in a bit [09:08] fwereade__: weird case I agree, but it did still expose that wrinkle of the upgrading logic [09:08] fwereade__: bootstrapping with --upload-tools from a released client binary triggers it [09:10] dimitern, so I *think* what triggers it is just having a mismatch between the tools we bootstrap with and the tools we record ourselves as having bootstrapped with, right? [09:11] dimitern, and so I guess --upload-tools from a released client will do that? but instant-upgrade-on-bootstrap is something we haven't done for years [09:12] fwereade__: I think it's the difference between version.Current and having FORCE-VERSION [09:12] even though --upgrade-tools adds the latter to fake it's .1, the binary version is still sans that .1 [09:12] dimitern, well, maybe, but why aren't we recording the same tools version that we're eploying? [09:14] dimitern, where does it think the binary version doesn't have the .1? it looks to me like the version we recorded in state doesn't have the .1 [09:14] fwereade__: I don't know yet - still digging, but ISTM not considering versions with different patch and build number equal in the upgrader will fix the symptom [09:15] dimitern, am super-confused: ISTM that the upgrader *is* quite reasonably and correctly considering the versions to be different [09:15] fwereade__: and there's bootstrap --auto-upgrade as well (false by default), totally not taken into account AFAICS [09:16] fwereade__: well: INFO juju.worker.upgrader upgrader.go:199 upgrade requested from 2.0-beta12.1 to 2.0-beta12 - doesn't that look weird to you? [09:16] dimitern, looks like it's doing exactly the right thing [09:17] dimitern, saw local version, server said it should run a different version, trying to do that [09:17] dimitern, the problem there is the server asking us to change in the first place [09:17] fwereade__: ok, then I'll keep digging - wanted to confirm that's the correct behavior in the upgrader [09:19] dimitern, fwiw, don't have a strong position on --auto-upgrade -- if we make sure we have the proxy settings inited from agent config, I don't see why that wouldn't work [09:19] fwereade__: I've verified the proxy settings are populated (into ~/.juju-proxy) on agents [09:21] dimitern, ok... does that mean that the agent always uses them? [09:22] fwereade__: that's what I'm trying to figure out now :) [09:22] dimitern: fwereade__: in beta14, there was a fix for --upload-tools and build version mismatches... seee https://bugs.launchpad.net/juju-core/+bug/1605050 [09:22] dimitern, I don't see why it would [09:22] Bug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools

[09:22] fwereade__: btw the origAgentVersion in the upgrader comes as PreviousAgentVersion, via agentconfig.UpgradedToVersion() [09:23] anastasiamac: cheers - i'll look there as well [09:23] dimitern: \o/ [09:23] anastasiamac: I see you've been on fire closing 1.25 bugs :) [09:23] not closing....just brooming the house a bit.. [09:23] :) [09:25] anastasiamac: ;) nice to see the count going down though! [09:30] dimitern, AFAICS the heart of the problem is that the *server* is asking us to upgrade [09:30] dimitern, it looks like we have the right binary and the right config on the agent [09:31] fwereade__: I think anastasiamac nailed it - the discrepancy seems to be fixed with tim's PR https://github.com/juju/juju/pull/5879/files [09:31] to confirm that I'll try the same scenario, but with the next beta [09:32] dimitern, sweet [09:41] \o/ [09:42] fwereade__, anastasiamac: it works in beta14, so indeed a dup of bug 1605050! thanks for the help ;) [09:42] Bug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools

[09:42] dimitern: :) m glad! [09:45] win 17 [09:45] bah [09:53] Bug #1607749 changed: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too)

[09:53] sorry babbageclunk I'm on to your PR now [09:54] dimitern: thanks, no worries [09:56] fwereade: reviews done [10:03] menn0, tyvm [10:08] menn0, re unit tests -- I'm basically seeing this as a pure internal refactor that doesn't really want new tests because it doesn't change behaviour [10:09] menn0, what tests would you write that aren't just this-input-produces-this-output, who-knows-what-it-means-or-does? [10:09] fwereade: ok fair enough. [10:09] fwereade: some of those methods /are/ conditional ... but I see your point [10:11] menn0, restate conditional please? [10:12] fwereade: sorry, they have conditional logic which could perhaps warrant a test [10:12] fwereade: doing different things depending on what's in the DB [10:13] menn0, yeah [10:13] menn0, how about if I do a pass for the externally-visible impact of same and make sure we have suitable hooks tests? [10:14] fwereade: sgtm [10:14] menn0, cheers [10:31] babbageclunk: reviewed [10:31] dimitern: Thanks! [11:17] morning [11:24] rick_h_: \o/ [11:29] Bug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> [11:35] Bug #1598390 opened: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> [11:38] Bug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> [11:54] babbageclunk, dimitern: sorry, I had a couple of comments on the review but I didn't hit post [12:25] fwereade: cool, thanks === petevg_vacation is now known as petevg [13:06] macgreagoir: welcome back, good week? [13:07] rick_h_: It was, thanks. Week of sun! [13:07] macgreagoir: added some small "get back in the flow of things" bugs your way on the kanban board [13:07] macgreagoir: please take a look when you're through email and looking for next task [13:08] rick_h_: Noted :-) I have been trying to catch up. [13:08] macgreagoir: all good, wheeeee [14:00] natefinch: katco macgreagoir dimitern ping for standup [14:01] omw [14:15] hmm, git blame is becoming less useful. What is "Juju bot" doing as an author in apiserver/network.go ? [14:24] katco: <3 I went to create a tracking card and it yelled at me that the id already existed [14:25] dimitern: if can you please look at http://reviews.vapour.ws/r/4684/ and see if it still applies and if so work to get it landed? [14:26] rick_h_: sure, added to my list [14:26] ty dimitern [14:27] rick_h_: np [14:29] fwereade: and added the one you were reviewing from eric into the review land if you can peek at that please and see if it still applies at all. [14:48] fwereade: ping [14:51] Bug #1610990 opened: list-storage in aws contains non-created items

[14:51] Bug #1610993 opened: UnitSuite.TestWorkers timed out waiting for workers

=== natefinch is now known as natefinch-afk [15:43] rick_h_: a side effect of allowing a maas server url without a prefix (so that the port can be specified unambiguously) [15:43] rick_h_: is that it's basically impossible to detect invalid maas server urls until we try to use them [15:44] rick_h_: I think the failure error is still clear enough, it's just a bit later [15:44] rick_h_: (for invalid urls we now add http:// prefix automatically - and according to url.Parse that makes anything a potentially valid url) [15:45] just noting it === frankban is now known as frankban|afk [15:49] voidspace: yea, with the add-cloud work I think our goal is to ping and reach the server to validate it's real and there [15:49]