[00:25] <wallyworld> axw: when you get a chance, no rush, a small tweak to series validation. i'll then update dep in the master pr https://github.com/juju/charm/pull/198
[00:40] <davecheney> thumper: https://github.com/juju/juju/pull/4688
[00:41]  * thumper looks
[00:41] <davecheney> i tried a few ways yesterday to merge these two handlers into one
[00:41] <davecheney> but as the one from api/private/server comes with a compelte implementation of a python mocking framework
[00:41] <davecheney> it was infeasable
[00:41] <davecheney> this is a smaller change which does the same thing
[00:41] <davecheney> and the author of the original code will have to figure out how to merge the two types
[00:45] <thumper> davecheney: change looks good +1
[00:46] <davecheney> thumper: ta
[01:13] <thumper> hmm... third time today I've hit bad record mac trying to land things
[01:16] <thumper> wallyworld: can you meet early?
[01:16] <wallyworld> thumper: sure, give me a couple of minutes
[01:16] <thumper> ok
[01:24] <natefinch> evening all
[01:28] <alexisb> evening natefinch
[01:28] <katco> natefinch: kiddo feeling any better?
[01:29] <natefinch> katco: not really... she's only had water & pedialyte since 6pm last night, and threw up even the water just before bed tonight.  But that's only #3 since 8am, so I'll take it over last night, for sure.
[01:30] <katco> natefinch: jees :(
[01:31] <natefinch> katco: my wife is slightly better off... she's managed to have, I think, two crackers, besides various liquids since around 8pm last night.   Crazy bad virus.
[01:32] <alexisb> natefinch, that sounds terrible :(
[01:34] <natefinch> alexisb: OMG, it was horrible.  We had to call our babysitter at 10pm to come help with the baby until about 3am when my wife was finally able to get off the bathroom floor and be in the bedroom.
[01:35] <alexisb> :(
[01:35] <natefinch> worst ever, and we've had some bad ones.
[01:43]  * alexisb wishes she had gofmt for 'c' in her kernel days
[01:45] <natefinch> tiotally... man, I remember having autoformat wars at my last job... if you didn't configure your autoformatter exactly right, every time you commit your stuff, you reformatted the code to be slightly differently.  Another guy on my team kept doing that... the aggravating thing was that he didn't notice, which made me really wonder if he even looked at what he was checking in.
[01:47] <natefinch> katco: ericsnow left a comment on my charmrepo PR about this needing to get merged into the new-channels-model branch.  Should I just PR this against that branch as well?  ref: https://github.com/juju/charmrepo/pull/65
[01:59] <natefinch> katco: just landed that 3 pointer in charmrepo.v2 (master)
[02:12] <davecheney> thumper, menn0: https://github.com/juju/juju/pull/4691
[02:12] <davecheney> followup from previous CL
[02:12] <menn0> davecheney: thumper is about to drive up to Christchurch so i'll do it
[02:13] <davecheney> ta
[02:13] <davecheney> this is more refactoring to remove the apisever/common dependency from the resource/api
[02:13] <davecheney> because apiserver imports resource/api
[02:13] <davecheney> so if I want to move apiserver/common.ServerError to apiserver
[02:13] <davecheney> i need to break that import loop
[02:14] <davecheney> and i want to move apiserver/common.ServerErr to apiserver to pay down the technical debt from the UpgradeInProgress refactor
[02:39] <cherylj> menn0: ping?
[02:40] <menn0> cherylj: howdy
[02:41] <cherylj> menn0: hey there, wanted to pick your brain on this mongo problem
[02:41] <cherylj> so we had mario run mgopurge
[02:41] <cherylj> and we told it to skip objects with an invalid token
[02:42] <cherylj> but I was wondering...  do those need to get cleaned up anyhow?
[02:42] <cherylj> some how?
[02:42] <menn0> cherylj: yeah, i was going to reply to that email thread today but have been flat out
[02:42] <cherylj> we're panicking in the same sort of way now in jujud - the token is invalid
[02:43] <menn0> cherylj: are the bad txn tokens in the txn-queue field?
[02:43] <menn0> cherylj: if so, yes they'll need to be removed. I kind thought that's what we were getting mgopurge to do but I could be misremembering
[02:43] <cherylj> menn0: that's what I'm wondering / thinking.  I haven't downloaded the db yet to look
[02:43] <menn0> cherylj: seems likely if that's the case
[02:44] <menn0> cherylj: mgo/txn will be trying to look up those txns, failing to find them and panicking
[02:44] <cherylj> menn0: but what I added in to prevent mgopurge from panicking was just to skip those transactions
[02:44] <menn0> cherylj: I was going to say on the email that they should get the replicaset healthy *before* trying to fix anything else
[02:44] <cherylj> maybe there's something else I need to add which removes them from the queue
[02:45] <cherylj> menn0: it sounds like they've done that
[02:45] <menn0> cherylj: he said that 2 out of the 3 nodes are ok
[02:45] <menn0> cherylj: that's not healthy
[02:45] <menn0> cherylj: they should get that 3rd node happy again first
[02:45] <cherylj> menn0: ah, gotcha
[02:46] <cherylj> menn0: I can ask Mario to do that
[02:47] <menn0> cherylj: and it sounds like making mgopurge remove the bad txn tokens needs to happen too
[02:47] <menn0> cherylj: a bad/empty token should just be treated the same as a missing txn
[02:47] <cherylj> menn0: yeah, that's what I was thinking.  I'll take a closer look at the PurgeMissing code
[02:47] <menn0> cherylj: the same logic that removes missing txns from the txn-queue field can then be used to remove the bad ones too
[02:51] <cherylj> bleh this mgo stuff is hard to read
[03:08] <katco> natefinch: i'd say just master and they an bug us if the merge conflicts are too bad
[03:20] <axw> wallyworld: charm change LGTM
[03:21] <wallyworld> tyvm
[03:48] <axw> wallyworld: adding cloud name, etc. to controllers.yaml doesn't really work :/   if you did "juju register", we've got nowhere to pull that information from
[03:48] <axw> wallyworld: so I think it goes back into bootstrap-config.yaml, and we cross-reference that in list-controllers
[03:52] <wallyworld> axw: ok, let's go with that; we can be clear about the limitations. the only other option i guess it to make an api call
[03:52] <rick_h__> axw: is this for the provider type info?
[03:53] <axw> wallyworld: IMO that's out of the question
[03:53] <wallyworld> yeah, agreed, was just making sure we covered all options
[03:53] <axw> rick_h__: sorta. it's for that, plus the bits we need to kill-controller if the controller is dead
[03:53] <axw> rick_h__: we could store the provider type easily, but the other information not so much
[03:53] <rick_h__> axw: ah ok, for the provider type user query I'd hope we could put that in the show-controller metadata
[03:53] <rick_h__> axw: gotcha
[03:54] <rick_h__> axw: yea, /me didn't catch the rest of the convo for the kill-controller link
[03:54] <axw> rick_h__: two birds, one stone :)
[03:54] <rick_h__> axw: yea, but let's make sure they're both birds and not one moose and one bird
[03:54] <axw> ;)
[03:55] <rick_h__> no thumper? curses
[04:16] <menn0> rick_h__: thumper is driving up to christchurch (where I live). he's taking his kids to a convention up here.
[04:16] <menn0> rick_h__: can I help at all?
[04:36] <axw> wallyworld: just thinking out loud... we could forget about storing the credential label/origin, and just auto-detect and use whatever it returns, like at bootstrap
[04:37] <axw> wallyworld: and if none auto-detected, say something like "no credentials detected". I guess the origin is still useful though...
[04:38] <axw> wallyworld: (just trying to minimise surface for such a corner case)
[05:24] <wallyworld> axw: sorry, was out with anastasia talking lxd image caching. yeah, we went around and around on minimising the serface for the corner case didn't we. but the idea of storing the label/origin is so that if we autodetected the wrong credentials, we could prompt for the correct ones
[05:24] <wallyworld> but is the effort worth it
[05:24] <axw> wallyworld: yeah, I suppose so. I'll add it later, doing the minimal work for now to support lxd
[05:25] <wallyworld> sgtm. i don't think it's that much extra to store the label/origin, let's take a view once things have settled a bit
[08:00] <TheMue> morning o/
[08:10] <mup> Bug #1555969 opened: API server stops responding after juju add-unit <juju-core:Triaged> <https://launchpad.net/bugs/1555969>
[08:21] <axw> wallyworld: if you're around later and feel like looking, here's the WIP: https://github.com/juju/juju/compare/admin-controller-model...axw:bootstrapconfig-partial-ondemand
[08:22] <axw> wallyworld: all working, lots of tests to update now.
[09:12] <frobware> voidspace: did this (http://reviews.vapour.ws/r/3955/) get back into master?
[09:13] <voidspace> frobware: well, the code it was changing wasn't on master I don't think
[09:14] <voidspace> frobware: I can have a look
[09:15] <voidspace> frobware: the subnetToSpaceIds function it changes doesn't exist on current master
[09:15] <dimitern> frobware, hey, I've realized I gave you bad advice yesterday wrt dependencies.tsv :/
[09:15] <frobware> dimitern: so let's fix it before we merge to master
[09:15] <dimitern> frobware, those imports which were removed with the master merge caused issues on windows
[09:16] <frobware> dimitern: I was looking at the report
[09:16] <dimitern> frobware, yeah, I suppose just adding back the missing ones will fix 3 of the curses
[09:16] <frobware> dimitern: can I just merge in what I had done?
[09:16] <frobware> originally
[09:16] <menn0> fwereade__: i'm aiming to review your model agent integration PR soon
[09:16] <dimitern> frobware, I'd try to use GOOS=windows godeps -N ... as suggested in the linked bug report
[09:16] <frobware> voidspace: if we're going to get maas-spaces2 into master next week we can wait till then
[09:17] <frobware> voidspace: I was just curious if you ported that single fix into master. I guess not because it was only broken on maas-spaces2
[09:18] <voidspace> frobware: right, it *couldn't* be ported to master...
[09:22] <dimitern> dooferlad, hey, I see getMongoSpace changes caused a data race in the last CI run
[09:22] <dooferlad> dimitern: really? Grr.
[09:22] <dimitern> dooferlad, can you have a look at that? http://reports.vapour.ws/releases/3735/job/run-unit-tests-race/attempt/1095#highlight
[09:23] <dooferlad> dimitern: on it
[09:23] <dimitern> dooferlad, cheers
[09:23] <fwereade__> menn0, <3
[09:24] <fwereade__> menn0, I recommend ignoring everything under worker/dependendency; core/life; and all the */lifeflag bits
[09:24] <fwereade__> menn0, because I can and will extract those
[09:24] <menn0> fwereade__: ok will do
[09:25] <dimitern> frobware, in my experiments yesterday I found this quick hack significantly reduces the initial boot time: http://paste.ubuntu.com/15346394/
[09:26] <dimitern> frobware, ~2m (average) from allocated to deployed
[09:41] <frobware> dimitern: the bridge wait I understand, the ntp is a step too far...
[09:43] <dimitern> frobware, that's because of the race I was telling you about when trying to ifup a lot of static interfaces
[09:44] <dimitern> frobware, I was seeing 4-5 bash instances trying to run ntpdata and getting blocked on trying to create a lockfile
[09:47] <frobware> dimitern: I'm going to try an experiment with a one-time reboot post our butchering of eni
[09:47] <frobware> dimitern: but somewhat secondary to getting the devices work done
[09:48] <dimitern> frobware, I tried that as well - depending on when you reboot, it might not work at all - e.g. before installing bridge-utils
[09:48] <dimitern> frobware, agreed
[09:48] <frobware> dimitern: the bridge-utils is a pre-req so is already present before we run the script
[09:49] <dimitern> frobware, yeah, that's assuming we got the chance to even run apt-get install bridge-utils
[09:49] <dimitern> frobware, which will happen after the bridge script completes
[09:56] <frobware> dimitern: it happens the other way round.
[09:56] <frobware> dimitern: our script would fail catastrophically if it wasn't present
[09:57] <frobware> dimitern: you can see this if you deploy from MAAS, cp the script, and run it. the whole thing fails because there is no brctl
[09:59] <dimitern> frobware, that's what I'm talking about :)
[09:59] <dimitern> frobware, since the script runs as a bootcmd, it will run before any packages listed in the generated userdata are installed..
[09:59] <frobware> dimitern: I was confused. you said "after the bridge script completes"
[10:00] <dimitern> frobware, hmm.. I might be wrong - just observed something like that
[10:01] <frobware> dimitern: there is no way we could bring the interface up without bridge-utils being there
[10:01] <frobware> dimitern, voidspace, dooferlad: standup/planning
[10:02] <voidspace> frobware: omw
[10:51] <menn0> fwereade__: review done. lots of great stuff. thank you. it will be great to get this landed.
[10:53] <dimitern> frobware, this is the gist of what's needed: http://paste.ubuntu.com/15346665/, and those API calls follow the pattern in http://paste.ubuntu.com/15241590/
[10:53]  * menn0 bed
[10:55] <dimitern> frobware, so if we agree on the interface, I can use a stub for now, and later we integrate
[10:56] <dimitern> frobware, let me know what you think
[10:59] <frobware> dimitern: will look in a bit
[11:03] <frobware> dimitern: I don't see a great deal of diff with your godeps incantation; https://pastebin.canonical.com/151643/
[11:05] <dimitern> frobware, that's exactly the missing import causing the curse
[11:05] <frobware> dimitern: :) yes, just read the bug.
[11:06] <dimitern> frobware, well, now we know what this package is for :)
[11:06] <frobware> dimitern: so another alternative is that we merge from master again this morning
[11:06] <frobware> dimitern: we would get that ^^ for free
[11:08] <dimitern> frobware, also works, and will give us updated lxd stuff as a benefit
[11:08] <frobware> dimitern: right, I'll do that instead.
[11:09] <dimitern> frobware, however, that should be followed up by dooferlad's fix not long after the merge lands in order not to waste a CI run
[11:09] <frobware> dimitern: good point
[11:13] <frobware> dimitern: can we HO re: the godeps stuff again. as in what's the best way to merge and or update it
[11:13] <dimitern> frobware, ok
[11:14] <dimitern> frobware, I'm in the sapphire HO (last one we used)
[11:55] <dooferlad> dimitern / frobware / voidspace: http://reviews.vapour.ws/r/4132/ fixes those races.
[11:57] <dimitern> dooferlad, looking
[11:59] <dimitern> dooferlad, did you run the test with -race?
[11:59] <dooferlad> yes
[12:00] <dimitern> dooferlad, so the issue is easy to reproduce and verify the fix
[12:01] <dimitern> dooferlad, LGTM, thanks that was quick :)
[12:01] <dooferlad> dimitern: yea, just running the tests with -race showed it and then it was just a moment of "oh crumbs, that was dumb"
[12:02] <dimitern> :)
[12:02] <frobware> dooferlad: we should try and land the changes close together; just running make check on my merge from master and will propose
[12:02] <dooferlad> frobware: I hit $$merge$$ about two seconds before you said that.
[12:03] <frobware> c'est la view
[12:03] <frobware> vie...
[12:03] <dooferlad> frobware: it will take some time to test, so as long as we get to reviewing your code soon we will be fine.
[12:32] <frobware> dimitern, voidspace, dooferlad: http://reviews.vapour.ws/r/4133/ -- merge master into maas-spaces2
[12:32] <voidspace> frobware: did you land one yesterday?
[12:32] <frobware> voidspace: yes
[12:32] <voidspace> frobware: ah yes, this one isn't as huge
[12:32] <voidspace> frobware: go for it
[12:32] <frobware> voidspace: that commit was also a blessed build.
[12:33] <frobware> voidspace: if there's one thing to look at its dependencies.txt
[12:33] <frobware> voidspace: I meant dependencies.tsv
[12:34] <voidspace> frobware: yeah, I looked - LGTM
[12:34] <voidspace> frobware: although we seem to be depending on stuff in people's own github repositories now
[12:34] <dimitern> frobware, looks good
[12:35] <dimitern> dooferlad, your fix should merge cleanly onto frobware's merge PR right?
[12:41] <frobware> dimitern: going to grab some lunch and then let's do devices... \o/
[12:41] <dimitern> frobware, sweet!
[13:05] <frobware> dimitern, voidspace, dooferlad: both merged. we should, in theory, get a blessed CI run now.
[13:07] <dimitern> frobware, let's hope we do :)
[13:13] <rogpeppe2> natefinch: ping
[13:31] <frobware> dimitern: whenever works for you let's sync
[13:31] <dimitern> frobware, in 15m ?
[13:32] <frobware> yep
[14:00] <dimitern> frobware, let's use the standup HO?
[14:01] <dimitern> frobware, well, last one we used anyway
[14:01] <frobware> ok
[14:24] <natefinch> rogpeppe: pong
[14:27] <mattyw> fwereade__, ping?
[14:35] <mup> Bug #1556113 opened: TestCleaner should have fired by now <ci> <go1.5> <go1.6> <intermittent-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1556113>
[14:35] <mup> Bug #1556116 opened: TestDeployBundleMachinesUnitsPlacement mismatch <ci> <gccgo> <ppc64el> <regression> <test-failure> <unit-tests> <juju-core:Incomplete> <juju-core maas-spaces2:Triaged> <https://launchpad.net/bugs/1556116>
[14:36] <fwereade__> mattyw, heyhey
[14:50] <mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
[14:59] <natefinch> ericsnow: let me know if you need help with that cards you took over from me
[15:02] <mup> Bug #1556137 changed: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
[15:05] <mup> Bug #1556137 opened: Juju 2.0: cannot connect to LXC container when deploying bundle with LXC container placement <oil> <juju-core:New> <https://launchpad.net/bugs/1556137>
[15:13] <mattyw> ericsnow, ping?
[15:13] <mattyw> ericsnow, do you know if the todo comment at the top of this file is currently being worked on? https://github.com/juju/juju/blob/master/cmd/juju/charmcmd/store.go
[15:14]  * ericsnow takes a look
[15:15] <ericsnow> mattyw: not really
[15:15] <mattyw> ericsnow, ok that's fine, I might have to end up doing some of it for the stuff I'm working on, wanted to make sure I wasn't going to be duplicating work
[15:15] <ericsnow> mattyw: I have a patch that accomplishes that but haven't had a chance to pursue landing it
[15:16] <mattyw> ericsnow, i'd be interested in seeing that if possible
[15:16] <ericsnow> mattyw: k, thanks for the heads up
[15:16] <ericsnow> mattyw: looking it up as we speak
[15:16] <mattyw> ericsnow, many thanks
[15:22] <ericsnow> mattyw: pretty sure this is the branch: https://github.com/ericsnowcurrently/juju/tree/resources-charmstore-client
[15:22] <ericsnow> mattyw: it isn't quite right at this point, but the key thing is the httpcontext package
[15:23] <ericsnow> mattyw: however, it looks like the new "charm" command would use it too, so it may make more sense in some other common repo
[15:29] <ericsnow> natefinch: #1556146
[15:29] <mup> Bug #1556146: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>
[15:29] <ericsnow> natefinch: bug #1556146
[15:29] <mup> Bug #1497801 changed: provider/joyent: data races <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1497801>
[15:29] <mup> Bug #1461961 opened: UniterSuite teardown fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1461961>
[15:29] <mup> Bug #1556146 opened: github.com/juju/juju/resource/api undefined: parseMediaType <ci> <go1.6> <regression> <xenial> <juju-core:Incomplete> <juju-core feature-resources:Triaged> <https://launchpad.net/bugs/1556146>
[15:32] <katco> ericsnow: natefinch: planning time
[15:34] <mattyw> ericsnow, thanks, I'll take a look
[15:39] <mup> Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
[15:39] <mup> Bug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
[15:48] <mup> Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
[15:48] <mup> Bug #1556155 changed: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
[16:00] <mup> Bug #1556152 opened: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556152>
[16:00] <mup> Bug #1556155 opened: worker/periodicworker data race <race-condition> <juju-core:Triaged> <https://launchpad.net/bugs/1556155>
[16:03] <natefinch> ericsnow: review a single character bug fix? http://reviews.vapour.ws/r/4135/diff/#
[16:09] <mup> Bug #1556152 changed: data race peergrouper.(*pgWorker).getMongoSpace() <race-condition> <juju-core:Invalid> <juju-core maas-spaces2:Fix Committed by dooferlad> <https://launchpad.net/bugs/1556152>
[16:09] <mup> Bug # opened: 1556153, 1556157, 1556161, 1556167, 1556171
[16:31] <HollyRain> does the Juju license is going to change? the issue is that at using a library like "juju/service", it does that all my code been AGPL
[16:31] <natefinch> HollyRain: very doubtful that the license will change
[16:33] <HollyRain> natefinch, well, at least there is an alternative to handle services: kardianos/service
[16:33] <HollyRain> in github.com
[16:36] <natefinch> HollyRain: if you mean github.com/juju/juju/service - anything under github.com/juju/juju is not really intended to be used as a general library
[16:36] <HollyRain> ok
[16:39] <mup> Bug #1556176 opened: TestCmdLine dial unix no such file or directory <ci> <go1.5> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556176>
[16:39] <mup> Bug #1556180 opened: MachineSuite.TestManageModelRunsRegisteredWorkers mismatch <go1.5> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1556180>
[16:39] <mup> Bug #1556183 opened: help text for list-controllers needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556183>
[16:51] <frobware> cherylj: ping
[16:52] <cherylj> frobware: in stand up, responses will be slow :)
[17:16] <frobware> voidspace: you still about?
[17:19] <voidspace> frobware: yup
[17:19] <frobware> voidspace: any joy with MAAS 2.0? I didn't get around to installing...
[17:20] <voidspace> frobware: not yet, recloning my vm and installing xenial - about to install a newer version of maas (different ppa) that may fix the bug
[17:20] <voidspace> frobware: did some diagnostic work with roaksoax and he thinks it might be fixed in this version
[17:27] <mup> Bug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
[17:30] <mup> Bug #1556207 changed: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
[17:31] <frobware> cherylj: we've made sure that maas-spaces2 is up to date w.r.t to master. if we get a clean CI build on maas-spaces2 we'd like to merge into master and continue the multi-NIC and MAAS 2.0 work elsewhere. Is master still locked down?
[17:33] <cherylj> frobware: yes, we want to merge perrito666's machine-provisioning-status before we unblock
[17:33] <cherylj> frobware: if your branch is ready, we can put it on the list to get shepherded in next
[17:34] <frobware> cherylj: waiting to see if the couple of fixes we did today give us a blessed CI run; should find out a bit later.
[17:37] <cherylj> frobware: okay, cool.  I'll keep an eye on it
[17:42] <mup> Bug #1556207 opened: 1.25.4: "tomb: dying" in all units <kanban-cross-team> <landscape> <juju-core:New> <https://launchpad.net/bugs/1556207>
[18:24] <katco> sinzui: hey, is this a spurious curse? http://reports.vapour.ws/releases#nate-minver
[18:31] <sinzui> katco: maybe. The lack of bless might be because the branch makes juju less reliable. The azure arm-bundle looks interesting. I can retest it
[18:32] <natefinch> spurious curse is the name of my goth metal band
[18:32] <katco> sinzui: thanks, i would appreciate it. i don't think there should be anything in there that would cause it to be less reliable
[18:32] <katco> sinzui: but appreciate your more informed opinion
[18:42] <mup> Bug #1556238 opened: Missing a Juju shell <juju-core:New> <https://launchpad.net/bugs/1556238>
[19:18] <mup> Bug #1556249 opened: help text for juju list-models needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556249>
[19:48] <mup> Bug #1556252 opened: help text for juju show-user needs improving <helpdocs> <juju-core:New> <https://launchpad.net/bugs/1556252>
[20:15] <marcoceppi> sinzui: is juju2 the name of the binary going forward?
[20:15] <marcoceppi> I noticed juju-core and juju are no longer listed and installing juju2 removes them
[20:21] <natefinch> marcoceppi: it's a vast underworld conspiracy
[20:28] <marcoceppi> well, it breaks the new charm and charm-tools command
[20:28] <marcoceppi> so I'd just like to align those packages
[20:29] <marcoceppi> it also means we can't install 1.25 and 2.0 sidebyside which completely kills this blog post from last week
[20:29] <marcoceppi> http://marcoceppi.com/2016/03/testing-juju-without-wrecking-juju/
[20:30] <marcoceppi> oh, jk, it doesn't break juju-core, just juju-core2
[20:30] <natefinch> marcoceppi: I'm 99% sure that we are supposed to be able to run them side by side.  WE've done a lot of work to enable that.
[20:30] <marcoceppi> I'm actually okay with that
[20:30] <marcoceppi> I'll jus tneed to update the packaging for charm and charm-tools
[20:31] <natefinch> marcoceppi: I think it's juju-core and juju (the latter being juju 2)
[20:31] <natefinch> marcoceppi: but I am certainly not the authority on these things
[20:31] <marcoceppi> natefinch: I upgraded and both versions are still there, I jus tneed to update the other packaging
[20:33] <natefinch> rick_h__, katco: charm publish --channel=stable cs:rabbit-22 --resources "foo-6 bar-3" ... this command seems to require that resource names not have spaces in them, in order to parse them in a single string like that.  Do we want to start to enforce that, or should we change this to be --resource foo-3 --resource bar-6?  or some third way?
[20:34] <katco> natefinch: yes, separate flags to mirror deploy
[20:34] <katco> natefinch: check out rick_h__ 's comment in the 1-pager
[20:34] <natefinch> katco: awesome.  I love consistency
[20:34] <katco> +1
[20:39] <marcoceppi> omg I just bootstrapped lxd \o/
[20:41] <natefinch> marcoceppi: huzzah
[20:57] <natefinch> katco: I kinda wish that for publish, it was --resource foo=3 --resource foo=5 ... but I understand that we're trying to make them like charm revisions, where it's part of the name
[20:57] <natefinch> s/foo=5/bar=5
[20:58] <katco> natefinch: yeah, i prefer = as well
[20:58] <katco> natefinch: but, precedent and all
[21:05] <katco> natefinch: ericsnow_afk: we don't need to do a standup
[21:05] <ericsnow> katco: k
[21:13] <sinzui> marco yes, juju2 is the package name. juju2 is also the name of binary.
[21:13] <sinzui> marcoceppi: if you havw juju-core and juju2 installed, you can use alternates to switch which Juju is /usr/bin/juju
[21:14] <marcoceppi> sinzui: right, it's just that juju2 removes some packages, including charm and charm-tools
[21:15] <sinzui> marcoceppi: it does? how?
[21:15] <natefinch> marcoceppi: hmm, that seems wrong.  It definitely shouldn't *remove* anything
[21:15] <sinzui> marcoceppi: a package cannot remove another package and it is intended to be co-installable.
[21:16] <perrito666> sinzui: cant a deb remove another if it is marked as conflicts or replaces?
[21:16] <marcoceppi> perrito666: yes
[21:16] <sinzui> perrito666: yes, replaces, but we don't use that. conflicts blocks and lets a user choose
[21:16] <marcoceppi> sinzui: juju2 removed juju which are depends on charm and charm-tools
[21:17] <perrito666> sinzui: I would re-check the package definition given what marcoceppi says
[21:17] <sinzui> marcoceppi: oh, I can remove that metapackage. we don't need it
[21:17] <marcoceppi> sinzui: which metapackage?
[21:17] <sinzui> juju is a metapackage marcoceppi. It hasn't been a real package in 4 years
[21:18] <natefinch> marcoceppi: welcome.... to the real world
[21:18] <perrito666> oh that is right, juju is to pull juju-core and juju-local right?
[21:18] <marcoceppi> sinzui: I know. but charm-tools, amulet, etc, depend on Juju
[21:18] <sinzui> right, and juju2 is really just juju2 now. no other deps
[21:19] <sinzui> marcoceppi: I think we need to drop the juju metapackage from the juju2 package. two source packages cannot provide it an be co-installable
[21:20] <natefinch> marcoceppi: what do charm-tools and amulet etc need from the juju package that isn't in core?
[21:20] <sinzui> marcoceppi: juju2 source package coul provide juju2-all or juju2-dev to get the authoring tools
[21:20]  * sinzui likes juju2-authors more than juju2-dev
[21:20] <marcoceppi> we just need juju installed whenever a user installs these tools
[21:21] <sinzui> marcoceppi: which juju needs to be install when someone installs those tools? if so, then shouldn't those package depend on juju-core or juju2?
[21:21] <marcoceppi> well either juju is fine
[21:21] <marcoceppi> just a juju
[21:21] <natefinch> marcoceppi: why do those tools need juju?
[21:21] <marcoceppi> hence the metapackage
[21:21] <marcoceppi> well, it's not a depends
[21:22] <marcoceppi> it's a Recommends
[21:22] <marcoceppi> the idea being that multiple things can provide a juju, so I'm just going to have it Recommend: juju2 || juju
[21:25] <sinzui> marcoceppi: the juju-core package we put in the ppa:juju/stable doesn't have a recommends or depends on amulet charm-tools. maybe the Ubuntu version of the package does
[21:29] <marcoceppi> sinzui:
[21:29] <marcoceppi> no amulet and charm-tools and charm recommends juju
[21:29] <marcoceppi> that way if you install them, you
[21:30] <marcoceppi> 'll get juju
[21:30] <marcoceppi> well, amulet depends on juju, the rest recommend it
[21:31] <sinzui> marcoceppi: okay, so amulet could "Depends: juju2 | juju-local"
[21:31] <marcoceppi> why juju-local? you mean juju-core?
[21:32] <sinzui> marcoceppi: yes, juju-core is fine for 1.x. I just assumed that a charm author would want local-provider
[21:33] <natefinch> OMG, so glad we dumped local provider for 2.0
[21:33] <sinzui> marcoceppi: I can add a metapackage to the new juju2 source package to install everything you think a charm-author needs.
[21:33] <sinzui> natefinch: \o/
[21:33] <sinzui> We can take half a day and close 200 bugs
[21:34] <sinzui> marcoceppi: also, we don't need to wait for the next release to remake the juju2 package to provide a metapackage for authors
[21:35] <ericsnow> natefinch: http://reviews.vapour.ws/r/4138/
[21:36] <marcoceppi> sinzui: well, I think juju2 should recommend the charm command
[21:36] <marcoceppi> sinzui: and charm depends on charm-tools
[21:36] <marcoceppi> and that'll all work
[21:39] <sinzui> marcoceppi: as in the charm package I see sitting in ppa:juju/devel... "Recommends: charm"
[21:40] <natefinch> what's the user-experience for "recommended" packages?
[21:40] <sinzui> natefinch: it will be installed, if it exists
[21:40] <natefinch> sinzui: so we're forcing every user of juju to install charm authorship tools?
[21:40] <sinzui> natefinch: the user can specify not to install recommends
[21:41] <sinzui> natefinch: I most often use recommends for cases where we know older ubuntu series don't have the optional package
[21:42] <natefinch> sinzui: I don't really see why juju would ever recommend charm authorship tools.  charm authors, in theory, should be like .1% or less of juju users
[21:42] <sinzui> natefinch: yeah, that is why I suggested a metapackage names charm-authors to be clear who wants the extra packages
[21:42] <natefinch> sinzui: agreed
[21:43] <natefinch> ericsnow: looking
[21:44] <natefinch> ericsnow: btw, thanks for tackling that..sorry you got burdened with the result of my misunderstanding.
[21:44] <ericsnow> natefinch: glad to do it
[21:45] <ericsnow> natefinch: it's all complicated by our usual high-coupling/low-encapsulation
[21:48] <natefinch> ericsnow: seems like we could use an AuthorizedCharm struct or something, that holds a CharmURL + macaroom
[21:48] <ericsnow> natefinch: I was totally thinking that the whole time :/
[21:48] <natefinch> ericsnow: or even slap a macaroom on the charm.URL struct
[21:48] <ericsnow> natefinch: yep
[21:49] <natefinch> blah
[21:58] <sinzui> perrito666: machine-provisioning-staus branch is merge
[21:58] <perrito666> sinzui: oh, you just made my weekend
[22:00] <natefinch> ericsnow: only had time for a half a review, sorry.  I'll finish up the rest later tonight.
[22:00] <natefinch> ericsnow: mostly looks good, just didn't get through it all.
[22:01] <ericsnow> natefinch: np
[22:01] <ericsnow> natefinch: thanks
[22:25] <mup> Bug #1556293 opened: Invalid volume ID <ci> <destroy-environment> <test-failure> <juju-core:New> <https://launchpad.net/bugs/1556293>
[22:31] <alexisb> anyone know how I make this go away:
[22:31] <alexisb> checking: go vet ...
[22:31] <alexisb> tools/lxdclient/client_instance.go:329: wrong number of args for format in Tracef call: 1 needed but 2 args
[22:32] <alexisb> I can build and run locally on my machine
[22:32] <katco> alexisb: what version of go are you compiling with locally?
[22:33] <alexisb> 1.6rc2
[22:34] <katco> alexisb: and CI is giving you this error?
[22:35] <perrito666> katco: I had the same
[22:35] <perrito666> alexisb: its a vet issue introduced by jam
[22:35] <alexisb> so I can build locally but the "go vet" check in the prepush script is failing
[22:35] <alexisb> perrito666, ah ok
[22:35] <alexisb> I will follow-up with him
[22:36] <perrito666> alexisb: just go to that line and delete the second argument to the Tracef
[22:36] <katco> alexisb: ah... yeah vet is separate than building, but it's probably because CI is using a different version of go than you
[22:36] <perrito666> katco: is CI running vet?
[22:36] <katco> alexisb: they change how vet works between versions sometimes
[22:36] <katco> perrito666: it should be
[22:36] <katco> perrito666: that should be blocking imo
[22:36] <katco> perrito666: and i thought it was
[22:36] <perrito666> katco: me too
[22:36] <perrito666> but apparently it isnt
[22:37] <katco> perrito666: i think it is, and CI is just using an older version of go
[22:37] <katco> perrito666: thus, the change jam made is fine
[22:37] <perrito666> katco: I thought go vet was catching that before
[22:37] <perrito666> odd
[22:37] <perrito666> in any case, it breaks with go 1.5
[22:38] <katco> perrito666: ci is building with 1.2.1 still
[22:38] <katco> alexisb: perrito666: lots o' things have changed between 1.2.1 and 1.5, let alone 1.6r2
[22:38] <alexisb> katco, not for 2.0
[22:38] <perrito666> that explains
[22:39] <alexisb> for trusty we build with 1.2.1, until 1.6 is officially in updates
[22:39] <alexisb> that did it perrito666
[22:39] <katco> alexisb: i think our CI workers are still using 1.2.1. sinzui can you comment?
[22:39] <katco> alexisb: i.e. the workers that $$merge$$ changes
[22:40] <sinzui> katco: oh, the merge job is using a trusty ami, so it is using go 1.2.1
[22:40] <perrito666> sinzui: mm, that is wrong for 2.0
[22:40] <katco> alexisb: ^^^ hence, go vet change made it in, but is incompatible with go1.6-r2
[22:40] <sinzui> katco: The release agreed to switch to ggo 1.6 nexgt week
[22:41] <sinzui> and that that time, we expect master to be blocked as we fix bugs
[22:45] <sinzui> katco: the merge job nor Juju's one Makefile does not specific how to install a version of go on a temporary instance in AWS. It gets the version from the Ubuntu release. so switching to xenial images will select golang (2:1.6-0ubuntu3)
[22:47] <katco> sinzui: understood, and that sounds correct. just trying to inform alexisb
[22:48] <katco> sinzui: by the by, how goes the retest of nate-minver?
[22:49] <sinzui> katco: it failed? but I am looking to it still as a substrate issue the same bundle passed on other substrates
[22:49] <katco> sinzui: oh, i thought you were going to retest with a higher timeout? does this mean we can merge into master?
[22:50] <sinzui> katco: I did  and we still timeout
[22:51] <katco> sinzui: ah ok. what do i need to do to get it landed into master? just wait for you guys to work your magic?
[22:51] <sinzui> katco: If am hoping to retest and provide good results, or find some reason why the banch fails
[22:52] <katco> sinzui: ok, when will you know more?
[22:52] <sinzui> maybe by morning. katco.
[22:53] <katco> ok ta sinzui
[23:01] <alexisb> sinzui, thanks for pushing hard to get releases out this week, have a great weekend!
[23:02] <sinzui> thank you alexis. you too
[23:31] <mup> Bug #1551276 changed: 2.0-beta2 stabilization <juju-core:Invalid> <https://launchpad.net/bugs/1551276>