[00:36] <menn0> axw, babbageclunk: so.... https://github.com/juju/juju/pull/7123
[00:43] <babbageclunk> menn0: trying to get something finished off so I can get some other people's opinions. Also I think wallyworld wanted me to take a look at a PR of his, so I might need to do that first - it's probably smaller than this one too!
[00:44] <menn0> babbageclunk: could be :)
[00:44] <babbageclunk> menn0: But I'll try to get to it soon!
[00:52] <menn0> wallyworld: easy one: https://github.com/juju/cmd/pull/48
[00:53] <wallyworld> menn0: sure. am also looking at resources one. will be awesome to get that all fixed up at least
[00:53] <menn0> wallyworld: after the resources one comes the big apiserver facade registration cleanup i've been sitting on
[00:54] <wallyworld> sounds painful
[00:54] <menn0> wallyworld: the payloads and resources PRs were needed before that could be finished
[00:54] <wallyworld> yep
[00:54] <menn0> wallyworld: yep, not exactly a soft cushion :)
[01:06] <axw> menn0: re "unnecessarily exposed? Backend": I'd prefer if the apiserver facade constructors that map state.State -> Backend were outside the package, and the package *only* dealt with Backend. not in this PR of course, but I don't think Backend is unnecessarily exposed
[01:06] <menn0> axw: yeah fair enough... I was 50/50 on that one
[01:06] <axw> menn0: I think we can neaten things up more when the global registry goes away
[01:06] <menn0> axw: I think so too.
[01:07] <menn0> axw: I need to do that for my big project
[01:07]  * axw nods
[01:07] <menn0> axw: (which is why I'm doing all this)
[01:25] <axw> wallyworld: lol @ MiG comment. I was thinking the same thing :)
[01:27] <wallyworld> :-)
[04:16] <axw> wallyworld: can we branch yet?
[04:17] <wallyworld> axw: i think real soon, anastasia is coordinating it; i thought it was going to be to coincide with beta1
[04:17] <wallyworld> i'm guessing you need to do breaking stuff
[04:18] <axw> wallyworld: ok
[04:18] <axw> wallyworld: yes
[04:18] <axw> I want to land my changes to detach storage
[04:19] <axw> a few changes bundled up together which can't land until you can detach storage
[04:19] <wallyworld> hmmm, let's discuss first thing tomorrow when she's back onboard
[04:19] <axw> there's still one or two other things I can do in the mean time
[04:19] <wallyworld> ok
[04:21] <axw> wallyworld: I ended up cheating a little bit, and not having storage attachment removal gate on volume/filesystem attachment removal. instead, just fail in "attach-storage" if the volume/filesystem is attached to another machine
[04:21] <axw> more or less comes to the same effect, but simpler
[04:21] <wallyworld> simple is good
[05:49] <axw> wallyworld: was it the lifecycle watcher that you were looking at, when you found that the filter is ignored if a members query is specified?
[05:49] <axw> wallyworld: I'm going to make it unconditional - any concerns about that?
[05:53] <wallyworld> axw: i think it was. off hand, i can't see an issue with what you want to do, but we will need to be careful that there's no unintended consequences. from memory, i needed to add a unit test to explicitly cacth the issue so i'm not 100% sure out test coverage is complete
[05:54] <wallyworld> i can't think of any bad consequences off hand
[05:56] <axw> wallyworld: okey dokey. all tests pass, and all the existing usages look to be safe - but will double check before I go ahead with changes.
[05:56] <wallyworld> ta, yeah i think it will be ok, just be a little more cautious
[06:48] <jam> axw: trivial review? https://github.com/juju/juju/pull/7121
[06:48] <axw> looking
[06:48] <jam> and a less trivial but hopefully useful one https://github.com/juju/juju/pull/7122
[06:49] <axw> jam: how's gogland so far?
[06:49] <jam> axw: the one thing it does nicer than vim is "find callers of this function" and "find implementations of this function" vs just "find definition"
[06:49] <jam> I'm not sold on its VIM integration, as a lot of the nice "jump to this" in the standard UX overlaps with VIM's commands
[06:49] <jam> (eg, ^B is jump to definition in gogland, but also previous-page in VIM)
[06:50] <axw> jam: do you use vim-go? it has integration for go-oracle, which can find callers/callees, etc.
[06:50] <jam> fortunately the important ones "gd" to jump to definition in VIM works in goland
[06:50] <jam> axw: I do, but I've often found it hard to get it set up correctly on all machinse
[06:50] <jam> I use Trusty, Xenial, Windows and Mac
[06:50] <axw> okey dokey
[06:51] <jam> getting them all set up nicely would be great, I should probably just try to start a fresh install
[06:51] <axw> jam: yeah, little things like that (re key bindings) often mean I find other IDEs with "vim mode" difficult to use
[06:51] <jam> I thought at least 'vim-go' had a "I'll automatically install dependencies" which it didn't seem to actually do
[06:55] <axw> jam: I've started reviewing hte other, gotta pick up my daughter from school shortly. I'll continue when I return
[06:55] <jam> axw: thanks
[07:28] <wallyworld> axw: can you peek at this small PR? I wanted to rename remote application "registered" to something hopefully more meaningful https://github.com/juju/description/pull/4
[07:29] <axw> wallyworld: sure, just after I finish with jam's
[07:29] <wallyworld> no rush
[07:32] <axw> jam: done
[07:34] <axw> wallyworld: LGTM. normally that'd require a version bump, but I'm assuming we don't care about compat yet
[07:35] <wallyworld> axw: yeah, usages are behind a flag
[07:35] <wallyworld> ty
[09:15] <babbageclunk> jam: would you be able to take a look at https://github.com/juju/juju/pull/7126?
[09:16] <jam> looking
[09:19] <babbageclunk> jam: Thanks - there's some stuff in there I'm not really sure about - GCE networking seems much simpler than what we support so a lot of the fields on SubnetInfos and InterfaceInfos are kind of fudged.
[09:20] <jam> babbageclunk: I have the feeling those structs are heavily influenced by AMS and MAAS and not so much by other providers, so we likely need a common ground. I'll look at it
[09:22] <jam> babbageclunk: actually, having comments that link to the GCE docs on networking would probably also be good
[09:23] <babbageclunk> jam: yeah, that's a really good call - I'll add that.
[09:24] <jam> "Any communication between instances in different networks, even within the same project, must be through external IP addresses."
[09:24] <jam> from https://cloud.google.com/compute/docs/networking
[09:24] <jam> sounds like we can't really do private=>private networking on GCE either.
[09:24] <jam> wallyworld: ^^
[09:25] <wallyworld> hmmmm
[09:25] <wallyworld> awesome
[09:25] <babbageclunk> d'oh, didn't spot that
[09:25] <wallyworld> we'll have to come up with a solution sooner rather than later it seems
[09:28] <babbageclunk> Although all the machines in models managed by a controller will be on the same network.
[09:28] <babbageclunk> At the moment there's no way to get a machine on a non-default network in GCE
[09:29] <babbageclunk> (I hacked something in for my testing.)
[09:29] <babbageclunk> wallyworld: ^
[09:31] <wallyworld> babbageclunk: interesting, i didn't realise we had that restriction. but the external ip address restriction will still trip us up
[09:31] <wallyworld> regardless of what network (single or otherwise) machines come up on
[09:33] <babbageclunk> I don't see how, until they can be on different networks they're all on the same network and can talk on the cloud-local address right?
[09:33] <babbageclunk> wallyworld: It's a much looser restriction than the azure one.
[09:33] <wallyworld> babbageclunk: ah, ignore me, i misread the text
[09:33] <babbageclunk> (As far as I understand)
[09:34] <wallyworld> it should work then. easy enough to test
[09:34] <babbageclunk> way
[09:34] <babbageclunk> duh
[09:34] <wallyworld> we'd need to check that the firewaller discovers at least one subnet
[09:34] <wallyworld> or else it will default to open to the world
[09:34] <babbageclunk> wallyworld: yeah, true - I'll give it a try now
[09:35] <wallyworld> to be sure just comment out the default 0.0.0.0/0 in the firewaller
[09:35] <babbageclunk> ok
[09:44] <jam> babbageclunk: don't we have to map 1 model == 1 project in GCE, which means a multi-model controller is spanning projects and thus networks?
[09:45] <jam> babbageclunk: at the very least, if you have >1 credential, then you certainly can't have 1 controller == 1 project
[09:45] <jam> which would hint that you have to span projects and thus networks
[09:46] <babbageclunk> jam: well, at the moment we couldn't have controllers with models in different projects.
[09:46] <jam> so if we're using https://cloud.google.com/compute/docs/networking#legacy_non-subnet_network
[09:46] <jam> babbageclunk: that sounds like a *severe* problem with our GCE implementation
[09:46] <jam> given we support multiple auth on other providers
[09:47] <babbageclunk> jam: The qa account uses legacy, but it depends how the default network has been set up.
[09:47] <jam> back to my thread, https://cloud.google.com/compute/docs/networking#legacy_non-subnet_network seems to say everything talks on the same single-subnet across all regions for a project
[09:47] <babbageclunk> jam: not sure about the multi-auth bit
[09:48] <jam> babbageclunk: regardless the default network, the goal has always been to support "juju add-model --credential=FOO" which would mean the controllers would span projects
[09:48] <jam> it sounds like we should have modeled 1 Model == 1GCE Project, though I can imagine we didn't do that
[09:49] <babbageclunk> jam: ok. I haven't seen that, but I think you're right.
[09:49] <jam> babbageclunk: its possible we put "Project" into part of the GCE credentials
[09:49] <babbageclunk> jam: We definitely don't have 1 model = 1 project at the moment. :(
[09:50] <babbageclunk> jam: it is in the credentials - I haven't seen add-model --credential=FOO
[09:53] <wallyworld> babbageclunk:  it seems you are saying the GCE provider is lacking the abiltity to create models with different credentials
[09:54] <wallyworld> that is quite a bad problem then
[09:54] <babbageclunk> wallyworld: I haven't tried, I don't know for sure that it doesn't
[09:54] <babbageclunk> wallyworld: but all of the testing I've been doing is with one set of creds.
[09:54] <wallyworld> ok, we'll need to check that tomorrow
[09:58] <jam> fwiw, there has been a strong request for us to request 'static' external IP addresses on GCE as well
[09:58] <jam> I haven't had time to dig into it
[09:58] <jam> but apparently IP addresses are even-more dynamic on GCE
[09:58] <jam> on AWS you only get new addresses if you "Stop" the machine explicitly and then "Start" it again
[09:59] <jam> apparently on GCE just doing a "shutdown -r" will give you a new address
[10:02] <mattyw> jam, you around to do a review?
[10:05] <jam> mattyw: currently otp and doing another review, but i can add it to the queue if you like
[10:06] <mattyw> jam, thanks very mcuh https://github.com/juju/juju/pull/7109
[10:08] <babbageclunk> wallyworld: hmm - looks like there's a nil pointer panic happening in the firewaller - could be the upgrade of the GCE client package. I'll chase it in the morning.
[10:09] <wallyworld> babbageclunk: i've already started looking. it's happening for me too on LXD
[10:09] <wallyworld> i'll look a bit more tomorrow as well if i don't find the cause tonight
[10:10] <babbageclunk> wallyworld: ah, ok - I thought it was my fault but I guess it could be yours!
[10:10] <wallyworld> :-)
[10:10] <wallyworld> probably
[10:10] <babbageclunk> catch you tomorrow
[10:10] <wallyworld> a *lot* of refactoring has been happening
[10:10] <wallyworld> ttyl
[10:10]  * babbageclunk exits pursued by a bear.
[10:10] <wallyworld> \o/
[10:10]  * wallyworld is having a whiskey
[10:11] <wallyworld> oh you said bear
[10:11] <wallyworld> i thought you said beer
[10:58] <perrito666> morning
[11:01] <mattyw> perrito666, morning morning
[11:54] <jam> babbageclunk: ping
[11:56] <jam> morning perrito666
[12:01] <perrito666> jam: I am supposed to have a meeting with you now :)
[12:01] <jam> hi perrito666, sorry caught up in a review brt
[12:01] <perrito666> tx
[13:03] <tasdomas> perrito666, hi - could I get a review: https://github.com/juju/juju/pull/7114
[13:08] <perrito666> tasdomas: not soon, if you are in a hurry I suggest you find a backup reviewer :)
[13:12] <tasdomas> perrito666, thanks ;-]
[13:19] <perrito666> jam: I feel like we are cheating you, you have little day left so our "have a good day" is not as effective for you
[13:54] <jam> perrito666: I carry it over for the next day :)
[13:54] <jam> matty
[13:54] <jam> sorry, was trying to search for your name
[14:13] <jam> mattyw: https://github.com/juju/juju/pull/7109 reviewed
[14:13] <mattyw> jam, ack thanks
[20:54] <wallyworld> hml: hey, i'm not sure what happened before, but i re-added our 1:1 to the calendar. does the time suit?
[20:55] <hml> wallyworld: the time works for me - our previous time was in the middle of your night.  :-)  most likely lost off your calendar
[20:56] <wallyworld> hml: great. it is on the back of the release call so if i'm a minute late i won't be long
[20:56] <perrito666> hml: wallyworld does not need to sleep, he is a robot of sorts, the only activity he has is soccer :p its like an aussie terminator
[20:57] <wallyworld> i need something to keep me sane
[20:57] <wallyworld> i also need coffee
[20:57] <perrito666> its as if Terminator had been made with Paul Hogan as the main character
[20:57] <wallyworld> lol
[20:58] <hml> perito666: ha!  i’ve seen him online and talking around lunch in the US and wondered.
[20:58] <perrito666> hml: paul hogan or wallyworld ?
[20:58] <hml> perrito666: wallyworld - haven’t seen paul in a while
[21:15] <menn0> gah! httptest.ResponseRecorder.Result() doesn't exist in Go 1.6 :(
[21:15] <menn0> and i've used it quite a bit
[21:16] <perrito666> and we are using go 1.6 for?
[21:22] <menn0> that's the minimum Go we support but I'm using Go 1.8 on my machines
[21:22] <menn0> the official Go in our ubuntu releases is Go 1.6
[21:26] <perrito666> I thought we stopped caring about that with snaps
[21:27] <menn0> perrito666: the Go snap only started working properly very recently (and still has a GOROOT issue which mwhudson is fixing)
[21:27] <wallyworld> and out tests fail with go 1.8
[21:27] <wallyworld> go 1.8 is stricted on url parsing for example
[21:27] <wallyworld> stricter
[21:28] <perrito666> I have not tried juju on 1.8 yet, I still use 1.7
[21:28] <wallyworld> we want to move to go 1.8 - the process is underway
[21:28] <wallyworld> juju works fine with 1.8, just the unit tests need fixing
[21:28] <perrito666> wallyworld: have you seen plugins? they are very cool, still very beta, but looks like a nice thing to look for the future
[21:29] <wallyworld> haven't seen them yet
[21:30] <perrito666> wallyworld: here, have some shameless plug by me :p https://perri.to/2017/03/go-plugins-and-content-delivery/
[21:30] <wallyworld> interesting
[21:40] <babbageclunk> wallyworld: reviewed the first one - looks good other than what I think is a logic bug in resolving the filters.
[21:41] <babbageclunk> wallyworld: looking at the other one now
[21:41] <wallyworld> babbageclunk: tyvm, will look after my meetings this morning
[21:41] <babbageclunk> wallyworld: cool
[21:43] <babbageclunk> wallyworld: oh my god, I was expecting the second one to be smaller.
[21:44] <wallyworld> babbageclunk: are you just looking at 2nd commit?
[21:44] <wallyworld> it was branched off the first one
[21:44] <babbageclunk> wallyworld: oh, yay!
[21:44] <wallyworld> it's in the description :-)
[21:44] <babbageclunk> wallyworld: I was thinking some of the changes looked familiar.
[21:44] <perrito666> babbageclunk: that did sound like a Cards Against Humanity white card :p
[21:45] <babbageclunk> perrito666: yeah, I thought that as I was typing it.
[21:53] <wallyworld> babbageclunk: what i'll do is make all fixes to the second branch and just do the one landing
[22:06] <babbageclunk> wallyworld: ok
[23:02] <anastasiamac> wallyworld: could u plz reply to question on bug 1567169 - tyvm
[23:02] <mup> Bug #1567169: juju deploy bundle does not honor existing machine definitions <conjure> <deploy> <native-deploy-gap> <s390x> <uosci> <OpenStack Charm Test Infra:Confirmed> <juju:Triaged> <juju-core:Invalid> <https://launchpad.net/bugs/1567169>
[23:05] <wallyworld> anastasiamac: it's more a matter of when will the logical mapping be done. i'm not sure if it's on the radar yet
[23:05] <wallyworld> i had thought someone was looking at it but not sure
[23:06] <anastasiamac> wallyworld: the question was whether there is a workaround and there is none.
[23:07] <wallyworld> outside of a bundle, you can use placement directives to some extent but i don't know off hand what bundles support in that area
[23:10] <anastasiamac> wallyworld: my understanding - bundles do not support deploying to existing machines. no workaround. plz add a political correct response since u've fielded previous query.. It looks to me like the user is asking your opinion ;)
[23:11] <wallyworld> no but bundle may support placement directives which could be used in some way. i can't answer until that is known
[23:12] <anastasiamac> wallyworld: right now, the answer that they want is to the question "whether there is a workaround". Current answer si "no workaround at this stage"
[23:12] <wallyworld> no, there may be a workaround, thayt's my point
[23:13] <wallyworld> placement directives might be able to be used if supported
[23:14] <anastasiamac> wallyworld: placement directives are not supported in bundle AFAIK
[23:14] <anastasiamac> wallyworld: however
[23:14] <anastasiamac> wallyworld: if u know otherwise, plz indicate who is best person to ask, if not u
[23:15] <wallyworld> just looking at the code, the bundle struct does have them
[23:15] <wallyworld> but the comments are unclear
[23:23] <wallyworld> anastasiamac: more investigation is needed since TestDeployBundleMachinesUnitsPlacement and the bundle code seem to indicate that the placement they want should still work even though that contradicts our stated position and the bug report
[23:47]  * babbageclunk runs