menn0thumper, wallyworld: for the record, using a abstract domain socket path like "@juju-mutex-" doesn't work00:51
mupBug #1610239 changed: Race in src/gopkg.in/mgo.v2 <ci> <intermittent-failure> <race-condition> <regression> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1610239>00:51
wallyworldsad trombone00:51
menn0wallyworld: in fact, I can't even get it to work if I patch the path prefix to "/var/snap/juju-menno/current/mutux-"00:52
wallyworldhmmmm, well that is unfortunate00:53
wallyworldlooks like we do need an interface00:53
menn0which 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 all00:53
thumpermenn0: damn00:53
menn0wallyworld: thumper: installing with --devmode works though00:57
menn0that will do for my immediate use00:57
mupBug #1555969 changed: API server stops responding after juju add-unit <canonical-is> <juju-core:Won't Fix> <https://launchpad.net/bugs/1555969>01:30
mupBug #1449044 opened: juju add-unit resets AWS security groups <add-unit> <ec2-provider> <security> <juju-core:New> <https://launchpad.net/bugs/1449044>01:30
menn0wallyworld: looks like the snappy developer namespace is used after all01:41
wallyworldoh, right, ok01:41
menn0wallyworld: 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
menn0wallyworld: so including your own suffix in the name isn't really necessary01:42
wallyworldmenn0: ah, did try that (juju.wallyworld) but still got a clash01:42
wallyworldi think it's all a bit in flux01:43
menn0wallyworld: ok fair enough... maybe there's still a global check01:43
veebersAm 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 up01:44
menn0wallyworld: actually... I have no idea what's going on - I get "snap not found" when I try to install juju-menno or juju-menno.menno01:46
menn0wallyworld: the store website says it's there and published though01:46
wallyworldmenn0: you need to use --devmode01:46
menn0wallyworld: I am01:46
wallyworldand --edge01:46
menn0sudo snap install juju-menno --edge --devmode01:46
wallyworldget rid of the dev namespace, that screwed me up as well01:47
menn0wallyworld: i'll ask on #snappy in case there's something i'm doing wrong01:50
wallyworldor u1-internal01:50
menn0wallyworld: why u1-internal?02:04
mwhudsonwallyworld: hey juju-mongodb2.6 is just there for upgrades, right?02:34
mwhudsonwallyworld: can we lose it from yakkety?02:34
wallyworldmwhudson: 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 all02:35
mwhudsonwallyworld: this is the best kind of bugix02:35
wallyworldyep :-)02:35
mwhudsonfixing mongo 3.2 seems not too bad02:35
mwhudsonwallyworld: can you comment to this effect on https://bugs.launchpad.net/ubuntu/+source/juju-mongodb2.6/+bug/161077802:37
mupBug #1610778: please remove this package from yakkety <juju-mongodb2.6 (Ubuntu):New> <https://launchpad.net/bugs/1610778>02:37
mwhudsonwallyworld: do we need juju-mongodb (i.e. 2.4) in yakkety?02:41
wallyworldonly if we need to support juju 1.25 in yajjety02:41
wallyworldwhich i think we do as we have committed to 12 (or 18?) months of support02:42
wallyworldbut that should be confirmed02:42
axwveebers: does QA have a vsphere set up that I can test some changes with?02:49
mwhudsonwallyworld: ok02:50
veebersaxw: I'm not sure off the top of my head, let me have a look03:03
veebersaxw: is vsphere known as anything else?03:05
axwveebers: vmware vsphere?03:05
axwveebers: not that I know of otherwise...03:05
axwI'm not very familiar with vmware tools tho03:05
veebersaxw: sorry the only thing close to a  mention I can see is "VMware vCenter Server Appliance"03:06
axwveebers: that might be it03:06
axwwallyworld: do you know about vsphere?03:06
wallyworldno :-(03:06
wallyworldthat was eric et al03:06
axwveebers: I don't see anything about it in cloud-city, so I guess it's not part of CI at the moment...03:09
veebersaxw I saw that mention in consoles.txt but that's all, I don't know if or how it's used.03:09
axwveebers: no worries, thanks for checking03:10
veebersaxw: sorry I couldn't be immediately helpful. I'll follow up tonight/tomorrow if we don't come across anything else03:10
veebersaxw: would you have any insight to my previous query re: status and cs:ubuntu application?03:10
axwveebers: sorry, which query was that?03:11
veebersaxw: 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 deployed03:12
axwveebers: don't know sorry. you didn't rename the app (juju deploy cs:ubuntu <something-else>)? which user is the test logged in as when running status?03:14
veebersaxw: (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
veebersI just know that if it happens quick it errors due to "the application 'ubuntu' is already deloyed"03:15
axwveebers: you're definitely deploying to and running status on the same model?03:17
axwveebers: if you push your branch I might spot something, otherwise I'm stabbing in the dark03:18
veebersaxw ack, let me dig around a bit so I have answers for you.03:18
thumpermenn0: if you feel like a break ^^^03:48
mupBug #1595155 changed: new systemd and dbus dependencies are broken <juju-core:Won't Fix> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1595155>03:49
menn0thumper: i'll get there soon... want to finish battling with this snap first04:02
veebersaxw: btw I figured out what I needed to do :-)04:06
axwveebers: cool04:07
anastasiamacaxw: talking about vsphere :)04:30
axwanastasiamac: ?04:30
anastasiamacaxw: bug 1588390 has a question about how to specify host and datacentre..04:30
mupBug #1588390: 2.0 beta7: can't bootstrap with vsphere cloud provider - ERROR invalid config: host: expected string, got nothing <oil> <oil-2.0> <vsphere> <juju-core:Triaged> <https://launchpad.net/bugs/1588390>04:30
anastasiamacaxw: could u comment?04:31
axwanastasiamac: sure04:31
anastasiamacaxw: \o/04:31
thumpermenn0: ack04:32
mupBug #1575797 changed: AddressableContainerSetupSuite.TestContainerInitialised lxc-net: no such file or directory <centos> <ci> <regression> <test-failure> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1575797>04:34
mupBug #1592366 changed: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366>04:37
menn0wallyworld: I've just emailed you with those instructions, can you try running through them please?04:50
mupBug #1592366 opened: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366>04:52
menn0thumper: ship it04:56
veeberswallyworld, axw: Re: model config tree. Does this start of a test plan make sense? Does it cover concerns? https://pastebin.canonical.com/162579/05:02
wallyworldveebers: yes, but you really need to set up an environment with controller defaults also, using clouds.yaml05:04
mupBug #1592366 changed: Juju machines failed to die, with added storage <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1592366>05:04
axwveebers: as a start, I think so. we'll also want to cover controller- and region-inherited config05:04
wallyworldand you also need to check the dynamic nature of the source values05:04
wallyworldie a value may come from "model" but if the controller default is changed to match, it will say "controller"05:05
veeberswallyworld, axw; good feedback. Is there any docs re: the region stuff?05:05
wallyworldonly the spec05:05
mupBug #1524572 changed: Azure provider: bootstrap results in error "PUT request failed: BadRequest - XML Schema validation error in network configuration at line 24,18." <azure-provider> <bootstrap> <juju-core:Invalid> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1524572>05:07
wallyworldmenn0: 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 found05:15
axwveebers: do you know which, if any, of the QA MAASes I can use to test a bootstrap change?05:19
veebersaxw: I should but I don't sorry :-\ that's 0-2 for today05:20
axwveebers: no worries :)05:20
veebersaxw: 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 there05:21
axwveebers: yeah just don't want to step on anyone's toes05:21
veebersaxw: 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
axwveebers: thanks :)05:23
menn0wallyworld: hmmmm... works for me... are you running juju-menno.juju instead of plain old juju?05:29
wallyworldmenn0: i tried juju as well05:29
wallyworldbut how could plain juju work?05:29
wallyworldthe snap doesn't write to ~/.local/share/juju05:30
menn0wallyworld: indeed. I was making sure you *weren't*  running juju05:31
wallyworldmenn0: right05:31
menn0wallyworld: I'm just running through the instructions again.05:31
wallyworldthe email says "juju", but i did use /snap/bin/juju-menno.juju05:31
menn0wallyworld: so the boostrap starts?05:32
wallyworldyeah, and the watch output is fine. then when I ^C once everything is started, there's nothing there05:32
wallyworldwell, there's a ssh file but no controller.yaml05:33
wallyworldssh directory05:33
wallyworldi'll try again05:33
menn0I get all the usual stuff in ./juju-menno/2/snap/juju-menno/2/.local/share/juju05:33
wallyworldyeah, all i got was an ssh directory05:34
wallyworldmenn0: there's an extra level of directories05:35
wallyworldls ~/snap/juju-menno/2/snap/juju-menno/2/.local/share/juju/05:35
wallyworldthat has all the stuff in it05:35
menn0wallyworld: yep, that's where everything is05:36
wallyworldwhen i run juju from snap, everything is in ~/snap/juju-wallyworld/2/.local/share/juju05:36
wallyworldyours has an extra bit of the path duplicated05:36
wallyworldand in ~/snap/juju-menno/2/.local/share/juju i have just an ssh dir05:37
wallyworldmaybe it's a race or something starting 2 controllers at the same time?05:37
menn0I wonder if it's because the setup script is in the snap and is running another thing in the snap05:38
menn0I might just distribute the script separately if that's the case05:39
anastasiamacmwhudson: 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
mupBug #1570650: Use juju-mongodb2.6 for 1.25 on xenial <local-provider> <packaging> <juju-core:Fix Released> <juju-core 1.25:Triaged> <juju-core (Ubuntu):New> <https://launchpad.net/bugs/1570650>05:39
menn0wallyworld: I've got to stop for now but I'll play around with it some more later on05:40
menn0wallyworld: thanks for trying it out05:40
wallyworldmenn0: no worries, i'll try again later if i can, try starting one controller at a time05:41
wallyworldanastasiamac: 1.25 is only getting critical fixes. i doubt upgrading mongo is a critical fix, but i could be wrong05:42
wallyworldand i think 1.25 support is xenial or trusty only, but again, i could be wrong05:42
anastasiamacwallyworld: i completely agree. did u read the bug?05:44
wallyworldi did, may have misunderstood it. it seems to be asking for cganges to 1.25 to support mongo 2.605:45
anastasiamacwallyworld: 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:46
anastasiamacwallyworld: 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 from05:48
anastasiamacyakkety, which seems inconsistent with this."05:48
wallyworldok. 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 resources05:48
anastasiamacwallyworld: this decision is not related to my question05:48
wallyworldyeah, i'm a bit confused by the "inconsistent" bit05:50
anastasiamacwallyworld: the bug is about xenial. why are mentioing yakkety here?05:50
wallyworlddon't know05:50
anastasiamacwallyworld: k. i'll ask Michael tomorrow ;0 NZ must be coming offline \o/05:50
veeberswallyworld: There is support for --upload-tools within juju-ci-tools, the abrupt removal of it would trip up some tests.05:56
wallyworldveebers: yeah, i grepped the source just before, i'll add an alias05:56
wallyworldthanks for looking, doesn't look like there's too much to change, but it will take some time05:56
veeberswallyworld: ah sorry had meant to get back to you earlier. You intend to fully remove it at some poitn?05:56
veebersno, not much to change, but might need some mechanism to make it backwards compat.05:57
wallyworldyeah, once everyone agrees, right now it's a spike05:57
wallyworldwe have a mechanism for 1.25 vs 2.0 tests i think05:57
veeberswallyworld: 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
wallyworldveebers: on my list - en email will be going to a wider audience than just qa05:58
veebersyeah there is (also, every beta revision release too)05:58
veeberswallyworld: awesome, thanks.05:59
veebersaxw, 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
veebersAttribute               Default                  Controller06:20
veebersapt-mirror:             archive.ubuntu.com        -06:20
veebers  aws/us-east-1:        us-east-1.aws.ubuntu.com  -06:20
axwveebers: I don't think it's implemented yet -- right wallyworld?06:21
axwveebers: yeah, the initial work is still pending: http://reviews.vapour.ws/r/5339/06:22
wallyworldveebers: yep, still wip06:22
wallyworldonly the controller inherited config is done06:22
veebersah ok, I'll ask that question at a later date then :-)06:22
wallyworldveebers: what's done is documented in the release notes, as is what is still todo06:22
veebersOk, I'm just trying to figure out the clouds.yaml and how it can be used in a test06:23
wallyworldrelease notes contain that info too06:23
veebersare latest release notes always found here: https://jujucharms.com/docs/devel/temp-release-notes06:24
veebershmm, nvm. I see that it is06:27
veeberswallyworld: 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:35
wallyworldveebers: 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 etc06:37
mupBug # changed: 1402696, 1568181, 1568185, 156819006:37
veeberswallyworld: how does one change a controller value after a bootstrap? Or is it always read from clouds.yaml?06:39
wallyworldjuju set-model-default06:39
veebersthat sets a controller default? or am I getting confused06:40
wallyworldalso juju unset-model-default06:40
veebersthere is base default config, model config and controller config right?06:40
wallyworldit sets the default value for a model attribute, which just happens to be a controller wide default06:40
wallyworldit will grow the ability to set a region default also when that bit is done06:41
wallyworldjuju set-model-default --region=us-east-1 http-proxy=foo06:41
wallyworldor something liek that06:41
veebersah ok.06:41
veebersI'll update that testplan I shared earlier and bother you again about it tomorrow :-)06:42
wallyworldthere's current 3 sources of model config: default, controller, model06:42
wallyworldit will soon be 406:42
wallyworldthe order goes: default, controller, region, model06:42
=== frankban|afk is now known as frankban
mupBug #1605770 changed: firewallerSuite.TearDownTest inst.Dial() failed <ci> <intermittent-failure> <regression> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1605770>07:07
mupBug #1610260 changed: AWS Error fetching security groups EOF/timeout <bootstrap> <ec2-provider> <intermittent-failure> <juju-core:Invalid> <juju-core 1.25:Won't Fix> <https://launchpad.net/bugs/1610260>07:07
mupBug #1610880 opened: Downloading container templates fails in manual environment <juju-core:New> <https://launchpad.net/bugs/1610880>08:01
dimiternfwereade__: hey, do you think upgrading from e.g. 2.0-beta14.1 to 2.0-beta14 should be allowed?09:02
dimiternfwereade__: 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.go09:03
dimiternfwereade__: i.e. I was wondering if there's a good reason not to just compare versions with version.Number.Compare() in the upgrader09:05
fwereade__dimitern, thinking... but *mainly* thinking that if we're not supporting upgrades during beta it's somewhat moot09:06
babbageclunkfwereade__, dimitern: take another look at http://reviews.vapour.ws/r/5365?09:07
dimiternfwereade__: the issue I'm trying to fix is outlined in bug 160774909:07
mupBug #1607749: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too) <bootstrap> <maas-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1607749>09:07
dimiternbabbageclunk: will do in a bit09:07
dimiternfwereade__: weird case I agree, but it did still expose that wrinkle of the upgrading logic09:08
dimiternfwereade__: bootstrapping with --upload-tools from a released client binary triggers it09:08
fwereade__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:10
fwereade__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 years09:11
dimiternfwereade__: I think it's the difference between version.Current and having FORCE-VERSION09:12
dimiterneven though --upgrade-tools adds the latter to fake it's .1, the binary version is still sans that .109:12
fwereade__dimitern, well, maybe, but why aren't we recording the same tools version that we're eploying?09:12
fwereade__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 .109:14
dimiternfwereade__: 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 symptom09:14
fwereade__dimitern, am super-confused: ISTM that the upgrader *is* quite reasonably and correctly considering the versions to be different09:15
dimiternfwereade__: and there's bootstrap --auto-upgrade as well (false by default), totally not taken into account AFAICS09:15
dimiternfwereade__: 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
fwereade__dimitern, looks like it's doing exactly the right thing09:16
fwereade__dimitern, saw local version, server said it should run a different version, trying to do that09:17
fwereade__dimitern, the problem there is the server asking us to change in the first place09:17
dimiternfwereade__: ok, then I'll keep digging - wanted to confirm that's the correct behavior in the upgrader09:17
fwereade__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 work09:19
dimiternfwereade__: I've verified the proxy settings are populated (into ~/.juju-proxy) on agents09:19
fwereade__dimitern, ok... does that mean that the agent always uses them?09:21
dimiternfwereade__: that's what I'm trying to figure out now :)09:22
anastasiamacdimitern: fwereade__: in beta14, there was a fix for --upload-tools and build version mismatches... seee https://bugs.launchpad.net/juju-core/+bug/160505009:22
fwereade__dimitern, I don't see why it would09:22
mupBug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools <sts> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1605050>09:22
dimiternfwereade__: btw the origAgentVersion in the upgrader comes as PreviousAgentVersion, via agentconfig.UpgradedToVersion()09:22
dimiternanastasiamac: cheers - i'll look there as well09:23
anastasiamacdimitern: \o/09:23
dimiternanastasiamac: I see you've been on fire closing 1.25 bugs :)09:23
anastasiamacnot closing....just brooming the house a bit..09:23
dimiternanastasiamac: ;) nice to see the count going down though!09:25
fwereade__dimitern, AFAICS the heart of the problem is that the *server* is asking us to upgrade09:30
fwereade__dimitern, it looks like we have the right binary and the right config on the agent09:30
dimiternfwereade__: I think anastasiamac nailed it - the discrepancy seems to be fixed with tim's PR https://github.com/juju/juju/pull/5879/files09:31
dimiternto confirm that I'll try the same scenario, but with the next beta09:31
fwereade__dimitern, sweet09:32
dimiternfwereade__, anastasiamac: it works in beta14, so indeed a dup of bug 1605050! thanks for the help ;)09:42
mupBug #1605050: Controller doesn't use tools uploaded with juju bootstrap --upload-tools <sts> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1605050>09:42
anastasiamacdimitern: :) m glad!09:42
macgreagoirwin 1709:45
mupBug #1607749 changed: juju bootstrap fails with MAAS trunk and juju (beta12 behind a proxy too) <bootstrap> <maas-provider> <juju-core:In Progress by dimitern> <https://launchpad.net/bugs/1607749>09:53
dimiternsorry babbageclunk I'm on to your PR now09:53
babbageclunkdimitern: thanks, no worries09:54
menn0fwereade: reviews done09:56
fwereademenn0, tyvm10:03
fwereademenn0, 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 behaviour10:08
fwereademenn0, what tests would you write that aren't just this-input-produces-this-output, who-knows-what-it-means-or-does?10:09
menn0fwereade: ok fair enough.10:09
menn0fwereade: some of those methods /are/ conditional ... but I see your point10:09
fwereademenn0, restate conditional please?10:11
menn0fwereade: sorry, they have conditional logic which could perhaps warrant a test10:12
menn0fwereade: doing different things depending on what's in the DB10:12
fwereademenn0, yeah10:13
fwereademenn0, how about if I do a pass for the externally-visible impact of same and make sure we have suitable hooks tests?10:13
menn0fwereade: sgtm10:14
fwereademenn0, cheers10:14
dimiternbabbageclunk: reviewed10:31
babbageclunkdimitern: Thanks!10:31
anastasiamacrick_h_: \o/11:24
mupBug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390>11:29
mupBug #1598390 opened: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390>11:35
mupBug #1598390 changed: Juju 2.0 Resources - Issue faced in the deployment of a charm from charm store when juju-attach is used <2.0> <juju-core:Fix Released> <https://launchpad.net/bugs/1598390>11:38
fwereadebabbageclunk, dimitern: sorry, I had a couple of comments on the review but I didn't hit post11:54
babbageclunkfwereade: cool, thanks12:25
=== petevg_vacation is now known as petevg
rick_h_macgreagoir: welcome back, good week?13:06
macgreagoirrick_h_: It was, thanks. Week of sun!13:07
rick_h_macgreagoir: added some small "get back in the flow of things" bugs your way on the kanban board13:07
rick_h_macgreagoir: please take a look when you're through  email and looking for next task13:07
macgreagoirrick_h_: Noted :-) I have been trying to catch up.13:08
rick_h_macgreagoir: all good, wheeeee13:08
rick_h_natefinch: katco macgreagoir dimitern ping for standup14:00
rogpeppehmm, git blame is becoming less useful. What is "Juju bot" doing as an author in apiserver/network.go ?14:15
rick_h_katco: <3 I went to create a tracking card and it yelled at me that the id already existed14:24
rick_h_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:25
dimiternrick_h_: sure, added to my list14:26
rick_h_ty dimitern14:26
katcorick_h_: np14:27
rick_h_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:29
rogpeppefwereade: ping14:48
mupBug #1610990 opened: list-storage in aws contains non-created items <blocker> <ci> <regression> <storage> <juju-ci-tools:Incomplete> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1610990>14:51
mupBug #1610993 opened: UnitSuite.TestWorkers timed out waiting for workers <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju-core:Triaged> <https://launchpad.net/bugs/1610993>14:51
=== natefinch is now known as natefinch-afk
voidspacerick_h_: a side effect of allowing a maas server url without a prefix (so that the port can be specified unambiguously)15:43
voidspacerick_h_: is that it's basically impossible to detect invalid maas server urls until we try to use them15:43
voidspacerick_h_: I think the failure error is still clear enough, it's just a bit later15:44
voidspacerick_h_: (for invalid urls we now add http:// prefix automatically - and according to url.Parse that makes anything a potentially valid url)15:44
voidspacejust noting it15:45
=== frankban is now known as frankban|afk
rick_h_voidspace: yea, with the add-cloud work I think our goal is to ping and reach the server to validate it's real and there15:49
voidspacerick_h_: cool15:49
rick_h_voidspace: so we'll just have to pick up that "try it" work where it makes sense to fail fast for the user15:49
voidspacerick_h_: I've pinged menno for an updated review15:51
rick_h_voidspace: <3 ty15:51
babbageclunkdimitern: Is it reasonable for this machineundertaker worker to use something from the provisioner API, if it does what it needs? Or is that bad?16:05
babbageclunkfwereade: ^^16:10
babbageclunkdimitern, fwereade: more specifically - ProvisionerAPI.GetContainerInterfaceInfo does pretty much exactly what I want. Is there any way to reuse that?16:11
joserick_h_: hey. do you have a sec to chat?16:27
rick_h_jose: sure thing16:28
rick_h_jose: you up for a HO?16:28
joserick_h_: sure, one sec16:29
dimiternbabbageclunk: I don't think it's a good idea16:34
dimiternbabbageclunk: we have cases where methods on different facades are shared via apiserver/common mixins16:34
dimiternbabbageclunk: but why do you think you need the same API method?16:35
babbageclunkdimitern: Well, I need something that takes a set of machine ids and returns a set of networkconfigs for those machines.16:36
babbageclunkdimitern: I'm writing it at the moment, but making backend interfaces + shims for State -> Machine -> LinkLayerDevice -> Address is pretty annoying.16:38
dimiternbabbageclunk: what shims? can I see at a diff?16:42
babbageclunkdimitern: Well, you can see the old version of it at http://reviews.vapour.ws/r/5366/diff/16:42
babbageclunkdimitern: There it's State -> MachineRemoval -> LinkLayerDevice16:43
dimiternbabbageclunk: have you seen apiserver/common/networkingcommon ?16:43
babbageclunkdimitern: Ooh, no - checking now16:44
dimiternbabbageclunk: there are useful helpers for converting configs16:44
dimiternmight save you some of that16:44
babbageclunkdimitern: Oops, killed this buffer.16:47
dimiternbabbageclunk: :) I noticed16:47
babbageclunkdimitern: Unfortunately none of that seems to cover the types I need. :(16:47
dimiternbabbageclunk: I think the shim based approach for apiserver facades didn't work quite well16:48
dimiternbabbageclunk: why not have a look at other examples - e.g. storage-related facades might be better designed16:49
babbageclunkdimitern: ok - any one specifically?16:49
dimiternbabbageclunk: storageprovisioner comes to mind16:49
babbageclunkdimitern: Hmm.16:55
babbageclunkdimitern: That kind of does what I'm doing. The main difference is that it can get away without shims because all of the methods return either interfaces or publically constructable types.16:56
babbageclunkdimitern: Without many shims, I mean.16:56
babbageclunkdimitern: But Machine, LinkLayerDevice and Address all have private constructors and embed a *State, so I need to cover them with interfaces to test.16:58
dimiternbabbageclunk: let's discuss it tomorrow? I need to go soon..16:59
babbageclunkdimitern: Oops, it's late for you! I'll bug you and Will about it tomorrow.16:59
babbageclunkHa ha snap16:59
babbageclunkdimitern: Bye!17:00
dimiternok ;)17:01
* rick_h_ grabs lunchables17:07
=== natefinch-afk is now known as natefinch
natefinchwow uh, juju credentials <cloud> is completely useless17:41
natefinchhow is the first step of setting up juju with azure "install node" ?17:47
sinzuinatefinch: bug 1611067 is a recent regression that related to bug 1418139 that is assigned to you.17:48
mupBug #1611067: kill-controller of manual failed to clean up models <blocker> <ci> <kill-controller> <manual-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1611067>17:48
mupBug #1418139: Can't reprovision a machine with manual provider <bootstrap> <destroy-environment> <manual-provider> <manual-story> <juju-core:In Progress by natefinch> <juju-core 1.25:Fix Committed by natefinch> <https://launchpad.net/bugs/1418139>17:48
rick_h_natefinch: there's WIP around that node azure stuff17:50
natefinchrick_h_: oh good17:50
mupBug #1611067 opened: kill-controller of manual failed to clean up models <blocker> <ci> <kill-controller> <manual-provider> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1611067>17:51
rick_h_natefinch: yea, https://github.com/Azure/azure-sdk-for-go/issues/36017:52
natefinchrick_h_: nice17:53
natefinchsinzui: those two bugs are definitely different, even though they may have similar external behavior.  The previous bug left a very obvious panic at the end of the controller's machine log, and this one does not.18:08
mupBug #1611076 opened: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076>18:48
mupBug #1611076 changed: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076>18:54
mupBug #1611076 opened: we need a juju rename-credential command <juju-core:New> <https://launchpad.net/bugs/1611076>18:57
natefinchkatco: responded.  I need to review the tests (didn't get a chance last time) and then pretty sure I can just LGTM it.19:24
katconatefinch: cool ty19:24
katconatefinch: your point about logging the retries at a different level is interesting. i'm not sure where i come down on that yet... i like the idea of being able to look at the log while it's happening to understand what's going on, but not sure if i would expect to flip into trace mode to do that19:28
* katco wonders if anyone else has opinions on that19:28
natefinchkatco: my opinion - there's errors and there's non-errors. This is not an error, because it's being retried.  Once it fails forever, then it's an error.  until then, it's just info (or debug).19:56
katconatefinch: there are warnings too19:57
mupBug #1611093 opened: "juju models" hangs <oil> <oil-2.0> <juju-core:New> <https://launchpad.net/bugs/1611093>19:57
natefinchkatco: I'm with Dave on warnings. Warnings, IMO, don't have a good use case.  Warning is basically "we didn't know if we should make this an error or not, so we put it at warning"... except that the code definitely has to treat it as an error or not, and usually it's treated as not an error.19:59
natefinchsinzui, mgz: have you seen this azure error? Provisioning failed. Shrinking a disk from 136367309312 bytes to 34359738880 bytes is not supported.. ResizeDiskError20:00
katconatefinch: warnings are definitely not an error (i.e. the system is not in an errored state), but i disagree that one only arrives at utilizing warnings because they cannot decide between info and error.20:00
katconatefinch: e.g., this code. juju is warning you that something is going wrong, but it may recover.20:01
natefinchkatco: it's a bit of a simplification, for sure.20:01
natefinchkatco: I guess, if it works in the end, then I feel like it's not super noteworthy.  Like dropped tcp packets.20:01
katconatefinch: except dropped tcp packets can forewarn of a failure and are often logged :)20:02
natefinchkatco: sure, and I'm not saying we shouldn't log retries at all.  They definitely 100% should be recorded somewhere. I'm just arguing to make them less in your face.20:03
katconatefinch: yes, that is the part i'm on the fence about20:03
sinzuinatefinch: We have not see ResizeDiskError before20:03
katconatefinch: it seems like a normal part of the system's operation, and not super-detailed tracing information20:04
natefinchkatco: it's a matter of degrees.  The problem is, I think whether it's info or warning is very much dependent on exactly what caused the retry... so do we err on the side of visibility or the side of keeping noise low?20:04
katconatefinch: i don't think you should be worrying about noise at the raw log data level. that is a problem for log views20:05
natefinchsinzui: it's unfortunate - Juju seems not to realize that this instance will never come up. It still says the agent is allocating20:06
natefinchkatco: we should definitely worry about noise in the log.  Most of our interactions with the log are at the raw text level.  There have been bugs filed and work done to remove spam from the logs.  I think that's worth the effort.20:07
katconatefinch: good point; we do seem to come down on that side of the argument (although i disagree with it)20:09
katconatefinch: still, these messages a) won't always be there, b) will happen at most 3 times20:10
natefinchsinzui: crap, I seem to be getting that consistently now (well, 2 out of 2 tries)20:10
mgznatefinch: hm, are you doing anything differently from the runs that worked?20:11
natefinchmgz: ¯\_(ツ)_/¯20:12
natefinchmgz: using 2.0-beta1420:13
natefinchmgz: forgot to use upload-tools, so I presume it's using whatever is in streams20:13
natefinchalso, interstingly:20:14
natefinch$ juju add-machine --series win201220:14
natefinchERROR empty apt-https-proxy in model configuration20:14
mgzthat seems like a bug20:16
natefinchyeah, I'm going to rebuild and make sure I'm running master with upload tools and see what happens then20:16
sinzuinatefinch: in azure I think you need to use series win2012r220:25
natefinchsinzui: ahh, maybe that's the problem20:25
natefinchsinzui: hmm... getting the same error if I use win2012r220:31
sinzuinatefinch: Our tests from this morngin get farther http://reports.vapour.ws/releases/4221/job/azure-arm-deploy-windows-amd64/attempt/4520:32
mupBug #1611097 opened: model already exists but can't be destroyed because it's not found <oil> <oil-2.0> <juju-core:Incomplete> <https://launchpad.net/bugs/1611097>20:34
sinzuinatefinch: We never use upload-tools since it doesn't worth with multiple os/arch. we used streams. We also deployed a charge from lp:juju-ci-tools/repository20:34
sinzuijuju --show-log deploy -m azure-arm-deploy-windows-amd64:azure-arm-deploy-windows-amd64 /var/lib/jenkins/repository/charms-win/dummy-source --series win2012r220:34
natefinchman, our pedantry for credential vs credentials is really annoying20:43
natefinchmgz: fwiw, that "no apt-proxy set" error went away with a rebuild, so probably I was just in some weird bad state in my local code (hopefully).20:53
mgzyeah, hopefully just a version incompat20:55
natefinchwow, juju add-model takes a heck of a long time for something that should be almost a noop20:56
natefinchh$ juju kill-controller azure -y21:00
natefinchpanic: empty value for "firewall-mode" found in configuration (type <nil>, val <nil>)21:00
rick_h_natefinch: did destroy-controller not work?21:00
natefinchrick_h_: I never use destroy controller21:00
rick_h_natefinch: :(21:00
rick_h_natefinch: that's the official way for users to perform that operation21:00
natefinchrick_h_: kill-controller is shorter and doesn't make me type out that extra flag about killing models too21:01
natefinchrick_h_: FWIW destroy gives that error too :021:02
natefinchrick_h_: I gotta run to make dinner, but will be back in a few hours21:02
=== natefinch is now known as natefinch-afk
mupBug #1611110 opened: Need remove-{space,subnet} commands <juju-core:New> <https://launchpad.net/bugs/1611110>21:04
mupBug #1611111 opened: Model still exists for a while after running destroy-model <oil> <oil-2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1611111>21:04
bdxother then specifying `--upload-tools`, should there be anything else to keep in mind when bootstrapping/deploying from a build of master ?21:44
thumperbdx: I don't think so21:46
bdxthumper: thx21:47
tvansteenburghany one have an example of deploying a local charm via the api?22:19
tvansteenburghwith juju 2, specifically22:24
tvansteenburghi have and example from juju1 that uploads a charm archive and then deploys it with the local:series/charm nomenclature22:25
tvansteenburghdoes that still work?22:25
tvansteenburghand if so, what would the charm-url passed to the api be?22:28
menn0wallyworld: I've updated my snap. Could you have another go at those instructions again please when/if you have a chance?22:44
menn0wallyworld: the weird directory hierarchy under ~/snap was being caused by the setup script calling another binary in /snap/bin22:45
menn0wallyworld: the setup script now calls $SNAP/bin/juju directly instead and that fixes the issue22:45
menn0wallyworld: not sure exactly what was going on but the environment variables seen by juju weren't right due to the nested invocation22:46
wallyworldmenn0: sure. yeah that was weird. seems like a bug to me. i'll try after standup22:47
redirbrb reboot22:47
redirwallyworld: axw wanted a test (see RB), I am curious if there's already a related test for other inherited config and if so where it lives.23:02
redirwallyworld: he suggested cloudconfig, but at a glance I don't see anything similar.23:03
wallyworldthere's no feature test yet (still todo). but there are other tests, i'll look at rb and see what's been requested23:04
alexisbredir, welcome back23:05
alexisbhope you had a lovely holiday23:05
rediralexisb: tx23:05
* redir nods23:05
redirvery relaxing:)23:05
redirand more sun than is probably healthy23:05
alexisb:) sun and relaxation both sound great23:07
redirHighly recommended:)23:08
alexisbthumper, wallyworld ping23:16
mupBug #1605008 changed: juju2beta12 and maas2rc2:  juju status shows 'failed deployment' for node that was 'deployed' in maas <oil> <oil-2.0> <juju-core:Invalid> <MAAS:Invalid> <https://launchpad.net/bugs/1605008>23:25
mgzalexisb: I think we need to have a plan over bug 1570650 - what happens if we get a security bug reported against 1.25/db in the trusty support lifespan23:26
mupBug #1570650: Use juju-mongodb2.6 for 1.25 on xenial <local-provider> <packaging> <juju-core:Fix Released> <juju-core 1.25:Won't Fix> <juju-core (Ubuntu):Invalid> <https://launchpad.net/bugs/1570650>23:26
mupBug #1610990 changed: list-storage in aws contains non-created items <ci> <regression> <storage> <juju-ci-tools:Incomplete> <juju-core:Won't Fix by axwalk> <https://launchpad.net/bugs/1610990>23:46
perrito666redir: what is the bug?23:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!