[00:02] <veebers> wallyworld: fyi my initial test shows that the latest log forward changes has *fixed* the cpu/loop issue (wrt to logforwarding and what I saw previously)
[00:02] <wallyworld> veebers: yay, ty
[00:44] <axw> wallyworld: http://reviews.vapour.ws/r/5236/
[00:45] <wallyworld> looking
[00:48] <wallyworld> axw: lgtm, ta
[00:49] <mup> Bug #1602895 opened: log forwarding sends all messages on enabling <2.0> <juju-core:Triaged> <https://launchpad.net/bugs/1602895>
[00:51] <redir> This http://reviews.vapour.ws/r/5153/ is still longing for a shipit
[01:20] <axw> thumper: probably not going to have time to review your pubsub stuff today, will try to get to it tomorrow if nobody else does in the mean time
[01:20] <thumper> axw: that's fine, it isn't urgent
[01:26] <axw> wallyworld: log forwarder test panicking: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8407/artifact/artifacts/trusty-out.log/*view*/
[01:27] <wallyworld> damn, i wonder why use of dying channel didn't prevent that
[01:41] <natefinch> man, I really wish we'd stop using maps of name to struct everywhere... especially when the struct doesn't even contain the name :/
[02:29] <thumper> natefinch: like where?
[02:30] <natefinch> thumper: almost all the new cloud & credential stuff.  github.com/juju/juju/cloud.Cloud doesn't even have a Name field :/
[02:31] <natefinch> thumper: cloud.Credential has no Name field.
[02:31] <thumper> well, we know why
[02:31] <thumper> actually...
[02:32] <thumper> we could trivially add a Name in there with things like `yaml:"-"`
[02:32] <thumper> which means don't serialize this value
[02:32] <thumper> so the output stays clean
[02:32] <thumper> and we could add them in when parsing
[02:32] <thumper> just a thought
[02:33] <natefinch> thumper: the fact that our internal data structures are being dictated by serialization formats is a bad thing
[02:33] <thumper> it is a thing
[02:39] <natefinch> hmm... bootstrap sometimes letting you use the provider name rather than the cloud name is sort of annoying
[02:40] <natefinch> and by annoying, I mean confusing
[02:41] <natefinch> juju bootstrap foo lxd works, juju bootstrap foo ec2 does not.
[02:53] <natefinch> oops, heh... uh... wallyworld... bootstrapping lxd requires --upload-tools
[02:55] <wallyworld> natefinch: i miss the point?
[02:55] <wallyworld> also, lxd is a cloud name as well as a provider name
[02:55] <natefinch> wallyworld: just that I was only doing interactive if the user specified no other flags... but then you can't do interactive with lxd, because you need to specify --upload-tools
[02:56] <wallyworld> what happens if you don't?
[02:56] <natefinch> this wonderful error: ERROR failed to bootstrap model: cannot start bootstrap instance: tools info mismatch ({2.0-alpha1-xenial-amd64  b67c1484745bd58e7fac6ad672a7f6e45042ebef7a1e0e995f3f0f3c2baa7d33 18556414}, {2.0-alpha2-xenial-amd64  ceb165a45206eddadc06a7c986b44a3f76195c71a317d0c87810727c71bcc0f8 18073871})
[02:56] <wallyworld> that's a bug then
[02:56] <wallyworld> upload-tools should not be required
[02:57] <wallyworld> maybe the streams data is wrong
[02:58] <natefinch> hmm... I was under the impression that unless you were running a released version of the client, you always had to use upload-tools... but maybe that was only true if you needed the dev jujud
[02:59] <natefinch> I've just always used upload-tools
[02:59] <wallyworld> ok, so from dev yes, you need upload tools
[02:59] <wallyworld> but not for lxd in general
[02:59] <wallyworld> thre same applies for other clouds
[02:59] <natefinch> well right, and in this case, I don't care what binary the jujud uses
[03:00] <wallyworld> i'd have to check the rules - but the client and agent versions generally need to match
[03:02] <natefinch> that's probably what I'm hitting, yeah.  I guess that's ok.  It makes it a PITA to test though :)
[03:06] <wallyworld> yes it does
[03:06] <wallyworld> i just hack the juju version
[03:07] <natefinch> well, the problem is that the code is checking for a command line that is just "juju bootstrap" and what I need it to also accept it "juju bootstrap --upload-tools" ... now the question is, do we want that to trigger interactive mode in production, or only as a hack for development?
[03:08] <natefinch> ...and this is why I'd prefer to just have a flag for requesting interactive mode :D
[03:20] <wallyworld> interactive mode is for when there are not enoug positional args
[03:22] <wallyworld> axw: a small one http://reviews.vapour.ws/r/5237/
[03:23] <natefinch> wallyworld: should I go into interactive mode even if they specify flags, then?
[03:23] <wallyworld> yep
[03:24] <wallyworld> when we talked yesterday, it was about missing positional args i think
[03:24] <natefinch> wallyworld: ahh, ok, I misunderstood the spec, then.
[03:24] <wallyworld> the spec was/is unclear
[03:24] <wallyworld> i'm just giving my interpretation
[03:24] <wallyworld> i think it makes sense
[03:25] <wallyworld> althugh to start with, we could just limit interactive to no args or fags
[03:25] <wallyworld> flags
[03:25] <wallyworld> perhaps it's better to start out conseratively
[03:25] <wallyworld> no args or flags
[03:28] <wallyworld> but i can see that allowing --upload-tools and still doing interactive for no positional args would be desirable for dev
[03:30] <natefinch> I hate that juju help constraints doesn't work anymore
[03:30] <wallyworld> oh yeah, i wonder what happened
[03:31] <natefinch> a ton of the "help topics" were stripped out.  I don't know why
[03:32] <natefinch> also juju help placement... gone
[03:32] <wallyworld> :-(
[03:33] <natefinch> $ juju help topics
[03:33] <natefinch> basics          Basic Help Summary
[03:33] <natefinch> commands        Basic help for all commands
[03:33] <natefinch> global-options  Options common to all commands
[03:33] <natefinch> topics          Topic list
[03:33] <wallyworld> natefinch: i have to duck out, but how about interactive for juju "juju bootstrap", maybe special case --upload-tools if it makes it easier for dev?
[03:34] <natefinch> wallyworld: seems fine for now.  Hoestly, looking at the flags, there's almost no flags that would be a problem with interactive mode
[03:34] <wallyworld> --credential would be
[03:34] <wallyworld> as it doesn't make sense until you select a cloud
[03:34] <wallyworld> so i reckon start simple
[03:35] <natefinch> sure
[03:35] <wallyworld> then we can get the basics done and iterate
[03:37] <wallyworld> axw: i have to go to doctor, bbiab, if you review branch and i don't respond, i'm not ignoring you :-)
[03:40] <veebers> wallyworld: re: logfwd, what's the expected behaviour when forwarding isn't on at bootstrap but is toggled later on the track? Are backdated logs sent or just from the toggle point onwards sent?
[03:40] <veebers> I see it as an open question on that spec foc
[03:40] <veebers> doc*
[04:15] <axw> wallyworld: sorry I've had a very disrupted morning, looking now
[04:45] <natefinch> wallyworld: well, first pass, needs a bunch more tests, but you can bootstrap interactively if you already have credentials, at least. https://github.com/juju/juju/pull/5797
[04:50] <mup> Bug #1602935 opened: Juju 2.0 DB2 charm giving error while deployed using ZFS as storage backend   <juju-core:New> <https://launchpad.net/bugs/1602935>
[06:35] <mup> Bug #1602952 opened: provider/azure: we should be checking "provisioningState" on entities before adding relationships <azure-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1602952>
[07:32] <rogpeppe> jam: any chance you could take a look at http://reviews.vapour.ws/r/5166/ please? I'm just about to make some changes to that code and it would be much easier to work on the simpler version if you approve of it.
[07:53] <axw> rogpeppe wallyworld: http://reviews.vapour.ws/r/5232/ -- this is ready for review now, I think this one could do with both 2 sets of eyes on it
[07:53] <axw> fairly simple changes, but a lot of them
[07:53] <wallyworld> ok
[07:54] <rogpeppe> axw: is this what we've just been working on?
[07:54] <axw> rogpeppe: yes
[07:54] <axw> rogpeppe: it lacks migration at the moment, I'll work on that now
[07:54] <rogpeppe> axw: ah, i'd say the PR description is a bit misleading then
[07:54] <axw> rogpeppe: bleh, I updated the commit message but not the description
[07:54] <axw> fixing
[07:54] <rogpeppe> axw: it's quite a bit more than "allow empty username"
[07:55] <axw> rogpeppe: updated, I hope that's a bit better
[07:56] <rogpeppe> axw: s/rejiggered/rejigged/ ?
[07:57] <rogpeppe> axw: otherwise, looks good
[07:57] <axw> rogpeppe: apparently rejigger is an americanism, I've been infected
[07:58] <rogpeppe> axw: ha, and apparently "rejig" is a britishism
[07:59] <rogpeppe> axw: so rejigger looks fine - i just hadn't seen it before
[08:00] <axw> rogpeppe wallyworld: one bit of ugliness this change exposes: when you logout, any memory of what your current model is wiped; then when you login you have to set your current model again
[08:00] <rogpeppe> axw: that didn't happen before?
[08:01] <axw> rogpeppe: nope, we weren't ever wiping info from models.yaml on logout before. so you could logout as admin, login as bob, and admin's current-model will still be in models.yaml
[08:01] <rogpeppe> axw: ah, of course, because "current-account" was separate
[08:01] <axw> it won't be *used*, but it'll be there
[08:01] <axw> then if you logout and log back in, you'll be back on the same
[08:01] <wallyworld> hmm, that may be ok perhaps? if there's no current model, we prompt right?
[08:01] <rogpeppe> axw: hmm, why are we wiping info from models.yaml now?
[08:02] <axw> rogpeppe: because now models.yaml is entirely linked to the logged in user
[08:02] <axw> wallyworld: we tell the user what to do ("Please use "juju models" ... and "juju switch")
[08:03] <wallyworld> axw: maybe if there's just the one model we should switch automatically
[08:03] <rogpeppe> axw: perhaps the current model info should include both username and model name
[08:03] <rogpeppe> axw: otherwise there's no way to be switched to a model that's under a different username, right?
[08:04] <axw> rogpeppe: that'll be part of the model name, when I update/land my other change: i.e. current-model will have the format "modeol-owner/model"
[08:05] <rogpeppe> axw: ah, in which case the problem you mention above won't happen, right?
[08:05] <rogpeppe> axw: because models.yaml won't be linked to the logged in user
[08:06] <axw> rogpeppe: I guess, if we want to say that current-model doesn't change between users
[08:06] <axw> rogpeppe: that seems a bit odd to me though
[08:06] <rogpeppe> axw: i think it's better than wiping it
[08:06] <axw> maybe it's ok
[08:06] <axw> yeah, probably
[08:06] <axw> alright, I'll just take out the code that wipes models.yaml for now then
[08:06] <rogpeppe> axw: i think that it would be surprising if i couldn't log out, then log back in to the same model
[08:07] <rogpeppe> axw: 'cos logged in user is almost entirely orthogonal to what model's currently being used.
[08:09] <wallyworld> rogpeppe: what happens if i log back in and new user can't access model?
[08:09] <rogpeppe> wallyworld: then you'll get permission denied
[08:10] <rogpeppe> wallyworld: seems better than just forgetting it always
[08:10] <wallyworld> seems reasonable i think
[08:11] <wallyworld> axw: changes look ok to me, if rogpeppe is happy that it solves his problem and allows beta12 this week to fit their requirements
[08:11] <rogpeppe> wallyworld: it doesn't solve the problem in itself, but it lays the groundwork for solving it
[08:12] <frobware> dooferlad, voidspace, babbageclunk: PTAL @  http://reviews.vapour.ws/r/5235/ and http://reviews.vapour.ws/r/5234/
[08:12] <rogpeppe> wallyworld: and it seems like a good change in general
[08:12] <axw> rogpeppe: well you can craft a file, like you could before. there are more changes due of course tho
[08:12] <wallyworld> rogpeppe: agreed, sorry i just meant that it unblocks you
[08:13] <rogpeppe> axw: have you tried crafting a file with these changes in place?
[08:13] <rogpeppe> axw: i'm not sure if it'll work
[08:14] <axw> rogpeppe: yes, it does. I don't have an idm to test with, but I verified that it tried to connect without a user/pass
[08:14] <rogpeppe> axw: you do have an idm to test with
[08:14] <rogpeppe> axw: identity-url: https://api.jujucharms.com/identity
[08:15] <axw> okey dokey
[08:19] <voidspace> frobware: can take a look
[08:19] <voidspace> frobware: I still need a full review on http://reviews.vapour.ws/r/5162/ :-p
[08:21] <voidspace> frobware: in the first one, was prefix already unused by all those methods?
[08:21] <voidspace> looks like it
[08:21] <frobware> voidspace: yes - was tidying up
[08:21] <voidspace> frobware: cool
[08:22] <voidspace> that first one is nice and easy
[08:22] <voidspace> frobware: LGTM
[08:23] <frobware> voidspace: will look at your PR after standup
[08:23] <voidspace> cool
[08:23] <voidspace> I'm looking at your second one
[08:25] <voidspace> frobware: I wish we could encapsulate all this in a general purpose library
[08:25] <voidspace> frobware: it's extremely precious knowledge
[08:25] <frobware> voidspace: yes, it has got to that stage now. It's quite different from the original sed script we started with.
[08:26] <voidspace> frobware: second one LGTM as well - modulo the comment from babbageclunk
[08:26] <frobware> voidspace: thanks
[08:28] <jam> rogpeppe: looking
[08:28] <rogpeppe> jam: thanks a lot
[08:30] <jam> rogpeppe: so does it still try the first one and then with a delay try the rest?
[08:30] <rogpeppe> jam: it still tries all the addresses
[08:31] <rogpeppe> jam: it just doesn't fall back to the bootstrap config (provider-specific) connection
[08:31] <jam> sure, but I thought the parallel try was the thing that did it, but that got removed if I'm reading the diff correctly.
[08:31] <rogpeppe> jam: no, there are two levels of parallel tries
[08:31] <rogpeppe> jam: the API connection code also does it
[08:32] <rogpeppe> jam: the Try in the top level connection was entirely for the bootstrap config fallback
[08:33] <frobware> babbageclunk: sync?
[08:33] <babbageclunk> frobware: oh, torry
[08:33] <babbageclunk> sorry
[08:43] <jam> ah good
[08:44] <urulama> wallyworld: could you give your +1 on http://reviews.vapour.ws/r/5232/ if it's ok? or if not, to fix it before beta12?
[08:47] <axw> wallyworld: nearly forgot about this one https://github.com/juju/romulus/pull/52
[08:57] <jam> rogpeppe: lgtm
[08:58] <rogpeppe> jam: thanks!
[09:14] <axw> rogpeppe: I've added migration code to my PR, and dropped the code that was wiping models.yaml. should be good to go once it's stamped
[09:14] <rogpeppe> axw: ah, i'll take another look
[09:22] <rogpeppe> axw: added a couple more review comments
[09:23] <axw> rogpeppe: I think adding a test is a waste of time. I've manually tested it, and the code will be deleted as soon as the beta is out (which is imminent)
[09:24] <rogpeppe> axw: fair enough, just a thought
[09:24] <rogpeppe> axw: as long as you've actually run the code :)
[09:25] <axw> rogpeppe: thanks. yeah I did, it was broken the first two times :p
[09:26] <rogpeppe> axw: BTW ignore my first comment (sorry, can't work out how to reply on reviewboard) - i hadn't realised the lines moved between types.
[09:26] <axw> rogpeppe: no worries - it's not super clear. thanks
[09:26] <axw> rogpeppe: I'm going to look at temporarily disabling the romulus dependency to break the cycle
[09:26] <rogpeppe> axw: what do you mean by "disabling the dependency" ?
[09:27] <axw> rogpeppe: well, just stop importing the commands actually
[09:27] <rogpeppe> axw: the "push temporary branch" thing works pretty well actually
[09:28] <rogpeppe> axw: wait until you've got a LGTM on both romulus and the juju-core branch before doing it though
[09:28] <rogpeppe> axw: and means you don't need to change the code at all
[09:29] <axw> rogpeppe: how does one push a temporary branch? don't I need to be able to write to master?
[09:30] <rogpeppe> axw: you'll need the capability to make new branches in romulus
[09:30] <rogpeppe> axw: you can ask ashipika1 to do it if you can't
[09:31] <axw> rogpeppe: which I don't have. I think I'll have to come back later, I think ashipika1 has gone back offline
[09:31] <axw> need a review first anyway
[09:31] <ashipika1> axw: who is offline?
[09:32] <axw> ashipika1: or not :) I just saw you're offline on canonical
[09:32] <axw> err
[09:32] <ashipika1> axw: ah, who know.. i have a probabilistic internet connection..
[09:32] <axw> not even there, my IRC client is telling lies
[09:33] <ashipika> axw: you need a feature branch?
[09:33] <axw> ashipika: yes please
[09:33] <ashipika> axw: pick a name, please :)
[09:34] <axw> ashipika: modelcmd-no-account
[09:34] <ashipika> axw: done
[09:35] <ashipika> axw: enjoy :)
[09:35] <axw> ashipika: ta
[09:36] <axw> ashipika: I'm not going to be able to push to that though am I? can you please push my change over there.
[09:40] <ashipika> axw: https://github.com/juju/romulus/pull/53  ?
[09:40] <axw> ashipika: yes, but the lander's not going to like it because juju/juju's API changed
[09:41] <ashipika> axw: shall i (ab)use the green button?
[09:41] <axw> ashipika: ah, if you have that then yes please
[09:41] <ashipika> axw: done :)
[09:41] <axw> ashipika: thanks
[10:45] <rogpeppe> jam: do you think that https://github.com/juju/juju/pull/5719 can land even though it doesn't fix one of the blocking critical bugs?
[10:49] <jam> rogpeppe: I would check with Cheryl about that more than myself. If they are trying to stabilize this is more likely to cause a regression than others
[10:56] <rogpeppe> jam: fair enough. FWIW it does fix at least one bug I've seen recently, just not any of the critical blockers.
[10:58] <rogpeppe> jam: and if it doesn't land, getting branches that depend on it landed for beta12 might be hard.
[11:05] <frobware> voidspace: still owe you your review - sidetracked...
[11:51] <rogpeppe> trivial dependency update anyone (stops juju-core depending on an external feature branch)? https://github.com/juju/juju/pull/5798
[11:54] <frobware> babbageclunk: could you take another look over http://reviews.vapour.ws/r/5235/
[11:57] <babbageclunk> frobware: LGTM
[11:59] <frobware> rogpeppe: just the one question, see RB
[12:00] <mup> Bug #1603060 opened: upgrade-charm arguments don't support tilde expansion <juju-core:New> <https://launchpad.net/bugs/1603060>
[12:07] <rogpeppe> frobware: thanks
[12:07] <rogpeppe> frobware: i just replied
[12:07] <rogpeppe> frobware: it seems that it was a left-over dep
[12:08] <rogpeppe> frobware: unless you can find somewhere where that package is used
[12:08] <frobware> rogpeppe: Was just (trying to) being diligent. Wanted to ensure that it was not accidental.
[12:09] <rogpeppe> frobware: yeah, it made me think again too
[12:10] <frobware> dooferlad: one for you - https://c9.io/blog/great-news/
[12:11] <frobware> dooferlad: you'll get bugs faster with prime! :)
[12:39] <dooferlad> frobware: I need coffee, but I would also like to talk through our current LXD bugs. Can you join a hangout in ~5 minutes?
[13:09] <frobware> dooferlad: yep
[13:12] <dooferlad> frobware: team hangout?
[13:12] <frobware> yep
[13:34] <frobware> dooferlad: http://reviews.vapour.ws/r/5040/
[13:46] <frobware> dooferlad: https://bugs.launchpad.net/juju-core/+bug/1566801
[13:46] <mup> Bug #1566801: LXD containers /etc/network/interfaces as generated by Juju  gets overwritten by LXD container start <cdo-qa-blocker> <landscape> <network> <juju-core:In Progress by frobware> <https://launchpad.net/bugs/1566801>
[13:47] <frobware> dooferlad: https://bugs.launchpad.net/juju-core/+bug/1600546
[13:47] <mup> Bug #1600546: lxd subnet setup by juju will interfere with openstack instance traffic <network> <sts> <juju-core:Triaged> <nova-compute (Juju Charms Collection):New> <https://launchpad.net/bugs/1600546>
[14:05] <alexisb__> dooferlad, sorry, I have a conflict
[14:12] <dooferlad> frobware: not in a meeting if you want to talk again.
[14:12] <frobware> dooferlad: need to resolve my conflict on my other PR first
[14:13] <dooferlad> frobware: sounds good
[14:18] <mup> Bug #1559299 opened: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
[14:19] <rogpeppe> anyone got an idea what the failure is here, and whether it has anything to do with the branch being landed? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8414/console
[14:22] <rogpeppe> mgz, sinzui: ^
[14:22] <rogpeppe> i've tried again in hope that it's just a sporadic infrastructure failure
[14:22] <mgz> rogpeppe: looking
[14:22] <rogpeppe> mgz: t
[14:22] <rogpeppe> mgz: ta, even
[14:24] <mgz> rogpeppe: see trusy-err.log
[14:24] <mgz> rogpeppe: juju/api_test.go:132: undefined: noBootstrapConfig
[14:24] <rogpeppe> where can i see that file?
[14:24] <mgz> rogpeppe: juju/api_test.go:132: too many arguments in call to newAPIConnectionFromNames
[14:25] <mgz> it's in the job artifacts
[14:25] <mgz> so, up one level from /console
[14:25] <mgz> at the top of the page
[14:25] <mgz> we're still looking at making this output clearer than it is at present
[14:26] <rogpeppe> mgz: ah, so you don't see test failures in the console output any more.ir
[14:26] <mgz> just for now. they should be there again at some point.
[14:27] <rogpeppe> what a great failure mode the IRC client has - if you're typing under heavy load, the input box goes into a state where text comes out randomly
[14:28] <natefinch> rogpeppe: I've seen that.  not sure if it's IRC or linux
[14:28] <rogpeppe> natefinch: i blame the app
[14:29] <rogpeppe> mgz: it's in trusty-out.log, not trusty-err.log
[14:29] <mgz> rogpeppe: both have revelent things
[14:29] <rogpeppe> mgz: oh yeah
[14:29] <mgz> splitting them is actually a little confusing
[14:30] <rogpeppe> mgz: it's really hard to see the pertinent data in trusty-err.log
[14:30] <mup> Bug #1559299 changed: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
[14:30] <mgz> rogpeppe: yep
[14:31] <rogpeppe> mgz: can you monitor the build artifacts in real time like the console log?
[14:31] <rogpeppe> mgz: i find it really useful to see a test error before all the tests have completed
[14:33] <mgz> rogpeppe: nope, that's another problem with parallel setup at present
[14:33] <mup> Bug #1559299 opened: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Triaged> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
[14:34] <rogpeppe> mgz: is there any way to abort a jenkins run that's already started?
[14:34] <rogpeppe> mgz: i know this one's gonna fail and i've fixed the issue already http://juju-ci.vapour.ws:8080/job/github-merge-juju/8417/
[14:34] <mgz> there is, but the safest way is to ask me
[14:34] <mgz> okay, I can do that
[14:34] <rogpeppe> mgz: please, martin, could you? :)
[14:34] <rogpeppe> mgz: thanks
[14:36] <babbageclunk> So, looking at bug #1602192 - why might systemctl be reporting that / didn't mount, when it's definitely available?
[14:36] <mup> Bug #1602192: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:In Progress by 2-xtian> <https://launchpad.net/bugs/1602192>
[14:46] <frobware> babbageclunk, dooferlad, voidspace: can you take another look over http://reviews.vapour.ws/r/5234/. My other PR gave me a few conflict so had to rebase.
[14:48] <mup> Bug #1600237 changed: ErroredUnit: 0 is in state cannot complete machine configuration: model configuration has no authorized-keys <deploy> <regression> <juju-core:Fix Released by axwalk> <https://launchpad.net/bugs/1600237>
[14:50] <babbageclunk> frobware: lgtm
[14:56] <rogpeppe> anyone got any idea why a controller-only login doesn't send userinfo back in the response?
[14:56] <rogpeppe> apiserver/admin.go:150: 	if isUser && !serverOnlyLogin {
[15:13] <voidspace> frobware: still need that review?
[15:14] <frobware> babbageclunk: actually, yes. just to be on the safe side as there were quite a few conflicts
[15:14] <frobware> voidspace: that ^ was supposed to go to you :)
[15:14] <babbageclunk> frobware: I already did! :)
[15:14] <frobware> babbageclunk: the bridgescript.go is back - another push fixed that. was lost in my conflict resolution
[15:15] <voidspace> frobware: ok
[15:39] <frobware> oh, interesting. last 12-24 hours no $(juju add-machine lxd:0) on MAAS 1.9. Just tried MASS 2.0 and it worked. Coincidence? Or is 1.9 broken?
[15:42] <mup> Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
[15:46] <voidspace> frobware: a couple of minor issues - but feel free to drop them if you don't think it's worth it
[15:46] <babbageclunk> frobware: I guess I should really have opened an issue for that.
[15:47] <frobware> voidspace: const as in some constant list someplace?
[15:47] <frobware> voidspace: I was trying for locality; in some case we remove mtu, in other mtu+others.
[15:48] <voidspace> frobware: I meant the same as you do for BRIDGE_OPTIONS
[15:48] <voidspace> frobware: but if you don't feel it aids readability then feel free to drop it
[15:48] <mup> Bug #1603133 changed: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
[15:49] <frobware> voidspace: yep, but chatted with babbageclunk about this earlier. Didn't want the constant to be updated (in some future change) without really understanding the implication, hence the locality
[15:49] <voidspace> ok
[15:50] <frobware> voidspace: regarding performance, ... don't think it's an issue here
[15:50] <frobware> voidspace: this script will only ever run once
[15:50] <voidspace> heh
[15:50] <voidspace> I just like to see the *right* data type used...
[15:50] <voidspace> but I don't really care
[15:50] <voidspace> it's not an optimisation it's a semantic correction
[15:50] <frobware> voidspace: and as long it is the same in python 2 & 3 I'm happy to change it
[15:50] <voidspace> it's an unordered collection not a sequence
[15:51] <voidspace> frobware: it is
[15:51] <voidspace> just wrap a set constructor round it
[15:51] <frobware> voidspace: given the nature of this code anything I don't have to change make me delirious.
[15:51] <voidspace> :-)
[15:51] <voidspace> up to you, it's such a minor detail
[15:52] <frobware> voidspace: in a follow-up, sure. but have been testing it as-is so don't want to start over (though I cannot believe it would be an issue)
[15:52] <frobware> voidspace: but thanks anyway
[15:54] <mup> Bug #1603133 opened: Application Get api call doesn't return deployed series for multi-series charms <juju-core:New> <https://launchpad.net/bugs/1603133>
[16:02] <frobware> voidspace: as in http://pastebin.ubuntu.com/19376777/ ?
[16:11] <babbageclunk> voidspace, frobware: no, just write {'address', 'gateway'...}
[16:11] <frobware> babbageclunk: yep, done already. :)
[16:12] <frobware> babbageclunk: http://reviews.vapour.ws/r/5234/diff/4-6/
[16:17] <babbageclunk> frobware: I've already clicked Ship It twice on that. I think it looks good!
[16:18] <frobware> babbageclunk: yep. thanks. was just confirming my SET LITERAL! :)
[16:18] <babbageclunk> frobware: :)
[16:39] <natefinch> super easy review anyone? http://reviews.vapour.ws/r/5242/diff/#
[16:42] <natefinch> cherylj: ^ ?
[16:42] <frobware> natefinch: reviewed
[16:42] <natefinch> frobware: thanks!
[16:44] <natefinch> alexisb__: I have a fix for hatch's bug, should I mark it critical and submit it, or... ?
[16:45] <alexisb__> yes please
[16:46] <hatch> ooo critical :)
[16:46] <hatch> thanks natefinch
[16:49] <natefinch> hatch: welcome.
[16:49] <natefinch> hatch: luckily it was as easy as it looked :)
[16:50] <hatch> haha great!
[16:52] <perrito666> we are spoiling hatch, he got 2 bugs in a week
[16:52] <hatch> LOL
[16:52] <hatch> maybe I just work on important stuff ;)
[16:53] <urulama> no worries. he's spoiled already.
[16:53] <urulama> :)
[16:53] <hatch> hahahaha
[16:53] <perrito666> hatch: nah, you are using some of these canadian superpowers of yours
[16:54] <hatch> a well placed "sorry" goes a long way
[16:55] <perrito666> nonsense, witchcraft I say
[16:55] <hatch> lol
[16:56] <urulama> hatch: do keep an eye on that branch and test it with gui when it lands, please, just in case to catch the beta12 train with any last changes
[16:56] <urulama> i'm sure it'll be fine though
[16:56] <hatch> urulama: yep will do!
[16:56] <urulama> ty
[17:08] <cherylj> natefinch: just fyi - for bug 1603133 , you'll also need to give it the blocker tag to use the fixes-1603133$$
[17:08] <mup> Bug #1603133: Application Get api call doesn't return deployed series for multi-series charms <juju-core:In Progress by natefinch> <https://launchpad.net/bugs/1603133>
[17:09] <cherylj> sigh, missed the first $$.  But whatevs
[17:18] <hatch> natefinch: just wanted to point out that https://github.com/juju/juju/pull/5801 failed building
[17:24] <cherylj> hatch: retrying...
[17:24] <hatch> great
[17:45] <mup> Bug #1578059 opened: Default route not coming up with juju 1.25.5 and bonding <canonical-bootstack> <juju-core:New> <MAAS:Incomplete> <MAAS 1.9:Incomplete> <https://launchpad.net/bugs/1578059>
[17:46] <natefinch> cherylj, hatch: thanks
[17:52] <natefinch> it's so much more nerve wracking watching jenkins now...
[17:53] <natefinch> there's no play by play update, you just have to wait for the newspaper in the morning to tell you if your team won or lost
[17:56] <hatch> haha
[17:56] <perrito666> natefinch: oh? what changed?
[17:58] <natefinch> perrito666: we're running multiple unit tests in parallel (well, in theory, I think right now, multiple == 1), and so they can't/don't update the jenkins console output with the test output.  It's only when the test run is done that the test output is linked to by the jenkins job page
[17:58] <natefinch> perrito666: so like, here, the tests are running, but you don't get real-time output of go test anymore: http://juju-ci.vapour.ws:8080/job/github-merge-juju/8421/console
[17:58] <katco> cherylj: maybe we should send out another email on this =|
[17:59] <natefinch> heh yeah, seems like everyone missed that little caveat at the end
[18:00] <perrito666> at least I did
[18:02] <natefinch> this is like when they try to slip in some bad news behind an otherwise banal headline:
[18:02] <natefinch> Pokemon go now accepts bitcoin!
[18:02] <natefinch> ᵃᶫˢᵒ ᴼᵇᵃᵐᵃ ʰᵃˢ ᵈᵉᶜᶫᵃʳᵉᵈ ᵐᵃʳˢʰᵃᶫ ᶫᵃʷ
[18:05] <perrito666> pokemon accepting bitcoin is not banal, check your priorities dude
[18:05] <natefinch> haha
[18:05] <natefinch> TestResumeTransactionsFailure failed... yay
[18:05] <natefinch> whelp. half hour of the test machine's time wasted.  Let's retry
[18:30] <mup> Bug #1603176 opened: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
[18:37] <mup> Bug #1603176 changed: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
[18:45] <perrito666> redir: ping?
[18:45] <redir> pong
[18:45] <redir> perrito666:
[18:45] <perrito666> redir: was it remove user you where working on?
[18:46] <mup> Bug #1603176 opened: juju debug-log returns not logged-error <juju-core:New> <https://launchpad.net/bugs/1603176>
[18:46] <perrito666> if so, did that ever land?
[18:46] <redir> perrito666: yup
[18:46] <redir> nope
[18:47] <perrito666> ah, ok, tx :) ill stop looking for it then :p
[18:47] <redir> perrito666: http://reviews.vapour.ws/r/5153/ I think the shipit button is broken or something;)
[18:48] <redir> I am trying to parse the latest review.
[18:48] <redir> the client side bits are just waitin for it
[18:48] <redir> perrito666: ^^
[18:52] <perrito666> redir: oh I can't hear you, I am entering into a tunnerl, shh shh <toot><toot><toot>
[18:52] <redir> :)
[18:53] <redir> I think we're really close
[18:56] <natefinch> hatch: fix committed :)
[19:00] <alexisb__> thank you natefinch
[19:01] <alexisb__> redir, how are you feeling?
[19:03] <hatch> natefinch: thanks!
[19:07] <mup> Bug #1593850 changed: Deployment stuck in "Pending" for all containers <cdo-qa> <cdo-qa-blocker> <juju-core:Invalid> <https://launchpad.net/bugs/1593850>
[20:18] <redir> alexisb__: meh. Still drugged up. If I don't feel better by the weekend I'll go to the doc next week.
[20:28] <mup> Bug #1603202 opened: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
[20:37] <mup> Bug #1603202 changed: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
[20:38] <rick_h_> redir: did you catch my cold?
[20:40] <mup> Bug #1603202 opened: kill-controller didn't do anything <juju-core:New> <https://launchpad.net/bugs/1603202>
[20:40] <redir> rick_h_: caught something somewhere.
[20:42] <redir> nose,ears,throat. Hopefully it'll be gone soon. I got a decent night sleep after a delayed flight. Another good night and I hope to report I'm on the upswing.
[20:58] <mup> Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
[21:01] <mup> Bug #1603208 changed: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
[21:10] <mup> Bug #1603208 opened: (Windows unit test) ConfigSuite.TestConfigNonExistentPath failure in config_test.go <blocker> <ci> <unit-tests> <windows> <juju-core:Triaged by axwalk> <https://launchpad.net/bugs/1603208>
[21:28] <mup> Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
[21:31] <mup> Bug #1602192 opened: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
[21:40] <mup> Bug #1602192 changed: deploy 30 nodes on lxd, machines never leave pending <lxd> <juju-core:Invalid by 2-xtian> <lxd (Ubuntu):New> <https://launchpad.net/bugs/1602192>
[21:58] <mup> Bug #1603221 opened: Charms utilizing storage fail on LXD <juju-core:New> <https://launchpad.net/bugs/1603221>
[22:02] <wallyworld> rick_h_: we are still in release standup, running a bit late
[22:02] <rick_h_> wallyworld: ah ok ty for heads up
[22:03] <wallyworld> we didn't abandon you :-)
[22:03] <rick_h_> ...yet :p
[22:40] <mup> Bug #1603228 opened: Juju does not support simplestreams for Azure-ARM <azure-provider> <simplestreams> <streams> <juju-core:Triaged> <https://launchpad.net/bugs/1603228>
[23:10] <wallyworld> niemeyer: hey, we want to use the latest and greatest mgo stuff in juju for beta12 (with the E1100 fix). but the fix is landed in a v2-unstable branch and so that now means a lot more than a godeps update to get it in. is there any chance you can merge the work to the v2 branch?