[00:18] <thumper> veebers: what do we need to do to add another repo into the bot landing?
[00:24] <veebers> thumper: as in a dep?
[00:25] <thumper> veebers: no, as in github.com/juju/description
[00:26] <veebers> thumper: I would have to find out
[00:29] <veebers> thumper: I believe we would need a new jenkins job and to update some scripts/cron for that. I would have to dig further to get a full answer
[00:29] <blahdeblah> thumper: Re: lp:1669046 - we have tickets in already to update all of our standalone controllers to 2.1.0.
[00:29] <blahdeblah> I'll create one shortly to get our HA controller env upgraded, but it may take a little longer - are there any special precautions/procedures for an HA upgrade?
[00:35] <blahdeblah> thumper: Also, if you need anything more on that 1.x to 2.x upgrade preparation, a reply to the ticket I created would be appreciated; gives me a place to log time worked on it.
[00:40] <thumper> blahdeblah: ack
[00:50] <thumper> hmm...
[00:50] <thumper> sublime not doing well with this global rename
[00:51] <thumper> doing save all on 5000 different go files causes it's plugins to work overtime
[00:51]  * thumper twiddles fingers waiting
[00:53] <thumper> oh bollocks
[00:54] <wallyworld> babbageclunk: i just noticed we have remoteApplicationsC in the ignored collections in migration_internal_test.go
[00:54] <thumper> managed to somehow end up with submodules
[00:55] <babbageclunk> wallyworld: oh, whoops - I'll fix that
[00:56] <wallyworld> babbageclunk: no wuckers. i noticed because i'm about to delete an entire collection and associated data model we won't be using anymore
[00:57] <wallyworld> no rush on it - get the spaces worker stuff done so i can test it out :-)
[00:57] <babbageclunk> wallyworld: ok - still trying to track down what I've broken.
[00:57] <wallyworld> joy
[00:58] <thumper> 11000 changes across 2800 files
[00:58] <thumper> yeah... do it
[01:00] <babbageclunk> wallyworld: I mean, I've worked out the line that's done it, but I don't understand why. Trying it again now
[01:00] <wallyworld> let me know if you need a 2nd set of eyes
[01:01] <babbageclunk> wallyworld: will do, thanks
[01:06] <blahdeblah> thumper: So, re: the precautions/procedures for HA upgrade question?
[01:10] <axw> wallyworld: sorry, https://github.com/juju/juju/pull/7047 should have been closed. I have another branch which supersedes it
[01:11] <wallyworld> no worries, i thought that was the case but then i second guessed myself and reviewed anyway. but yeah, it didn't seem to match the latest discussion
[01:11] <babbageclunk> wallyworld: ok, worked it out - the connection's dropping because of a panic - nil pointer dereference. :( fixing!
[01:11] <wallyworld> i hate those
[01:11] <wallyworld> babbageclunk: what that in a unit test?
[01:12] <wallyworld> that's why i added the stacktrace to catacomg errors
[01:12] <wallyworld> cause i had a similar issue that was hard to diagnse where it was happening
[01:12] <axw> wallyworld: well actually it's the same branch but updated. pushing now, will address comments and ping you later
[01:12] <wallyworld> np
[01:16] <axw> bleh nope, I'm wrong. closing and will create a new one
[01:22] <thumper> blahdeblah: shouldn't be any different
[01:23] <blahdeblah> thumper: Cool - so we don't need to upgrade each node separately or anything like that?
[01:24] <thumper> nope
[01:26] <blahdeblah> sweet
[01:26] <blahdeblah> thanks
[01:39] <axw> wallyworld: https://github.com/juju/juju/pull/7066. I'm running QA now
[01:39] <wallyworld> ok, otp with tim
[01:54] <babbageclunk> wallyworld: Oops, ListSubnets doesn't like blank space names either - I think there are going to be a few of these.
[01:54] <wallyworld> yeah
[02:11] <veebers> did something in 2.2 change for Azure? I see a _bunch_ of test failures in azure with errors like "'Failed': Code="AuthenticationFailed" Message="Authentication failed.""
[02:15] <babbageclunk> veebers: Sounds like authentication failed.
[02:15] <babbageclunk> :)
[02:16] <veebers> babbageclunk: ah an interesting take on an error message :-\
[02:16] <babbageclunk> veebers: In non-Friday-afternoon-japes mode, not that I know of.
[02:17] <veebers> babbageclunk: thing is this is happening during a bootstrap
[02:17] <veebers> babbageclunk: ack. I still need to pack for the sprint, leaving the house early tomorrow :-*(
[02:18] <babbageclunk> veebers: ouch, I'm not leaving until Sunday afternoon.
[02:19] <veebers> babbageclunk: ah, and arriving Sun evening right? I'm hoping that arriving Sat evening I lessen jetlag and hit the ground running on Monday
[02:19] <babbageclunk> veebers: yeah, shake off some of that jetlag on Bourbon St, I hear you.
[02:19] <babbageclunk> ;)
[02:20] <veebers> babbageclunk: ^_^
[02:22] <babbageclunk> wallyworld: ugh, segfault whackamole
[02:24] <babbageclunk> wallyworld: actually, this one isn't a segfault, just the subnets command (calling ListSubnets which I just fixed) now complains about blank spaces.
[02:33] <babbageclunk> wallyworld: rather than giving subnets a blank space, maybe we should be giving them a special space name? I feel like we're going to encounter knock-on effects from this.
[02:34] <babbageclunk> wallyworld: Although I'm not sure about what the special space name would be.
[02:34] <wallyworld> babbageclunk: sorry have been otp till now
[02:35] <babbageclunk> wallyworld: no worries, mostly thinking out loud.
[02:35] <wallyworld> babbageclunk: IIANM it is the intent to use "" as the default space rather than a const "default" or whatever
[02:35] <wallyworld> we will just have to solve the whack a mole sadly
[02:36] <wallyworld> babbageclunk: i need food, will be biab
[02:36] <babbageclunk> wallyworld: ok, lucky I hate those pesky moles.
[02:47] <babbageclunk> wallyworld: given that ListSubnets might now return a blank space tag, should I make a new facade version?
[03:09] <babbageclunk> wallyworld: review plz? https://github.com/juju/juju/pull/7067
[03:54] <wallyworld> babbageclunk: reviewed
[04:06] <wallyworld> axw: reviewed - IMO we need to include Type in list storage output
[04:07] <axw> wallyworld: should be obvious from the pool?
[04:07] <axw> and/or provider ID?
[04:08] <wallyworld> perhaps, but not guaranteed to be obvious? the pool name might not reflect the type so well? same with provider id which could well be opaque
[04:08] <wallyworld> pool names  can be defined by the user
[04:08] <axw> wallyworld: true, but I would think the operator would know what they've set up
[04:08] <wallyworld> but it is not the operator who always runs list-storage
[04:09] <axw> wallyworld: I'm reluctant because it's going to add a fair bit to the width
[04:09] <wallyworld> think of a support person or other user who did not do the original deploy
[04:09] <wallyworld> the width of the table?
[04:09] <axw> wallyworld: yeah
[04:09] <wallyworld> juju status is not exactly un-wide
[04:09] <axw> wallyworld: indeed, but one of the things we did in 2.0 was to cut it down
[04:10] <axw> cut down size of instance IDs, etc.
[04:10] <axw> to avoid overflowing terminal width by default
[04:10] <wallyworld> sure. but "volume" or "fiesystem" is not that much extra
[04:11] <axw> wallyworld: actually you can't tell from the pool alone anyway, since you couldh ave a filesystem on EBS or whatever
[04:11] <wallyworld> true
[04:11] <axw> I'll look at adding it in
[04:11] <wallyworld> I do think we need it TBH. ty
[04:12] <wallyworld> we can always remove if people complain, but i honestly don't think they will
[04:51] <axw> wallyworld: https://github.com/juju/juju/pull/7066/commits/fa75bb44923f8aafaf70a8c7615d64dafb494ea0
[04:51] <wallyworld> looking
[04:52] <wallyworld> axw: awesome, thanks
[04:52] <axw> np
[06:12] <blahdeblah> Anyone who's worked on the juju2 user permissions subsystem around?  Just want to ask some questions before I log some seemingly rather silly bugs.
[06:13] <blahdeblah> Asking anyway... :-)
[06:13] <anastasiamac> blahdeblah: 2.0.x or 2.1.x?
[06:13] <anastasiamac> there were some changes...
[06:13] <blahdeblah> anastasiamac: 2.1.0 stable!
[06:14] <anastasiamac> blahdeblah: ask away.. there may not b answers that make ur day :)
[06:14] <blahdeblah> So, Q1: is it expected that superusers are exempt from being disabled?  (Because in my testing, they are.)
[06:14] <blahdeblah> To me this is rather unexpected.
[06:16] <anastasiamac> blahdeblah: yes. i believe it's so tat someone can destroy and kill
[06:16] <anastasiamac> blahdeblah: maybe that logic needs to be adjusted to not disable if it's the last one
[06:17] <anastasiamac> blahdeblah: we have a discussion at sprint next week about user mngmt... so i can bring it up, especially if it's bugged up :)
[06:18] <blahdeblah> OK, so then the bug I will logging is that when you disable a superuser, it gives no indication that your command did absolutely nothing.
[06:18] <blahdeblah> (although it doesn't do nothing; it does actually mark the user as disabled, and it shows this way in list-users --all)
[06:23] <blahdeblah> anastasiamac: Q2: Is it expected that non-superusers which are disabled and then re-enabled lose all of their grants to various models?  To me this is also rather unexpected.
[06:24] <blahdeblah> When I disable a user and then re-enable that same user immediately (say, because I typoed the user name and disabled the wrong one), I don't want to have to work out which models were affected.
[06:25] <anastasiamac> blahdeblah: i *think* this is expected as you want to b explcit about ur grants when re-enabling a user
[06:25] <anastasiamac> blahdeblah: but again, it something to discuss
[06:26] <blahdeblah> No, I don't.  I want them to go back exactly as they were. :-)
[06:26] <anastasiamac> k \o/ file it and i'll see what we do
[06:26] <blahdeblah> OK - thanks
[06:57] <axw> wallyworld: do you recall if CI/builders are using go 1.7 to build already? or still on 1.6?
[07:01] <wallyworld> axw: still 1.6 AFAIK
[07:01] <axw> bugger
[07:03] <wallyworld> i could be wrong but i think it's 1.6
[07:03] <wallyworld> is there a 1.7 feature you want to use?
[07:03] <axw> wallyworld: yeah, http request context
[07:03] <axw> wallyworld: 1.8 would be better, since that has graceful shutdown/close methods on server
[07:04] <wallyworld> is 1.8 officially out yet? last i heard it was still rc?
[07:05] <axw> wallyworld: https://blog.golang.org/go1.8
[07:05] <wallyworld> i/m 2 weeks out of date
[07:05] <axw> wallyworld: also I suspect sort.Slice could be useful in a few parts of the codebase...
[07:05] <wallyworld> indeed
[07:06] <wallyworld> we'll have the right people necxt week to discuss
[07:06] <wallyworld> i'll add it to the agenda
[07:07] <axw> wallyworld: cool, thanks
[07:07] <axw> IIANM we can use whatever we like now, and are not dependent on archives
[07:09] <wallyworld> yeah, i think so too
[10:02] <mup> Bug #1669729 opened: Cannot update machine data <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1669729>
[10:36] <SimonKLB> any idea why i can't switch to a model that i have never connected to using a new user in juju?
[10:36] <SimonKLB> i can see the model in `juju models`
[10:37] <SimonKLB> but `juju switch aws:default` just spits out 'ERROR "aws:default" is not the name of a model or controller'
[10:38] <SimonKLB> looks like there is some problem at the controller level even
[10:38] <babbageclunk> SimonKLB: is your controller called aws?
[10:39] <SimonKLB> babbageclunk: yea
[10:39] <SimonKLB> added a new user, got the register base64 string, added it to the new user and named the controller aws
[10:39] <babbageclunk> SimonKLB: maybe something's getting confused between that and the aws provider
[10:40] <SimonKLB> ill retry with a more unique name
[10:40] <babbageclunk> SimonKLB: It's a guess, sorry.
[10:41] <babbageclunk> SimonKLB: Could also try passing --debug to  `juju switch`
[10:41] <SimonKLB> babbageclunk: do you have to re-do the add-user process, because now the second time i use the register string i get 'ERROR secret key for user "X" not found'
[10:42] <SimonKLB> or can i genenrate the string again without having to do add-user?
[10:43] <babbageclunk> SimonKLB: I don't think you can reuse the register string (I'm not certain of that though) - try adding another user?
[10:43] <SimonKLB> yea will do
[10:45] <SimonKLB> babbageclunk: same thing using "mycontroller" as the name
[10:45] <SimonKLB> nothing stands out in the --debug output
[10:46] <babbageclunk> SimonKLB: you can see the model in `juju models`?
[10:46] <babbageclunk> SimonKLB: did you grant access to the user?
[10:47] <SimonKLB> babbageclunk: yea i granted access
[10:47] <SimonKLB> http://paste.ubuntu.com/24101356/
[10:48] <babbageclunk> SimonKLB: Try `juju switch mycontroller:admin/default`?
[10:48] <SimonKLB> doh...
[10:48] <SimonKLB> thanks man haha
[10:49] <babbageclunk> SimonKLB: hmm, I don't think the admin/ should be necessary, since just default is not ambiguous.
[10:49] <SimonKLB> any idea why its named admin/default there and not elsewhere?
[10:49] <SimonKLB> well it worked using admin/ but not without :O
[10:50] <babbageclunk> SimonKLB: It's admin/default because it's owned by admin.
[10:50] <SimonKLB> aaah
[10:50] <SimonKLB> make sense
[10:51] <babbageclunk> SimonKLB: It's still pretty confusing though - can you file a bug? Or I will.
[10:51] <SimonKLB> launchpad or github?
[10:51] <perrito666> morning
[10:54] <SimonKLB> nvm launchpad it is!
[10:54] <babbageclunk> SimonKLB: yes launchpad please!
[10:55] <babbageclunk> morning perrito666!
[10:55] <perrito666> babbageclunk: coming to the sprint?
[10:55] <babbageclunk> perrito666: yup yup, assuming I get into the country
[10:55] <perrito666> babbageclunk: yes, we are all under the same assumption, I dont thing the place for the sprint was very wisely chosen :p
[10:56] <perrito666> we go to uk after the brexit and now to the US, who is pickig the destinatios?
[10:57] <babbageclunk> perrito666: political storm-chasing
[10:57] <perrito666> heh
[11:06] <SimonKLB> babbageclunk: https://bugs.launchpad.net/juju/+bug/1669745
[11:06] <mup> Bug #1669745: Model name different for model owner and non-owner might confuse new users <juju:New> <https://launchpad.net/bugs/1669745>
[11:07] <babbageclunk> SimonKLB: Nice write-up, thanks! I've tagged it with usability.
[17:15] <rogpeppe1> if anyone cares to take a look, i've just put a PR up for review of a change to gopkg.in/juju/worker.v1. my aim is to use it to replace a bunch of the state/workers.RestartWorker stuff: https://github.com/juju/worker/pull/2
[21:20] <redir> i saw perrito666 new ride today: https://goo.gl/NDtqUN