[00:34] <rick_h_> ty redir for all the help!
[00:37] <redir> np. I made a joke on standup about joining the docs team. Nobody laughed.
[00:37] <redir> seriously though, always happy to help with whatever.
[00:37] <anastasiamac> redir: i did not laugh. i thought it was scary :D
[00:38] <redir> anastasiamac: :)
[00:39] <anastasiamac> but seriously - awesome job on release notes! tyvm to all involved \o/
[00:39] <redir> Use the source, Luke.
[00:40] <anastasiamac> redir: haha :D this is good. no lightsabers plz
[00:59] <alexisb> wallyworld, do we need to add a blurp in the "whats new for GA" on new bootstrap command
[00:59] <alexisb> sequence
[01:02]  * redir eod
[01:02] <alexisb> redir, thank you for the release notes help today
[01:02] <alexisb> I owe you a beer in december
[01:02] <alexisb> or wine :)
[01:03] <redir> I'll take the beer or wine:) but it really wasn't a big deal.
[01:26] <alexisb> wallyworld, ping
[01:27] <alexisb> thumper, I may need you if wallyworld is mia
[01:31] <alexisb> menn0, maybe??? someone??
[01:34] <menn0> alexisb: hello?
[01:34] <wallyworld> thumper: here now
[01:35] <wallyworld> alexisb: sorry, was afk getting coffee
[01:35] <wallyworld> bootstrap is all new in 2.0 anyway, compared with 1.25
[01:35] <wallyworld> not sure we need anything special for yesterday's change
[01:44] <thumper> wallyworld: ping
[01:44] <wallyworld> thumper: hey, just in a call
[01:44] <thumper> ack
[01:44] <thumper> I'll idle in the hangout
[01:48] <wallyworld> thumper: hopefully will be there soon
[01:54] <alexisb> thumper, wallyworl is occupied
[01:54] <thumper> :)
[01:54] <alexisb> feel free to join the party if you want :)
[02:00] <thumper> where's the party?
[02:11] <alexisb> wallyworld, thumper you guys need to stay close
[02:12] <wallyworld> close to each other?
[02:12] <thumper> hmm...
[02:12] <alexisb> well you guys do that naturally ;)
[02:12] <alexisb> close to the channel
[02:27] <menn0> thumper: https://github.com/juju/juju/pull/6449
[02:27] <menn0> thumper: that's one of the intermittent failures
[02:27]  * thumper looks
[02:37] <menn0> thumper: crap. wrong branch. proposing again.
[02:37] <thumper> :)
[02:38] <menn0> thumper: with the new workflow does the bot check if someone's reviewed it?
[02:41] <alexisb> ah wallyworld did you see my request about new for GA release notes
[02:42] <wallyworld> alexisb: the bootstrap stuff? did you see my reply?
[02:42] <alexisb> no
[02:42] <alexisb> well so something new is new fore GA
[02:42] <alexisb> and I htink it would be good to note that the this main command as changed
[02:43] <wallyworld> isn't there info already that bootstrap is new?
[02:43] <wallyworld> i'll take a look
[02:43] <alexisb> k
[02:43] <alexisb> wallyworld, there could be, the notes all blur after multiple days of looking at them
[02:44] <wallyworld> understood, i'll take a look
[02:44] <wallyworld> still be held hostage by thumper
[02:49] <alexisb> ok all, looking for haiku ideas for the release announcement
[02:49] <wallyworld> alexisb: looks like someone, probs rick, has already edited all the bootstrap examples in the notes
[02:49] <wallyworld> i like haikus but am bad at making them up
[02:51] <alexisb> wallyworld, thumper is there  an easy way to get # of bugs fixed since 11/6/2015
[02:51] <alexisb> or 6/11/2015 if you are not a US persone ;)
[02:51] <alexisb> from launchpad
[02:51] <wallyworld> you mean the rest of the world?
[02:52] <wallyworld> i think if you do a filtered query and specify fix committed, it tells you the count
[02:52] <wallyworld> in the results
[02:52] <wallyworld> but we'll need to include juju-core also
[02:52] <wallyworld> not just juju
[02:52] <wallyworld> as we switch projects
[02:55] <alexisb> OK, haiku idea to kick us off:
[02:56] <alexisb> Juju 2
[02:56] <alexisb> So Amazing
[02:56] <alexisb> Models Big Software
[03:07] <alexisb> F*%$&#% Amazing
[03:07] <alexisb> Model big software, easy!
[03:07] <alexisb> Juju 2 is here!
[03:09] <balloons> alexisb, I used http://reports.vapour.ws/dashboard/juju/all/Critical,High,Medium,Low,Undecided,Wishlist/2015-11-06/2016-10-13
[03:09] <balloons> giving 845.. not sure if I feel good or bad about that number
[03:11] <alexisb> seems like it should be higher :)  and yeah
[03:14] <alexisb> man this timezone is boring
[03:15] <balloons> ::yawn::
[03:16] <alexisb> :)
[03:16] <balloons> ^^ it's a pun.. bored and tired!
[03:16] <balloons> boring is good though.. Feels less chaotic
[03:16] <alexisb> yes
[03:23] <thumper> alexisb: Today we are done, Thank God Juju 2 is out, now where is my drink!
[03:24] <alexisb> :)
[03:24] <alexisb> there we go
[03:27] <alexisb> 2.0, so good
[03:27] <alexisb> models, controllers, oh may!
[03:27] <alexisb> big software for all
[03:31] <cmars> service application
[03:31] <cmars> model controller switcharoo
[03:31] <cmars> cant stop juju 2
[03:31] <balloons> thumper, wallyworld, any thoughts on # of external contributors?
[03:31] <balloons> or other interesting number nonsense?
[03:31] <wallyworld> hmmmm
[03:31] <balloons> at this hour, it's all handwavy
[03:31] <thumper> more than one
[03:31] <alexisb> lol
[03:32] <alexisb> yeah contributers will be a be low given the size of the project
[03:32] <wallyworld> and complexity
[03:32] <alexisb> cmars, I love switcharoo
[03:34] <alexisb> lines of code, maybe??
[03:35] <balloons> I should do an infographic
[03:35] <balloons> man, if things weren't so crazy, this would be more fun
[03:35] <alexisb> :)
[03:36] <thumper> :)
[03:39] <thumper> it is friday afternoon and I have run out of fucks to give
[03:39] <thumper> time to go choke someone
[03:39] <alexisb> wow
[03:39] <thumper> BJJ
[03:39] <thumper> what were you thinking?
[03:40] <alexisb> trumper ??
[03:40] <thumper> haha
[03:55] <alexisb> balloons, I just lost power
[03:56] <alexisb> it is likely to go out again
[03:56] <balloons> ohh fun
[03:56] <alexisb> wallyworld is here to help with announcement review
[03:56] <alexisb> when you are ready
[03:56] <alexisb> just in case
[03:56] <balloons> I was waxing on about my prose
[03:56]  * wallyworld is waiting with baited breath
[03:56] <alexisb> :)
[03:56] <alexisb> so close
[03:56] <balloons> we are close -- updating mirrors and waiting for packages to appear
[03:57] <balloons> have at it wallyworld. I keep sounding like an informercial or a corny old man
[03:58] <balloons> I think it should be light and have a touch of fun in it
[03:58] <wallyworld> yeah
[03:58] <balloons> Mostly we're linking to the docs
[03:58] <balloons> So no need to rehash or sell it
[03:58] <wallyworld> balloons: i reworded "providers" as there's a push to move away from that term
[03:58] <wallyworld> best not to poke the hornet's nest
[03:58] <balloons> semantics semantics!
[03:58] <balloons> ty, I'll add that to my mental list of banned words
[03:59] <wallyworld> balloons: when will juju 2.0 drop in the official xenial/trusty archives?
[04:00] <wallyworld> should we mention that? mybe not?
[04:00] <balloons> *soon* TM
[04:00] <balloons> no, don't jinx me please
[04:00] <balloons> NO promises
[04:00] <wallyworld> i would imagine most users would not want to use a ppa
[04:00] <balloons> rc3 is in yakkety.. it's sitting in proposed in xenial
[04:00] <balloons> it would have been REALLY nice to have that in xenial also
[04:01] <wallyworld> yeah, it's a shame that we can't issue release notice after juju is properly in the archives
[04:01] <wallyworld> not just a ppa
[04:04] <wallyworld> balloons: do we add a link to the official release notes in this announcement?
[04:04] <wallyworld> i know it's in introducing page
[04:04] <wallyworld> but that's a step away
[04:05] <alexisb> wallyworld, I think that requires it to be publised, which will need the docs team
[04:05] <balloons> hehe.. we ran 180m000 test suites over 2.0
[04:05] <balloons> wallyworld, we can link to anything that's on the site now. It's what was linked from the PR
[04:06] <wallyworld> so the introducing link in your doc above goes to https://jujucharms.com/docs/2.0/temp-release-notes
[04:06] <wallyworld> which is rc3
[04:06] <wallyworld> so if we issue this notice, people will be directed to old info
[04:06] <balloons> wallyworld, yep, so it goes
[04:07] <wallyworld> that doesn't look very professional of us
[04:07] <balloons> stable ppa has the packages
[04:07]  * menn0 is done
[04:07] <alexisb> wallyworld, agreed on that one
[04:07] <balloons> including precise alexisb.. just for you!
[04:07] <alexisb> sigh
[04:08] <wallyworld> how quickly can we get the proper 2.0 release notes up
[04:08] <wallyworld> and can we delay any notice of release until then
[04:09] <balloons> alexisb, and precise is gone now ;-)
[04:09] <alexisb> balloons it is the doc team that does the release notes commit right?
[04:10] <alexisb> can we send them a note and have someone on teh QA team that is on during EUR hours send the announcement?
[04:10] <balloons> I believe they publish -- even landing it doesn't do anything
[04:10]  * alexisb looks at the rc3 notes
[04:10] <alexisb> rc3 announcement
[04:11] <wallyworld> balloons: alexisb: also, the instructions for snap say --beta. but this is GA
[04:11] <wallyworld> people will be very confused IMO
[04:11] <balloons> yep, we can't go to stable channel without leaving devmode :-(
[04:12] <balloons> which of course would mean it wouldn't work, so ...
[04:12] <wallyworld> oh
[04:12] <balloons> I agree it's confusing though
[04:12] <wallyworld> everything is awesome
[04:12] <balloons> and non-stable snaps don't appear in search
[04:12] <alexisb> yeah in that case I think we are OK though given the juju snap is development
[04:13] <alexisb> but not have published release notes seems like an issue for announcement
[04:13] <wallyworld> +1 to that
[04:13]  * balloons notes this wouldn't be the first time
[04:13] <alexisb> true
[04:13] <balloons> did you noticed before? ;-)
[04:13] <wallyworld> but for 2.0 GA it sort of matters
[04:13] <alexisb> heh no, but we know how to use it
[04:14] <wallyworld> 2.0 GA will get a lot of attention and we will be judged on stuff like this. perception and all that
[04:14] <balloons> honestly, I would expect them to follow along with the site update shortly tomorrow. Outside of the "temp-release-notes", I don't think rc3 is mentioned
[04:15] <wallyworld> it says RC3 all over the page
[04:16] <alexisb> balloons, lets get the anouncement sent to the Juju managers (myself, rick, torsten and brett)
[04:16] <alexisb> as if you would send it to the list
[04:17] <balloons> wallyworld, if it helps, you are already announced: http://insights.ubuntu.com/2016/10/13/canonical-releases-ubuntu-16-10/
[04:17] <alexisb> I will take it from there
[04:17] <wallyworld> and all the bootstrap examples are wrong
[04:17] <balloons> that is technically true
[04:18] <wallyworld> balloons: yeah i saw, which is a bit premature
[04:18] <balloons> never early or late.. precisely on time
[04:19] <wallyworld> maybe no one reads release notes :-)
[04:19] <alexisb> obviously we do not
[04:19] <wallyworld> so those folks that run to get 2.0 will not be told the wrong info about bootstrapping
[04:19] <wallyworld> and see outdated examples
[04:20] <mup> Bug #1425669 changed: AllWatcher next internal failure for previously removed service. <api> <canonical-bootstack> <juju-core:Expired> <juju-core 1.25:Won't Fix> <python-jujuclient:Invalid> <https://launchpad.net/bugs/1425669>
[04:31] <balloons> wallyworld, can you add the command to upgrade from rc. I will mention it
[04:31] <wallyworld> to the doc? it's just juju upgrade-juju
[04:31] <wallyworld> assuming the streams are all good
[04:32] <balloons> wallyworld, if you didn't notice, I asked so I didn't have to think..
[04:32] <balloons> those braincells are still in yesterday :-)
[04:32] <balloons> ty!
[04:32] <wallyworld> :-)
[04:34] <balloons> ok thumper..
[04:34] <balloons> wait, did thumper bail?
[04:35] <balloons> ok, everyone who isn't thumper can party now
[04:35] <wallyworld> balloons: you did it!
[04:35] <balloons> wallyworld, WE did it!
[04:35] <jose> OMGOMGOMG CONGRATULATIONS!
[04:35] <wallyworld> if it goes well, you did it; if it goes poorly, alexisb did it
[04:36] <balloons> wallyworld, <3
[04:36] <alexisb> that is how it works :)
[04:36] <balloons> I remember those who stayed the course
[04:36] <balloons> and those who didn't :-)
[04:36] <wallyworld> been a long road
[04:36] <balloons> here's to the first hotfix!
[04:37] <wallyworld> thanks jose, let's hope everything goes well
[04:37] <alexisb> WOOT!
[04:38] <jose> seriously, I'm very excited
[04:38] <balloons> please don't break anything..
[04:38] <balloons> not tonight anyway
[04:39] <balloons> preferably not until next week
[04:39] <balloons> a whole weekend of happiness please
[04:39] <alexisb> :) thank you balloons for pushing through
[04:41] <alexisb> jose, happy deploying with 2.0 GA :)
[04:41] <alexisb> I am off to bed, see y'all later
[04:42]  * balloons collapses too
[04:43] <wallyworld> see ya
[04:44] <jose> alexisb: oh I'm pretty sure all my live demos will just break
[10:59]  * frobware celebrates 2.0 by upgrading the firmware on his router. I may even by online later... :-O
[10:59] <dimitern> :D
[10:59] <perrito666> lol I am celebrating by upgrading ubuntu... it broke
[11:07]  * macgreagoir started on his family machine, not his work one ;-)
[11:11] <perrito666> macgreagoir: my family machine is a mac
[11:11] <macgreagoir> perrito666: Ssshhh!
[11:12] <perrito666> k, finally end up upgrading with dist-upgrade since the upgrade tool just would not work
[11:14] <rogpeppe> can we land stuff on master now without fear of breaking the new release?
[11:14] <perrito666> rogpeppe: you can no longer land stuff in master, at all
[11:14] <perrito666> rogpeppe: did you see rick email about?
[11:15] <rogpeppe> perrito666: nope
[11:15] <rogpeppe> perrito666: which mailing list?
[11:15] <rogpeppe> perrito666: ah, new developer workflow?
[11:15] <perrito666> yes
[11:17] <rogpeppe> perrito666: ah, ok. so we can propose changes. that's good.
[11:18] <rogpeppe> perrito666: i guess existing PRs will have to be recreated, right?
[11:19] <perrito666> rogpeppe: sadly yes
[11:27] <perrito666> mm, now I need to wait for the ppas I use to add y builds
[11:32] <rick_h_> you can retarget an existing PR against a develop
[11:32] <rick_h_> don't have to recreate it
[11:32] <rick_h_> and morning and such
[11:33] <perrito666> rick_h_: really?
[11:33] <rick_h_> perrito666: go click the "Edit" button in the upper right
[11:33] <perrito666> oh look, that actually works
[11:33] <rick_h_> perrito666: you can change the title of the PR and the commit into branch
[11:33] <perrito666> and seems develop looks enough like master so it looks decent
[11:34] <rick_h_> perrito666: yes, all the new workflow branches were recreated from master after 2.0 lock yesterday
[11:34] <perrito666> I feared it would show as if my branch had a ton of diffs
[11:34] <perrito666> rick_h_: excelent job
[11:34] <rick_h_> no, should be good to go
[11:36] <rick_h_> perrito666: thanks for letting me know it wasn't common knowledge. Emailed the list with the nugget.
[11:36] <rogpeppe> rick_h_: ah thanks! I never knew it was possible to retarget a PR.
[11:38]  * perrito666 is  most likely the only juju dev that loves git
[11:43] <rogpeppe> perrito666: git or github ? :)
[11:43] <perrito666> git
[11:44] <perrito666> rogpeppe: I am fond of github for floss projects but not so much of how many people  use it
[11:46] <perrito666> rogpeppe: you do know you can view and link diffs in gh without making a pr right?
[11:46] <rogpeppe> perrito666: yes, but that's not quite the same
[11:46] <perrito666> how so?
[11:47] <rogpeppe> perrito666: i want it to be a PR because that's what it will be - I'm just not sure that it's exactly the right thing until I actually see it.
[11:48] <rogpeppe> perrito666: if I just view a diff, then I might make the PR and perhaps I've done it differently from the diffs I viewed.
[11:48] <perrito666> how is this different form a pr https://github.com/juju/juju/compare/develop?expand=1
[11:49] <rogpeppe> perrito666: it's not a PR :)
[11:50] <rogpeppe> perrito666: it can't be commented on for a start
[11:50] <perrito666> rogpeppe: you just changed your use case ;)
[11:50] <rogpeppe> perrito666: did I? I explicitly mentioned "demo" in my email.
[11:51] <rogpeppe> perrito666: there are a few use cases here.
[11:51] <perrito666> I might be having a es-> en issue here  but demo is just show it
[11:51] <rogpeppe> perrito666: if I show someone something, it's really useful if they can comment on it too.
[11:51] <voidspace> anyone know the repo for the CI tests?
[11:52] <voidspace> perrito666: rogpeppe: dooferlad: frobware: ^^^
[11:52] <rogpeppe> perrito666: "here's this WIP that I hope to submit tomorrow - it's a bit broken for the moment, but you might want to comment on the API"
[11:52] <perrito666> voidspace: bzr+ssh://bazaar.launchpad.net/+branch/juju-ci-tools/
[11:53] <voidspace> perrito666: thanks
[11:53] <perrito666> voidspace: sorry I dont know the short lp thinguie
[11:53] <perrito666> rogpeppe: well in that case I understand you can still pr and the tests will run but that is orthogonal to your use of the PR
[11:53] <perrito666> as a workaround I have on ocasions made a PR against my own master
[11:54] <voidspace> perrito666: that's fine, i've got it - appreciated
[11:54] <rogpeppe> perrito666: i think it's reasonable to make the tests triggered manually. they take a bunch of resources and the developer probably knows best about when best to trigger them.
[11:55] <rogpeppe> perrito666: for example, if I've just updated a comment, there's really no point in running the tests again.
[11:55] <rick_h_> rogpeppe: but the point is that it's short enough that it's harmless and having it auto means things can't slip by
[11:55] <rogpeppe> perrito666: but if I've updated something more substantial, then they should.
[11:55] <rogpeppe> rick_h_: 25 minutes isn't really very short...
[11:55] <rick_h_> rogpeppe: ideally, sure noticing that, but for the most part it's not worth the effort
[11:56] <rick_h_> rogpeppe: in the light of a PR, with a review and a QA and such, not horrible
[11:56] <rogpeppe> rick_h_: particularly if its double that because the test bot started before I noticed a trivial issue
[11:57] <rogpeppe> rick_h_: personally, I like to make the PR, check that everything looks OK, *then* publish it/run auto tests.
[11:57] <rogpeppe> rick_h_: are the representative tests run for many PRs concurrently?
[11:57] <rick_h_> rogpeppe: ok, well apologies it didn't match your personal expectations. Hopefully it's better than it was yesterday and we can smile at progress
[11:58] <rogpeppe> rick_h_: i'm definitely +1 on having some way to run tests before hitting $$merge$$
[11:58] <rogpeppe> rick_h_: do the auto-tests run every time the PR is updated?
[11:58] <rick_h_> rogpeppe: I believe it shuold
[11:58] <rick_h_> webhooks ftw
[11:59] <rogpeppe> rick_h_: is there a way to trigger the auto-tests to run again (say if there's a test failure that might or might not be intermittent) ?
[12:01] <perrito666> can annyone that knows enough bzr tell me how I diff my local copy with lp one?
[12:05] <voidspace> mgz: ping
[12:54] <balloons> rogpeppe, there isn't ATM -- no magic words for those tests
[12:54] <rogpeppe> balloons: ok, thanks
[12:55] <rogpeppe> perrito666: bzr diff lp:somewhere ?
[12:55] <balloons> rogpeppe, please collect your feedback after trying it for a bit. We can tweak as we go
[12:57] <balloons> rogpeppe, running tests on command for instance is certainly doable, so i don't want you to think it's locked in
[13:12] <rogpeppe> balloons: it would be great if the $$merge$$ 'bot could recognise when it doesn't need to run the tests again because they've been run on the same code already by the try bot
[13:15] <rick_h_> rogpeppe: but it also has to check that develop has had no other changes int he meantime
[13:15] <rick_h_> rogpeppe: that's the main reason to rerun
[13:15] <rogpeppe> rick_h_: that's what i'd expect it would do
[13:15] <rogpeppe> rick_h_: keep track of whether tests had been run on a given tree hash
[13:18] <rogpeppe> rick_h_: we could even run a microservice just to keep track of that.
[13:18] <rick_h_> rogpeppe: yea, sorry. I'm just happy to get this far so bigger fish to fry atm. I completely agree it could get better over time.
[13:19] <rogpeppe> rick_h_: yeah, it's really nice to get this far.
[13:21] <rogpeppe> balloons: out of interest, does $$merge$$ run more tests than the auto-try check?
[13:21] <rick_h_> rogpeppe: no
[13:21] <rogpeppe> rick_h_: ok, thanks.
[13:47] <katco> rick_h_: hey i'm going to attend the standup, but i can't talk atm
[13:51] <rick_h_> katco: k
[13:57] <rogpeppe> perrito666: ping
[13:57] <perrito666> rogpeppe: pong
[13:58] <rogpeppe> perrito666: we've run across a perm checking problem with AllWatcher
[13:58] <rogpeppe> perrito666: the offending line of code is this: isAuthorized, err := auth.HasPermission(permission.LoginAccess, context.State().ControllerTag())
[13:58] <rogpeppe> perrito666: in NewAllWatcher
[13:58] <perrito666> aha, what issue are you getting?
[13:58] <rogpeppe> perrito666: the question is: why is this checking for login access to the controller in order to be able to watch a model?
[13:59] <rogpeppe> perrito666: ah, perhaps it's because it's used by both the WatchAll and WatchAllModels API calls?
[13:59] <perrito666> rogpeppe: it comes from the assumption that users created should have login access (in order for us to be able to also take that permission out)
[14:00] <rogpeppe> perrito666: but presumably the user wouldn't have been able to create the watcher if they weren't able to log in?
[14:00] <perrito666> any model user should have controller login
[14:00] <rogpeppe> perrito666: i'm wondering why the explicit check is there
[14:00] <rogpeppe> perrito666: that's no longer true FWIW
[14:00] <rogpeppe> perrito666: even if true, why did we feel the need to make that check there?
[14:01] <rick_h_> voidspace: frobware ping for standup
[14:01] <perrito666> rogpeppe: I cant really remember now, it is most likely the translation from the check in place previously or from someone reporting a bug
[14:01] <rick_h_> dimitern: ping for standup
[14:01] <dimitern> oops omw
[14:01] <wallyworld> rogpeppe: all users accessing model indeed need controller login. tim landed that change last week
[14:02] <rogpeppe> wallyworld: actually they don't
[14:02] <rogpeppe> wallyworld: we landed a flag that turns off that requirement
[14:02] <wallyworld> the code says they do unless it has changed in the last week
[14:02] <rogpeppe> wallyworld: allow-model-users
[14:02] <wallyworld> right but out of the box it does need it
[14:03] <rogpeppe> wallyworld: yes, but the code can't make that assumption
[14:03] <wallyworld> so it seems that check you are talking about doesn't honour that new flag
[14:03] <rogpeppe> wallyworld: well, i'm wondering why that check exists in the first place
[14:03] <rogpeppe> wallyworld, perrito666: it was added here http://reviews.vapour.ws/r/5430/diff/5/ (in watcher.go)
[14:03] <wallyworld> not sure, don't know that bit of code directly
[14:03] <rogpeppe> perrito666: i don't really understand the comment there
[14:04] <perrito666> rogpeppe: reading
[14:05] <voidspace> rick_h_: sorry, omw
[14:08] <perrito666> rogpeppe: I would venture it is because its used by WatchAll*, the check might need to be in each WatchAll*
[14:09] <rogpeppe> perrito666: i don't understand
[14:11] <rogpeppe> perrito666: specifically in the comment i don't understand "this allows us to remove login permission for a user".
[14:11] <rogpeppe> perrito666: that seems like something relevant to some other endpoint entirely.
[14:12] <perrito666> rogpeppe: sorry was reading the wrong thing
[14:12] <rogpeppe> perrito666: :)
[14:13] <perrito666> rogpeppe: AuthClient seems to return true even if you have removed "login" from the permissions (or that I imply from my own comment)
[14:13] <perrito666> so if I want to revoke login from you, I want the check to ban you from entering if I do
[14:13] <rogpeppe> perrito666: but... if you've got access to the AllWatcher facade, you've already logged in by definition, right?
[14:13] <perrito666> rogpeppe: we might have named this poorly
[14:13] <rogpeppe> perrito666: named what?
[14:14] <perrito666> but if you want to be fine grained, if you are there it means you have authenticated, not logged in
[14:14] <perrito666> rogpeppe: the permission name
[14:14] <rogpeppe> perrito666: what's the difference between authenticating and logging in?
[14:15] <perrito666> rogpeppe: I was just trying to make a point, ignore me, what I meant is that we named the basic permission login, but it is a poor name
[14:16] <rogpeppe> perrito666: it seems a reasonable name to me - without that permission, you can't log in to the controller
[14:16] <rogpeppe> perrito666: (but, given allow-model-access, you can log in to a model even without that permission on the controller)
[14:17] <perrito666> rogpeppe: you might then want to change HasPermission to honour "allow-model-access"
[14:17] <rogpeppe> perrito666: i don't think we should be calling HasPermission in NewAllWatcher at all
[14:17] <rogpeppe> perrito666: i think AuthClient would be just fine
[14:17] <perrito666> rogpeppe: you should always be calling haspermission
[14:17] <rogpeppe> perrito666: why?
[14:18] <perrito666> rogpeppe: because its the interface endpoint for common.authenticator to tell you if you have the right credentials, ideally all should converge there
[14:18] <rogpeppe> perrito666: i don't see that any other API facades are checking for controller login access
[14:19] <rogpeppe> perrito666: and NewAllWatcher is somewhat special - it can only do something by virtue of the fact that watcher has already been created (and permission checks were done then)
[14:19] <perrito666> rogpeppe: grep -r ".HasPermission" | grep -v _test | grep apiserver | wc -lc
[14:19] <perrito666>      66    8256
[14:20] <rogpeppe> perrito666: try grepping for LoginAccess
[14:20] <perrito666> rogpeppe: if you are asking if the user has any of Login, AddModel, Superuser you are implicitly checking for login access
[14:21] <rick_h_> natefinch: katco either of you have osx?
[14:21] <perrito666> now, if you want to state that NewAllWatcher is special, and you can stand by that just change it and add a rich comment about it
[14:21] <rick_h_> natefinch: katco I need a volunteer to help  sinzui with https://bugs.launchpad.net/juju/+bug/1633495 please
[14:21] <mup> Bug #1633495: Panic MacOS Sierra <osx> <juju:Triaged> <https://launchpad.net/bugs/1633495>
[14:22] <rogpeppe> perrito666: but surely when you're watching a model, the right thing to check would be the model perms, not the controller perms, right?
[14:22] <katco> rick_h_: i do not, sorry
[14:22] <katco> rick_h_: 100% ubuntu here
[14:22] <rick_h_> voidspace: ? ^
[14:22] <sinzui> rick_h_: katco: I am going to attempt to use https://github.com/juju/utils/commit/28c01ec2ad930d41fe5acd9969b96284eb61660b as a patch to unblock hombrew
[14:23] <natefinch> rick_h_: I have no apples
[14:23] <frobware> dimitern: let's sync on monday for the juju side of nss-juju
[14:23] <dimitern> frobware: sure
[14:23] <katco> sinzui: rick_h_: i think that should be easy to dx/fix though? no hw required other than for the final test?
[14:24] <rick_h_> katco: yea, just figured it'd be good to get a verify. I thuoght bdx's patch would have taken care of it and it landed pre GA
[14:24] <voidspace> rick_h_: sorry, I'm 100% ubuntu these days too
[14:24] <sinzui> katco: indeed no hardware. pass it to me. I am seeing this issue as I prepare the homebrew request
[14:24] <perrito666> rogpeppe: as I said before, when we assume that a user has Login by default  and we want to use that as a way to block the user from accessing then checkign for that permission makes sense. Remember that until a couple of weeks for a user to do anythiung, Login to controller permissino was a must
[14:24] <voidspace> rick_h_: perrito666 has a Mac
[14:24] <rogpeppe> perrito666: when i grepped for '\.HasPermission\(.*Controller', AllWatcher is the only one that seems to be checking controller perms when acting on a model
[14:24] <rick_h_> katco: can you please help sinzui out and if we need a final verify use sinzui's hardware or perrito666's ?
[14:24] <perrito666> voidspace: my wife has, but I might be able to check whatever that bug is)
[14:25] <katco> rick_h_: sure. sinzui ramping up on bug
[14:25] <rick_h_> ty
[14:25] <rogpeppe> perrito666: well, actually it changed quite recently
[14:25] <rogpeppe> perrito666: but anyway, i do think that watchers are special
[14:25] <rogpeppe> perrito666: because a watcher facade can't do anything at all by itself
[14:25] <rogpeppe> perrito666: i'll propose a change
[14:26] <rogpeppe> perrito666: thanks for the useful discussion.
[14:26] <perrito666> rogpeppe: propose a change, be very verbose on the comments since this overall knowledge is not shared across the team sadly
[14:26] <perrito666> rogpeppe: sure, just ping me if you need to discuss it more
[14:48] <rogpeppe> perrito666: https://github.com/juju/juju/pull/6453
[14:50] <rogpeppe> balloons: y'know what would be really good - if we could abort an auto-test half way through if another update is seen
[14:51] <rogpeppe> hmm, looks like it runs two jobs concurrently anyway, cool. http://juju-ci.vapour.ws/job/github-check-merge-juju/
[14:52] <rogpeppe> perrito666: would you be able to review the above PR, please?
[14:53] <perrito666> rogpeppe: otp will review in a moment
[14:53] <rogpeppe> perrito666: ta
[14:56] <rogpeppe> balloons: FYI I just pushed another commit to https://github.com/juju/juju/pull/6453 and it doesn't seem to be running the auto-test job again
[14:56] <dooferlad> is anyone else having trouble with the magic auto-upload tools stuff not working? I have a different md5sum of jujud on my local machine to the one I just asked for by doing an add-machine...
[14:57] <rogpeppe> dooferlad: it generally seems to work ok for me, but i haven't checked checksums much
[14:57] <dimitern> I'd appreciate a review on https://github.com/juju/juju/pull/6454 (finally all seems to be working and tested exhaustively)
[14:57] <dooferlad> rogpeppe: I thought I was going crazy when some logs didn't turn up that I expected :-|
[14:57] <rogpeppe> dooferlad: i know the feeling well
[14:58] <sinzui> katco: I just confirmed that the patch I made from the juju/utils Sierra commit does fix the issue.
[14:58] <rogpeppe> dooferlad: that's why i wanted there to be a "please make sure you're really uploading local binary" flag to juju bootstrap
[14:58] <katco> sinzui: cool; i'm working on a comprehensive fix
[14:58] <sinzui> :)
[14:58] <dooferlad> rogpeppe: yea, magic is fine until it doesn't work
[14:58] <katco> sinzui: i had to pull in a newer version of juju/testing and we don't need to panic there anyway
[15:00] <voidspace> mgz: ping
[15:00] <mgz> voidspace: yo
[15:00] <voidspace> mgz: you said I should run the bootstrap (for vsphere) in "the same way CI tests do"
[15:01] <voidspace> mgz: I have juju-ci-tools and juju-release-tools
[15:01] <voidspace> mgz: the readme doesn't say how to run tests (is that documented elsewhere) and I can't find the entry point
[15:01] <voidspace> mgz: I can see a "bootstrap_with_env" function call, but that's from jujupy and I can't see which package provides that
[15:03] <mgz> voidspace: as in, just look at the ci test on jenkins
[15:03] <mgz> and literally run that script
[15:03] <perrito666> rogpeppe: add QA Steps to your PR please
[15:03] <voidspace> mgz: ah...
[15:04] <rogpeppe> perrito666: ah yes, will do
[15:05] <rogpeppe> perrito666: in a call right now; after that
[15:05] <katco> need very short review of juju/utils which precludes fixing critical 2.0 bug: https://github.com/juju/utils/pull/246
[15:05] <mgz> voidspace: I'm happy to just go over running a ci test on hangout in like 20 mins?
[15:05] <mgz> if that helps?
[15:06] <voidspace> mgz: I'll be going to fetch daughter then
[15:06] <voidspace> mgz: I'll see how I get on and shout again, maybe sometime after that if you're free?
[15:06] <mgz> sure, after pickup also fine
[15:07] <katco> rogpeppe: what do you think of getting rid of that once all together?
[15:11] <rogpeppe> katco: i'd take a look at where it's used
[15:11] <katco> rogpeppe: it's used in various places around Juju, but the once functionality should be managed there, not in a lib
[15:12] <rogpeppe> katco: tbh i'd probably keep it as was and just set it to "" or "unknown" on failure
[15:13] <rogpeppe> katco: at least initially
[15:13] <katco> rogpeppe: that sounds good for now
[15:14] <katco> rogpeppe: see if you like that?
[15:14] <rogpeppe> katco: when i said "as was" i meant "as it was before the PR"
[15:15] <katco> rogpeppe: oh, no. i need the ability to not panic
[15:15] <rogpeppe> katco: no need to panic. just initialise the variable to "unknown" on error.
[15:16] <voidspace> mgz: where is the juju release build job on CI?
[15:16] <katco> rogpeppe: that's what the pr is doing
[15:16] <dimitern> mgz: it seems my PR #6454 pre-check job failed on trusty and lxd for unknown reasons
[15:16] <dimitern> mgz: do I need to push another commit to re-trigger it?
[15:16] <rogpeppe> katco: the PR is adding two exported functions
[15:16] <voidspace> mgz: when I follow the links from reports.vapour.ws for release builds I get 404 and they don't show up on the jenkins dashboard (that I can see)
[15:17] <katco> rogpeppe: HostSeries was "exported" previously via the global variable
[15:17] <katco> rogpeppe: i'm making HostSeries not panic, and introducing MustHostSeries for those who want to panic
[15:18] <mgz> voidspace: log in using the credentials in cloud-city consoles.txt
[15:19] <rogpeppe> katco: i was thinking we could probably keep the global for the time being
[15:19] <katco> rogpeppe: why? it serves no purpose
[15:19] <voidspace> mgz: hah
[15:19] <voidspace> mgz: ok, thanks
[15:20] <rogpeppe> katco: easy patching :)
[15:20] <katco> rogpeppe: hm, on juju we don't allow patching any longer
[15:20] <katco> rogpeppe: is this used somewhere other than juju?
[15:20] <natefinch> katco: when did we blanket stop allowing patching in juju?
[15:21] <katco> natefinch: mm... i think around july? let me check
[15:21] <katco> natefinch: june 8th
[15:22] <rogpeppe> katco: ok, without patching you'll need to pass in HostSeries as an explicit dependency everywhere.
[15:22] <rogpeppe> katco: good luck!
[15:22] <katco> rogpeppe: that's the idea
[15:25] <katco> rogpeppe: so, where does this leave us with this PR?
[15:27]  * rick_h_ goes for lunchables, biab
[15:27]  * dimitern really thinks we should have an option to say $$retry$$ on a PR when the pre-check job fails
[15:30] <natefinch> katco: what's the title of the email about patching?  I'm trying to find it, but not seeing anything that looks relevant
[15:30] <rick_h_> dimitern: there is a command for that. !!build!! i think
[15:30] <dimitern> rick_h_: oh? trying now.. thanks!
[15:33] <dimitern> rick_h_: yeah, that worked - it needs to be on its own as a comment though
[15:50] <rogpeppe> katco: you do what you need to. if you're really going to pass it in explicitly, then you don't need anything more than a function that reads host series and doesn't cache it
[15:50] <rogpeppe> katco: you can then pass in the series string as the explicit dependency
[15:51] <katco> natefinch: sorry was otp: https://github.com/juju/juju/wiki/Boring-Techniques#do-not-use-global-variables
[15:52] <katco> rogpeppe: yeah that's a great point: code at the edges shouldn't have to actively introspect series, just be told
[15:53] <rogpeppe> katco: then you don't need to worry about caching the value
[15:53] <katco> rogpeppe: yep, exactly!
[15:54] <katco> rogpeppe: so sorry, i'm still unclear: what do i do with this PR?
[15:55] <rogpeppe> katco: i'd change it to just expose HostSeries
[15:55] <rogpeppe> katco: and dispense with all the globals
[15:56] <katco> rogpeppe: including the once functionality?
[16:00] <rogpeppe> katco: yup
[16:00] <rogpeppe> katco: just a simple function to read the series
[16:00] <katco> rogpeppe: i am in love
[16:00] <rogpeppe> katco: :)
[16:01] <katco> rogpeppe: ok updated PR
[16:04] <dimitern> ok, so the pre-check job is broken with lxd, it's not just for me
[16:17] <rogpeppe> katco: i added a few more comments :)
[16:17] <katco> rogpeppe: ta! just one left to address (logger)
[16:18] <perrito666> rogpeppe: your patch failed on windows
[16:19] <katco> rogpeppe: ok, responded w/ new patch
[16:20] <rogpeppe> katco: i don't understand your link response to "why isn't it concurrent safe?"
[16:20] <katco> rogpeppe: sorry, i'll add more detail
[16:20] <rogpeppe> katco: that function isn't called from readSeries
[16:21] <katco> rogpeppe: indirectly it is
[16:21] <katco> rogpeppe: readSeries -> updateSeriesVersionsOnce()
[16:21] <katco> rogpeppe: oops, actually it is direct ;p i was thinking of HostSeries
[16:22] <rogpeppe> katco: hmm, i see. that seems like a bug to me.
[16:22] <rogpeppe> katco: readSeries could just call UpdateSeriesVersions
[16:23] <katco> rogpeppe: i think it probably has something to do with OS's. looks like we have some OS specific files in here
[16:23] <rogpeppe> katco: but tbh i think that given your policy decision, i think you should remove all the global state
[16:23] <katco> rogpeppe: that would be ideal, but probably not prudent for this pr
[16:24] <rogpeppe> katco: well in general in Go, global functions should be safe to call concurrently
[16:24] <katco> rogpeppe: wow, really? i had never noticed that
[16:24] <katco> rogpeppe: that's kind of awesome
[16:25] <rogpeppe> katco: methods on a type are in general *not* safe to call concurrently unless documented as such
[16:26] <rogpeppe> katco: tbh that whole package is a bit spaghetti-like and could use some love
[16:26] <katco> rogpeppe: yeah i noticed that...
[16:26] <katco> rogpeppe: there is a lot of redirection
[16:28] <rogpeppe> perrito666: i'm pretty sure that windows failure is nothing to do with my change
[16:28] <katco> rogpeppe: so +1 on pr?
[16:28] <rogpeppe> katco: if you've made the function concurrent-safe, sure
[16:28] <katco> rogpeppe: oy... i don't think i can do that in a short amount of time
[16:29] <katco> rogpeppe: i don't think it was concurrent-safe before
[16:29] <katco> rogpeppe: e.g. you would get different results depending on whether you were the first in
[16:29] <rogpeppe> katco: there was no function to call, so it was
[16:29] <katco> rogpeppe: ?? yes there was... it was exposed through that global variable `HostSeries`
[16:29] <rogpeppe> katco: ha, no i lie
[16:30] <rogpeppe> katco: but it *was* concurrency safe
[16:30] <katco> rogpeppe: i don't think so? it had a RC
[16:30] <rogpeppe> katco: it used a sync.Once
[16:31] <katco> rogpeppe: right, so if you were 2nd in but 1st in hadn't completed, you'd get "", nil
[16:31] <rogpeppe> katco: nope, that's not how sync.Once works
[16:32] <katco> rogpeppe: ohhh yeah, i forgot subsequent calls block
[16:32] <rogpeppe> katco: so given that HostSeries is using global state anyway, you could easily just continue to use a global variable.
[16:33] <rogpeppe> katco: i hadn't realised about all the other global state stuff.
[16:33] <katco> rogpeppe: yeah, sad state of affairs :(
[16:34] <rogpeppe> katco: well to be fair, it is all about a global thing
[16:37] <katco> rogpeppe: leaning towards taking the "once" out of "updateSeriesVersionOnce"
[16:38] <katco> rogpeppe: wow nm... that really spider-webs out... you're right, everything is global
[16:38] <rogpeppe> katco: i'm not sure i see the problem - you could just change hostSeries to return "unknown" rather than panicking.
[16:38] <rogpeppe> katco: tbh i think that would be the better solution until you can fix the whole package
[16:39] <katco> rogpeppe: ok i'll once again revert back to that
[16:42] <katco> rogpeppe: do you think it should return an error every time?
[16:43] <katco> rogpeppe: or just "unknown", err 1st and then "unknown", nil
[16:48] <mup> Bug #1633554 opened: juju ssh uses old/invalid known_hosts data <juju-core:New> <https://launchpad.net/bugs/1633554>
[16:49] <katco> rogpeppe: pr updated
[16:57] <mup> Bug #1633554 changed: juju ssh uses old/invalid known_hosts data <juju-core:New> <https://launchpad.net/bugs/1633554>
[17:03] <mup> Bug #1633554 opened: juju ssh uses old/invalid known_hosts data <juju-core:New> <https://launchpad.net/bugs/1633554>
[17:14] <redir> crazy weather here in the easy bay, today.
[17:20] <katco> rick_h_: what am i doing wrong? https://github.com/juju/juju/pull/6455
[17:21] <rick_h_> katco: /me looks
[17:22] <katco> rick_h_: for context, i am successfully rebased off of staging
[17:22] <katco> rick_h_: no conflicts
[17:22] <rick_h_> katco: so a conflict with something else on develop?
[17:22] <rick_h_> katco: so this is a window where someone's landed something on develop, and it's not yet landed on trunk (staging) and that is causing a conflict?
[17:22] <katco> rick_h_: i think that's the case?
[17:23] <katco> rick_h_: but it looks like there's PRs included from Sep. 6th?
[17:23] <rick_h_> katco: oh ic, sec
[17:23] <katco> rick_h_: unless i'm reading this wrong
[17:24] <rick_h_> katco: can you update staging from upstream, create a new branch from that, and cherry-pick your commit over to the new branch and see if that's better?
[17:24] <katco> rick_h_: wait i think i see... my local staging was out of date
[17:24] <rick_h_> katco: I'm wondering if it was something off between when you started and now?
[17:24] <katco> rick_h_: which is weird... i just updated that
[17:25] <katco> rick_h_: i think this is human error on my part
[17:25] <rick_h_> katco: hmm, ok. If you find it's something too easy to do let me konw so we can adjust/warn folks
[17:26] <katco> rick_h_: no i guess there was an error updating my local refs that i missed, or i just did something else wrong
[17:27] <katco> looks like rogpeppe is off for the day; still need a +1 on https://github.com/juju/utils/pull/246
[17:27] <rick_h_> natefinch: perrito666 can either of you please look at ^ ?
[17:27] <rick_h_> redir: as well? ^
[17:27] <perrito666> ill tal
[17:27] <rick_h_> ty perrito666
[17:29] <redir> tx perrito666 :)
[17:29] <katco> ta perrito666
[17:32] <katco> sinzui: also could use a review on this: https://github.com/juju/juju/pull/6455
[17:33] <rogpeppe> rogpeppe: sorry, i was pairing getting a critical fix out
[17:33] <rogpeppe> katco: ^
[17:33]  * rogpeppe talks to himself once again
[17:33] <katco> rogpeppe: oh sorry
[17:33] <rogpeppe> katco: i'll take another look
[17:33] <katco> rogpeppe: ta
[17:36] <sinzui> katco: do you need me to build and run n Sierra?
[17:36] <katco> sinzui: to test the fix, i think so
[17:36] <sinzui> katco: okay, you fix matches my expectations. I will ping you back in about 15 minutes
[17:36] <katco> sinzui: ta
[17:37] <rogpeppe> katco: reviewed
[17:38] <katco> rogpeppe: good call on the bug#, making those changes. ta for the review
[17:38] <katco> perrito666: you are off the hook if you like
[17:38]  * perrito666 unhooks himself
[17:38] <perrito666> katco: shout if you want the review anyway
[17:39] <katco> rogpeppe: do you think that should be a single meta bug, or one specific to those lines?
[17:39] <katco> perrito666: ta
[17:39] <perrito666> rogpeppe: approved https://github.com/juju/juju/pull/6453
[17:43] <rogpeppe> katco: dunno :)
[17:43] <rogpeppe> perrito666: ta!
[17:43] <katco> rogpeppe: i'll make it a meta-bug for all of utils
[17:44] <rogpeppe> katco: yeah
[17:44] <rogpeppe> katco: no global loggers, eh?
[17:45] <katco> rogpeppe: i think loggers might be OK, but once the framework for injecting things in is established, often it's just as easy to inject a logger
[17:45] <rogpeppe> katco: injection is just a parameter, right?
[17:45] <katco> rogpeppe: parameter, or member-variable
[17:45] <rogpeppe> katco: ok
[17:46] <katco> rogpeppe: or a type which can retrieve those things
[17:47] <katco> rogpeppe: have you done anything with IoC before?
[17:47] <rogpeppe> katco: tbh i've argued for non-global loggers before
[17:48] <rogpeppe> katco: i think it's worth doing
[17:48] <rogpeppe> katco: (that was in the context of go-kit)
[17:49] <katco> rogpeppe: i don't know anything about go-kit, what is it?
[17:49] <rogpeppe> katco: it might be nicer to do loggo a bit differently if that's what we're doing
[17:49] <rogpeppe> katco: a set of packages for microservices
[17:49] <rogpeppe> katco: loggo is oriented around global loggers
[17:49] <katco> yeah
[17:49] <rogpeppe> katco: but if it wasn't, i think you'd probably ask for a sub-logger of an existing logger
[17:50] <rogpeppe> katco: anyway, i'm late, gotta go
[17:50] <katco> rogpeppe: tc, ta
[18:02] <sinzui> katco: LGTM
[18:03] <katco> sinzui: cool... it says tests failed...
[18:04] <katco> sinzui: but... i don't see any failing tests
[18:05] <sinzui> katco: indeed I don't see a reson for the failure
[18:05] <katco> sinzui: can you take that and run with it on your end? i'll go ahead and merge this into develop
[18:06] <sinzui> katco: I cannot ^ balloons any insight into why the build check failed to unblock katco
[18:07] <balloons> PR?
[18:07] <sinzui> katco: balloons: is there a problem with the lxd test? http://juju-ci.vapour.ws/job/github-check-merge-juju/60/console
[18:07] <balloons> See /var/lib/jenkins/workspace/github-check-merge-juju/artifacts/lxd-err.log
[18:08] <katco> balloons: ah i see it now... is that anything the code can influence?
[18:08] <balloons> the LXD test failed..
[18:09] <katco> balloons: "Failed to copy file. Source: /var/lib/jenkins/cloud-city/jes-homes/merge-juju-lxd/models/cache.yaml Destination: /var/lib/jenkins/workspace/github-check-merge-juju/artifacts/lxd/controller"
[18:09] <katco> balloons: i don't know what that means
[18:11] <balloons> katco, that's not the issue here.. It's weird it shows there
[18:11] <balloons> the lxd.err log is with full debug, so it's hard to parse imho
[18:12] <katco> balloons: oh, so we look at trusty-out.log for unit test failures, and lxd-err.log for lxd failures?
[18:14] <katco> balloons: hmmm i see a python exception... what is causing it? "juju --debug expose -m merge-juju-lxd:merge-juju-lxd dummy-sink" ?
[18:14] <balloons> katco, I was just going to say the same thing
[18:14] <balloons> that's why it failed
[18:14] <balloons> now, as to what that error is about, well, let's see
[18:15] <balloons> katco, ahh timeout. Look how long it was waiting
[18:16] <balloons> juju --debug expose -m merge-juju-lxd:merge-juju-lxd dummy-sink never did anything
[18:16] <katco> balloons: ah from the timestamps? 20m or so?
[18:16] <balloons> yea.
[18:17] <katco> balloons: so the question is immediately: is this intermittent? wondering if there's anything in the version of this lib i pulled in that would cause this
[18:17] <balloons> katco, if you think it's spurious I can run again. And if it is, we'll need to investigate
[18:18] <katco> balloons: well, i already did a $$merge$$ before you popped into the conversation, so i think we'll get our answer in a bit
[18:18] <balloons> katco, so I kicked it again. We'll see and followup on our end, or you'll know on yours ;-)
[18:18] <katco> hehe
[18:18] <balloons> ohh, hheheh
[18:18] <katco> balloons: sorry about that; got my other data point in sinzui's comment and went with it
[18:34] <katco> balloons: looks like it timed out again... huh
[18:35] <balloons> katco, you have another run still going of the pre-check
[18:35] <balloons> they ran at the same time..
[18:35] <katco> balloons: ah ok
[18:35] <katco> balloons: guess we'll see what happens there. otherwise i'm in for some fun debugging
[18:35] <balloons> katco, so just a datapoint, but looking like it's you ;-)
[18:40] <katco> balloons: i dunno i'm looking at the changes from 406e7197d0690a3f28c5a147138774eec4c1355e to 28c01ec2ad930d41fe5acd9969b96284eb61660b for this library, and there's like... nothing
[18:42] <balloons> katco, that gave me an idea -- I think I've solved it
[18:42] <katco> balloons: in fact, here's the diff: https://github.com/juju/utils/commit/28c01ec2ad930d41fe5acd9969b96284eb61660b
[18:42] <balloons> katco, it's the dreaded LXD too many container bug. I'll have to apply the sysctl values to this host too
[18:42] <katco> balloons: oh? what was it?
[18:42] <katco> ohh
[18:42] <balloons> yea..
[18:42] <balloons> sorry about that
[18:43] <katco> balloons: i.e. too many tests running at once = run into this?
[18:43] <katco> balloons: and since we're now running tests for every pr...
[18:43] <katco> kablooey
[18:43] <balloons> katco, exactly
[18:44] <balloons> we're at magic number 13.. where things end
[18:45] <katco> balloons: not even x^2 (shakes head)
[18:45] <balloons> katco, sending $$merge$$ should land you now. Sorry for the trouble
[18:45] <katco> balloons: no worries, thanks for the help
[18:50] <katco> natefinch: https://twitter.com/i/moments/782600001541251073
[19:00] <natefinch> katco: ha. Goats are the cutest, sorry puppy lovers
[19:00] <cmars> goats get my votes
[19:21] <katco> sinzui: your MacOS fix is committed
[19:23] <sinzui> :)
[19:31] <balloons> rogpeppe, remember when I said you can't ask for a build.. Seems like I lied
[19:31] <balloons> rogpeppe, !!.*!! seems to be working
[19:32] <natefinch> lol, it's like you're swearing at the bot
[19:32] <balloons> !!ilovebots!!..
[19:32] <balloons> or just !!build!!
[19:37] <mup> Bug #1566450 opened: Juju claims not authorized for LXD <bootstrap> <ci> <intermittent-failure> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1566450>
[19:37] <natefinch> rick_h_: in your bug, you say "Accounts should only be available to the admin of the controller and not for anyone that can read the data", but the only account it shows is the one you're logged in as, so I presume it's ok to show your own account and ACLs.
[19:40] <mup> Bug #1566450 changed: Juju claims not authorized for LXD <bootstrap> <ci> <intermittent-failure> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1566450>
[19:43] <mup> Bug #1566450 opened: Juju claims not authorized for LXD <bootstrap> <ci> <intermittent-failure> <lxd> <juju-core:Triaged> <https://launchpad.net/bugs/1566450>
[20:00] <rick_h_> natefinch: +1
[20:10] <natefinch> rick_h_: actually, it looks like non-admins can't see any controller details at all, which is kind of silly.
[20:10]  * redir lunches
[20:12] <perrito666> natefinch: yup that was by design
[20:13] <natefinch> perrito666: most of it is information the client already has.... like api endpoint, list of models the user has read access to, what account you're using to connect to it, what your curent model is, etc
[20:14] <natefinch> perrito666: the only information that definitely must be hidden is the ca-cert and models the user doesn't have read access to.  I don't think showing the cloud type or region is going to hurt anything
[20:15] <natefinch> perrito666: also, just returning empty json is really ugly.
[20:16] <perrito666> natefinch: in which context?
[20:16] <perrito666> to users?
[20:16] <perrito666> in that case any form of json is ugly :p
[20:17] <natefinch> perrito666: I guess show-controller always outputs yaml, so empty json is fine.... we just should have had a tabular output that outputs a nice message when you don't have rights to see the controller info
[20:20] <natefinch> rick_h_: so the long and the short of it is, I'm not sure what to do with this bug.  I think it's sort of a "it's already done slash not applicable" unless we want to change how the whole thing works to show some data to non-admins
[21:58] <hackedbellini> hey! I'm trying to setup juju 2.0 with lxd/zfs following this: https://jujucharms.com/docs/stable/getting-started
[21:59] <hackedbellini> When I run bootstrap, everything seems to go right. But at some point it fails in this line: 2016-10-14 21:53:20 DEBUG juju.tools.lxdclient client.go:199 connecting to LXD remote "remote": "192.168.99.4:8443"
[21:59] <hackedbellini> that because 192.168.99.4 is not the machine that I'm running it (the machine is 192.168.99.3). That ip is from the broadcast machine
[22:00] <hackedbellini> I don't know from where it is getting that config. Do someone have a clue on what is going on here?
[22:16] <hackedbellini> it is something like this comment: https://bugs.launchpad.net/juju/+bug/1547268/comments/19
[22:16] <mup> Bug #1547268: Can't bootstrap environment after latest lxd upgrade   <2.0-count> <juju:Triaged by rharding> <https://launchpad.net/bugs/1547268>
[22:17] <hackedbellini> note that it is doing a GET on the gateway ip and not on the bridge address
[22:31] <hackedbellini> anyone?