[00:57] <anastasiamac> wallyworld: plz comment on bug 1672879 when u get a chance
[00:57] <mup> Bug #1672879: [2.1.1] Controller does not look at agent_stream in model-config - it uses agent_stream that it booted with <oil> <oil-2.0> <juju:Triaged> <https://launchpad.net/bugs/1672879>
[01:09] <babbageclunk> wallyworld: can I get a review for my fix for the GCE legacy network bug? https://github.com/juju/juju/pull/7150
[01:14] <wallyworld> babbageclunk: sure
[01:14] <babbageclunk> wallyworld: fanks
[01:16] <menn0> axw: ping
[01:16] <axw> menn0: pong
[01:21] <menn0> axw: regarding the rev menioned in bug 1669180, that's quite an old rev for a recent ticket. how sure are you that it's the right one?
[01:21] <mup> Bug #1669180: proxy-ssh/juju ssh --proxy is ignored <cdo-qa-blocker> <juju:In Progress by menno.smits> <https://launchpad.net/bugs/1669180>
[01:22] <menn0> axw: it seems like jam's more recent work is what Gabriel/you are referring to
[01:22]  * axw looks
[01:22] <wallyworld> babbageclunk: minor nits only
[01:23] <menn0> axw: it does look like jam may have done something weird with proxy handling in his recent changes though
[01:23] <axw> menn0: hmm yeah doesn't look like it was changed in that rev, sorry
[01:23] <menn0> axw: ok cool... just making sure i'm not going crazy
[01:23] <axw> menn0: oh wait
[01:23] <axw> it is
[01:24]  * axw gets the line
[01:24] <axw> menn0: https://github.com/juju/juju/commit/d25d100f3c04eb6dc22c58db51e87c1d947a6836#diff-f75a59a4d41206aca31bb545d00e3e31R326
[01:25] <menn0> axw: ha, that's the line I was looking at too.
[01:25] <menn0> axw: for some reason I had thought that was part of jam's recent changes
[01:25] <menn0> axw: I agree that it's fishy
[01:26] <menn0> axw: thanks i'll dig further
[01:26] <axw> menn0: no worries
[01:39] <babbageclunk> wallyworld: I called those network initially but that clashed with the network package I use just further down. Do you think I should rename the import?
[01:40] <wallyworld> babbageclunk: nah, tis ok
[01:40] <wallyworld> leave as is tehn
[01:40] <babbageclunk> wallyworld: I agreee that it's a bit awkward though.
[01:41] <babbageclunk> wallyworld: just checking against a non-legacy network to be sure.
[01:43] <wallyworld> ty
[02:09] <thumper-headdown> anyone... https://github.com/juju/description/pull/6
[02:09] <thumper-headdown> juju branch to follow
[02:26] <anastasiamac> thumper-headdown: i'll swap ur PR for thoughts on bug 1675048 :) way forward or solution would b nice \o/
[02:26] <mup> Bug #1675048: mongod doesn't return when killed <mongodb> <juju:Incomplete> <https://launchpad.net/bugs/1675048>
[02:26]  * anastasiamac looking now
[02:40] <axw> menn0: your change seems sane to me
[02:40] <menn0> axw: did you see my email?
[02:40] <axw> oh I see email, /me reads
[02:40] <menn0> axw: just more detail
[02:41] <menn0> axw: I'd like jam's feedback before proceeding
[02:41] <menn0> axw: we might end up going with this for 2.2 and something more sophisticated for 2.3
[02:42] <axw> menn0: I suppose an alternative to classifying addresses would be to find an address that's routable from the controller's perspective. that might be as simple as finding addresses in the same space
[02:42] <axw> menn0: but yeah, I think this is probably fine for now
[02:43] <axw> and now I see I basically just said the same thing as your last sentence, which I hadn't got to yet ;:p
[02:57] <thumper-headdown> ah fuck...
[02:58]  * thumper-headdown headdesks gently
[03:01] <thumper-headdown> hmm...
[03:01] <thumper-headdown> maybe not
[03:19] <thumper> well shit
[03:19] <thumper> axw added model status back in april 2016 and migration missed it
[03:19] <thumper> and here I thought it was something new
[03:20] <anastasiamac> it was new in april 2016 :)
[03:20] <thumper> not helpful
[03:20] <anastasiamac> :(
[03:20] <thumper> on the plus side, can make it required in the description rather than optional
[03:21] <thumper> which is cleaner
[03:21] <anastasiamac> it seems to me that we need to have better testing that description pkg is in sync with what we have in juju....
[03:27] <thumper> well... this was missed when it was together, so that isn't the issue
[03:28] <anastasiamac> exactly.. what ele could have been missed in the same manner?..
[03:28] <anastasiamac> else*
[03:36] <babbageclunk> wallyworld: I'm trying to test the add-subnet part of my provider-network-id change, but I can't run it with GCE because add-subnet requires a space name and spaces aren't supported on GCE. Should I add a card to make add-subnet accept an empty space name?
[03:46] <babbageclunk> wallyworld: PR for storing network id: https://github.com/juju/juju/pull/7152
[03:48] <wallyworld> babbageclunk: looking
[03:49] <babbageclunk> wallyworld: ta
[03:49] <wallyworld> babbageclunk: empty space name is what we want, tes
[03:50] <axw> wallyworld: I have pods running in kubernetes in vsphere
[03:50] <axw> I'll do some more testing, but looking good
[03:50] <wallyworld> whoot!
[03:50] <wallyworld> proxy did the trick?
[03:51] <axw> wallyworld: yep
[03:58] <wallyworld> babbageclunk: my OCD kicked in with naming consistency, see what you thnik
[03:58] <babbageclunk> wallyworld: the problem is there are already inconsistent names, so you're never going to be happy. :(
[03:59] <wallyworld> true. i was hoping not to make it worse :-)
[03:59] <wallyworld> but, your call
[03:59] <babbageclunk> wallyworld: This is definitely better - there are heaps of other ones on network.InterfaceInfo that are all in this direction.
[04:00] <wallyworld> righto
[04:01] <babbageclunk> wallyworld: So, I could make them consistent with the other names in the same structure, but then we're going to have weird inconsistencies between the types. Maybe that's better?
[04:02] <wallyworld> hmmm, maybe best to stick with something that's more consistent overall
[04:02] <wallyworld> lessen the tech debt
[04:02] <babbageclunk> wallyworld: Yeah, that was where I ended up, I think.
[04:03] <wallyworld> sgtm then
[04:03] <babbageclunk> wallyworld: sorry, kind of annoying.
[04:03] <wallyworld> yeah, can't be helped, it's what was there
[04:03] <babbageclunk> wallyworld: I might quickly get add-subnet working with no space, then?
[04:04] <wallyworld> why not
[04:06] <babbageclunk> wallyworld: since it's a positional arg (with optional availability zones after it) I think it needs to be required as "" though. Too crufty?
[04:07] <wallyworld> oooh, yuk
[04:07] <wallyworld> but what other choice is there that retains compatibility
[04:07] <wallyworld> maybe we add a --space arg
[04:08] <wallyworld> and deprecate the positional arg
[04:08] <wallyworld> or if --space is used, don't interpret the first psoitional arg as a space
[04:08] <wallyworld> just assume ones
[04:08] <wallyworld> zones
[04:08] <wallyworld> so we support old syntax but add better syntax
[04:09] <babbageclunk> Ok, so it would be: if there's a --space option, the positional args are cidr-or-provider-id [zone1 zone2...]
[04:11] <babbageclunk> if more than one positional arg and no --space, the 2nd arg is space name (preserving backwards compat)
[04:11] <babbageclunk> and we allow just 1 arg (and --space not specified) meaning add this subnet not in a space?
[04:12] <babbageclunk> I think that works.
[04:14] <babbageclunk> Has the possibility of putting something into a space accidentally if someone has spaces named the same as an AZ and they don't know about the legacy mode? That would be pretty weird though.
[04:15] <babbageclunk> wallyworld: ^?
[04:16] <wallyworld> babbageclunk: yeah +1 but i think 1 arg should  error as it does now
[04:16] <wallyworld> but the error would mention the prefered syntax
[04:17] <babbageclunk> so the preferred syntax for adding a subnet without a space would be `add-subnet <provider-id>--space=""` ? Seems janky.
[04:17] <babbageclunk> oops, `add-subnet <provider-id> --space=""`
[04:17] <babbageclunk> wallyworld: ^
[04:19] <axw> wallyworld: confirmed, kubernetes is happy now. ran the microbot smoke test, and it's responding happily
[04:19]  * axw moves on to the vswitch bug
[04:19] <wallyworld> babbageclunk: or add-subnet --space foo mysubnet
[04:20] <wallyworld> axw: quick review? https://github.com/juju/names/pull/79
[04:20] <axw> looking
[04:20] <wallyworld> axw: awesome about k8
[04:20] <babbageclunk> wallyworld: right, but the no-space version would be add-subnet --space "" mysubnet?
[04:21] <wallyworld> babbageclunk: yeah :-( maybe just keep as is
[04:21] <wallyworld> and can be bikeshedded with folks next week
[04:21] <wallyworld> babbageclunk: or propose and we can ask for input on the pr
[04:23] <babbageclunk> I'll send an email to jam and cc you - think I should add anyone else on?
[04:24] <babbageclunk> wallyworld: ^ (I'm still trying to get the hang of when to put someone's nick at the start of messages)
[04:24] <wallyworld> babbageclunk: sorry, i keep switching back to IDE
[04:24] <wallyworld> include witold as well since he's in that space (pun intended)
[04:25] <babbageclunk> wallyworld: ha, good friday afternoon joke!
[04:25] <wallyworld> dad joke
[04:58] <jam> babbageclunk: you're adding subnets to the "undefined" space, thus "" is perfectly appropriate for now
[04:58] <jam> babbageclunk: that's concretely the "what do we want to call the otherwise-unnamed space"
[04:58] <jam> right now it is exactly called ""
[08:45] <babbageclunk> jam: ok, thanks - so I understand that as: we still require the space to be passed positionally, but we allow "". Right?
[08:47] <babbageclunk> jam: I guess in general, we'd want people to be using named spaces. So this is enough of a special case that it's ok for for the command to do it is a little awkward?
[08:48] <babbageclunk> gah, edito: ".... for the command to do it to be a little awkward?"
[14:49] <wpk> wallyworld: I've updated https://bugs.launchpad.net/juju/+bug/1314682 with what I'm getting
[14:49] <mup> Bug #1314682: Bootstrap fails, missing /var/lib/juju/nonce.txt (containing 'user-admin:bootstrap') <bootstrap> <juju> <maas-provider> <juju:Expired> <juju-core:Won't Fix> <https://launchpad.net/bugs/1314682>
[15:06] <wpk> sinzui: ^^^
[15:08] <sinzui> wpk: did you setup the dns/addresses to be ip4
[15:14] <sinzui> wpk: did the instructions in comment 28 not work?
[15:38] <wpk> sinzui: cloud-init finishes, apt-get update takes ~1.5 seconds
[15:39] <wpk> there is an error in cloud-init.log but found non-fatal and unrelated