[01:17] <axw> wallyworld: I have a few fixes for vsphere in https://github.com/juju/juju/pull/7256, I'd appreciate a review at some point so I can land it for the beta
[02:19] <cmars> anyone up for a fairly mechanical review? https://github.com/juju/juju/pull/7253
[02:20] <cmars> pm me if you have any questions
[02:31] <mup> Bug #1682827 changed: Bootstrap on OpenStack Cloud fails <juju:New> <https://launchpad.net/bugs/1682827>
[03:00] <axw> wallyworld: so you ok with me landing that MAAS PR then?
[03:01] <wallyworld> yeah
[03:01] <wallyworld> we can followup over the next few days and try and get it validated
[03:10] <cmars> axw, thanks for the review
[03:11] <axw> cmars: np
[03:18] <wallyworld> axw: the vsphere pr is reviewed
[03:18] <axw> wallyworld: thanks
[03:18] <wallyworld> hopefully that will be the last change for a while... :-)
[03:26] <axw> wallyworld: I'm going to leave it at 2 sec to match what the govc tool does, OK?
[03:26] <wallyworld> axw: sure, np. was just curious
[03:26] <axw> wallyworld: no worries. thanks
[06:30] <jam> axw: it doesn't seem right to disable the default cpu/cores stuff
[06:31] <jam> axw: as you can supply '--constraints' if you really are constrained
[06:31] <jam> the out-of-the-box result should be something that we feel is reasonable for a controller
[06:31] <jam> I know we've had problems with <1GB mem in the past
[06:31] <axw> jam: we already have controller-specific constraitns in the provider/common package
[06:31] <jam> axw: wouldn't that also be expected for any charm?
[06:32] <jam> default cpu cores = 2 might be a bit much
[06:32] <jam> maybe 1 core 1GB ?
[06:32] <jam> but removing it entirely seems like you'll just run into "all these charms just don't seem to work"
[06:33] <axw> jam: AFAIK, no other provider overrides CPU/mem in the provider code
[06:33] <axw> jam: hmm, maybe the 1GB limit is in the provider, mixed in with image selection. seeing it in the azure provider now. I can put that in.
[06:34] <jam> axw: I can't say as to where it exists, but some sort of sane "minimum default" seems useful.
[06:35] <axw> jam: it's different because it'll vary by site. but yes, we should - I thought it was handled outside the provider, but looks like I was wrong
[06:36] <jam> axw: could we just handle the "this is already off" error instead of pre-checking?
[06:36] <jam> not sure if they give clear errors
[06:38] <axw> jam: maybe, not sure if the destroy task will still be actioned if that happens. I'll look at optimising it later
[06:39] <jam> axw: not a big deal, pre-check is always a little bit racy
[06:46] <icey> juju is once again not setting JUJU_AVAILABILITY_ZONE in all cases: https://bugs.launchpad.net/juju/+bug/1684325
[06:46] <mup> Bug #1684325: customize-failure-domain has no effect when ceph-mon is deployed in a container <juju:New> <https://launchpad.net/bugs/1684325>
[07:35] <axw> jam: turns out there's a default of 1GB mem in the OVF anyway, and then vcenter may allocate more. since it's defined in the images and they could change, we should still check - but I'm going to defer until after my current work
[07:36] <jam> axw: k
[07:43] <wallyworld> jam: axw: i checked the code - the controller contraints are processed at bootstrap in withDefaultControllerConstraints() in environs/bootstrap. We honor any constraints the user may have passed in though. why do we think vSphere should be special and get to set it's own constraints that sometimes fail?
[07:43] <jam> wallyworld: juju should be defining default constraints for a controller, it doesn't have to come from vsphere
[07:44] <wallyworld> right, that's what we do
[07:44] <wallyworld> i was confused as to your pushback on the PR
[07:44] <wallyworld> all that was done was special vSphere constraints were removed and we rely on the controller contraints already in place
[07:45] <axw> wallyworld: the one piece I don't think we do in one location, is set default constraints for non-controller machines
[07:46] <axw> wallyworld: e.g. setting 1GB mem. I think we might do that when selecting instance types, but that doesn't apply to vSphere
[07:46] <wallyworld> right, there's aren't any
[07:46] <wallyworld> hmm, ok there could a mem constraint
[07:46] <wallyworld> not sure
[07:47] <axw> wallyworld: anyway, as I said above the OVF says by default that it needs 1GB mem, 2 vCPUs
[07:47] <axw> doesn't specify Hz
[07:47] <wallyworld> so we are ok then
[07:48] <axw> wallyworld: yes, but I think we should check the minimum memory, in case the images change, or images for other series/OS come along
[07:48] <wallyworld> if that's what we do for other providers, sgtm
[07:48] <axw> wallyworld: doesn't need to be done as a constraint, just check the ImportSpec that gets generated from the OVF
[07:49] <axw> I'll do it later, working on higher priority things atm
[07:49] <wallyworld> yep
[07:50] <wallyworld> axw: no rush since you have stuff happening; if you get a chance, but can wait till tomorrow, i have soccer in a bit anyway https://github.com/juju/juju/pull/7258
[07:51] <axw> wallyworld: ok, probably a bit later - I keep context switching and losing where I'm at :)
[07:52] <wallyworld> yeah, no worries, leave it go, just wanted to let you know it was there for later
[07:52] <wallyworld> tomorrow is fine
[07:52] <wallyworld> the gui doen't even use it yet
[08:07] <rogpeppe> axw, wallyworld, jam: any chance of a review of https://github.com/juju/juju/pull/7254?
[08:07] <wallyworld> rogpeppe: i'm just heading out to soccer but will be back later this evening
[08:08] <rogpeppe> wallyworld: k
[11:14] <mup> Bug #1680582 changed: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:23] <mup> Bug #1680582 opened: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:29] <mup> Bug #1680582 changed: Agents losing connection to leader tracker <canonical-bootstack> <juju-core:Won't Fix> <https://launchpad.net/bugs/1680582>
[11:40] <rogpeppe> here's a small addition to juju/utils, in case anyone cares to review it: https://github.com/juju/utils/pull/273
[12:14] <jam> rogpeppe: I made some comments on it as well
[12:14] <rogpeppe> jam: thanks
[12:14] <rogpeppe> jam: except you're too late :)
[12:14] <jam> rogpeppe: its never too late :)
[12:15] <rogpeppe> jam: well, it's merging already
[12:15] <jam> rogpeppe: sure, but you can always land a follow up
[12:15] <rogpeppe> jam: i'm not convinced by the "no panic ever" thing.
[12:15] <rogpeppe> jam: lots of our code can panic
[12:15] <jam> rogpeppe: we've been bit several times with panic() in production code, and adding more doesn't make it better
[12:16] <rogpeppe> jam: this is something that's easy to verify at the call site - like a number of panics that are in the go stdlib
[12:17] <jam> rogpeppe: well, I'd guess that not all callers are going to be passing in consts
[12:17] <rogpeppe> jam: more-or-less anything that takes a pointer as an argument can panic
[12:17] <rogpeppe> jam: in practice, all callers are passing in a const for the "var=" part
[12:18] <rogpeppe> jam: in this case, i think i prefer the panic to making it return an error
[12:20] <rogpeppe> jam: FWIW i just used the existing tests from juju/environs/tools/build.go
[12:20] <rogpeppe> jam: the implementation there didn't panic when not passed a "=" - it just silently got it wrong
[12:21] <rogpeppe> jam: i guess it could just silently ignore a badly formatted argument
[12:23] <jam> rogpeppe: if it is only ever used with const values, then I'm ~ok with a panic() but it feels like the type of helper that ends up folded into code that gets called from iterating over an array of env vars someone was asked to set
[12:25] <rogpeppe> jam: ok, i'll make it silently ignore the bad value. i'd prefer that to adding an error return, because it's very convenient to use it inline currently.
[12:26] <jam> thk
[12:26] <jam> thx
[12:27] <rogpeppe> jam: these are the only calls for the moment, BTW: http://paste.ubuntu.com/24419916/
[12:28] <rogpeppe> jam: thanks for the review of https://github.com/juju/juju/pull/7254
[12:34] <rogpeppe> jam: here you go: https://github.com/juju/utils/pull/274
[12:35] <jam> rogpeppe: lgtm
[12:36] <rogpeppe> jam: thanks
[12:36] <rogpeppe> jam: wanna approve it on the PR?
[12:36] <jam> I did
[12:36] <jam> well, I hit approve, apparently not submit review
[12:36] <jam> rogpeppe: done
[12:37] <rogpeppe> jam: thanks
[13:17] <wpk> jam: what's the PR you wanted to get reviewed?
[13:17] <jam> https://github.com/juju/juju/pull/7260
[13:22] <zeestrat> Is there a way to use dynamic variables such as env variables when deploying bundles with the native juju deploy in 2.x?
[13:32] <wpk> is there a doc on building juju dpkg?
[13:32] <wpk> *deb
[13:32] <wpk> ?
[13:34] <rogpeppe> anyone have a clue what failed here? http://juju-ci.vapour.ws:8080/job/github-merge-juju-utils/178/console
[13:40] <wpk> glitch in matrix
[13:40] <wpk> watch out for people in black coats
[13:42] <rogpeppe> wpk: :)
[13:43] <rogpeppe> here's a small change to make the cmd tests pass under Go tip: https://github.com/juju/juju/pull/7261
[16:47] <rogpeppe>  i'm looking for a second review of this if poss, please: https://github.com/juju/juju/pull/7261
[21:01] <thumper> morning