[00:00] <menn0> anastasiamac, thumper: heads up. this is pretty important: https://bugs.launchpad.net/juju/+bug/1676427
[00:00] <mup> Bug #1676427: juju.txns mongo collection getting out of control <canonical-is> <juju:Triaged> <https://launchpad.net/bugs/1676427>
[00:00] <menn0> anastasiamac, thumper: I have some ideas about how to deal with it which I'll write on the bug. I'm not sure that I should pick it up though.
[00:34] <menn0> thumper or axw: https://github.com/juju/juju/pull/7151 pls
[00:34]  * thumper looks
[00:37] <thumper> menn0: LGTM
[00:37] <menn0> thumper: cheers
[00:40] <menn0> cmars: done. ship it with one tiny thing
[00:47] <cmars> menn0, thanks
[03:56] <babbageclunk> wallyworld: hey, I'm a bit confused about the public/private address on machines thing - calling unit.PublicAddress does just call through to machine.PublicAddress.
[03:56] <wallyworld> babbageclunk: so is thr thought that the machine public address method falls back t private
[03:57] <babbageclunk> wallyworld: But the problem is that calling machine.SetProviderAddresses with only a cloud-local address still sets both public and private on the machine
[03:57] <wallyworld> babbageclunk: we can work with that right? the address that comes back shoild have a scope?
[03:57] <wallyworld> so we call public() and then check the scope
[03:58] <babbageclunk> wallyworld: yeah, true - things will do the right thing if there's a public address.
[03:58] <wallyworld> babbageclunk: and we fail if scope != public unless region/enant/etc match
[03:58] <babbageclunk> wallyworld: ok - I'll do it at that level
[03:58] <wallyworld> ty
[04:01] <wallyworld> babbageclunk: btw, thanks a lot for the reviews, much appreciated
[04:01] <babbageclunk> wallyworld: no worries, sorry, should have pinged you about them
[04:01] <wallyworld> tis totally ok
[04:02] <wallyworld> i'm knee deep in the next one
[04:02] <wallyworld> permissions are somewhat fun the way we did them
[04:12] <menn0> thumper: you still around?
[04:57] <thumper> menn0: ack
[18:18] <kwmonroe> hey juju-dev, are application-constraints in bundles still supported in 2.1?  https://bugs.launchpad.net/juju/+bug/1676986
[18:18] <mup> Bug #1676986: juju doesn't honor bundle application constraints (2.1.2) <juju:New> <https://launchpad.net/bugs/1676986>
[18:23] <rick_h> kwmonroe: totally, and tests case here: https://github.com/juju/charm/blob/v5/bundledata_test.go#L113
[18:23] <kwmonroe> rick_h: that thar is a machine constraint
[18:23] <rick_h> kwmonroe: but above it is an application one
[18:24] <rick_h> kwmonroe: now...root-disk should work as well but not in the test there. hmmm
[18:24] <kwmonroe> oh, well, whatever, you should have sent me to the right line ;)
[18:24] <rick_h> kwmonroe: yea, sorry. I was looking at both but you're right oops
[18:25] <rick_h> kwmonroe: I was more worried if space split would work or if they needed to be ,
[18:25] <rick_h> but looks like space is ok there
[18:26] <kwmonroe> yeah, so i've tried both "mem=X" and "mem=X root-disk=Y" in my sample bundle (in the above bug).  lemme try something..
[18:26] <kwmonroe> (i'm gonna try adding a machine constraint too to see which one wins)
[18:32] <kwmonroe> alrighty rick_h, bug updated.. machine constraints are 2legit2quit.  app constraints seem ignored.
[18:33] <kwmonroe> -> https://bugs.launchpad.net/juju/+bug/1676986
[18:33] <mup> Bug #1676986: juju doesn't honor bundle application constraints (2.1.2) <juju:New> <https://launchpad.net/bugs/1676986>
[18:33] <rick_h> kwmonroe: booo :(
[18:34] <kwmonroe> total boo broham.  and what worse is i'm gonna have to report this during the juju show.  no way around it.
[20:42] <thumper> hml: morning
[20:42] <thumper> hml: have you hooked up the pre-push hook in your juju repo?
[20:42] <hml> thumper: good morning
[20:42] <thumper> hml: among other things it runs go vet
[20:43] <hml> thumper: i’ve seen go vet run… so i think so, perhaps i should double check.  :-)
[20:43] <thumper> just saw some vet errors in openstack firewaller
[20:43] <thumper> which have crept into develop
[20:43] <thumper> hmm, probably someone else then
[20:43] <thumper> perhaps I should check blame
[20:44] <hml> thumper: checking now.
[20:44] <thumper> I just thought of you when thinking of recent openstack work
[20:44] <hml> thumper: :-)
[20:45] <thumper> oh dear
[20:45] <thumper> actually was axw
[20:45] <thumper> but the bug is bad
[20:45] <thumper> 97467364 (Andrew Wilkins     2016-11-22 12:05:25 +0800 237)                             suffix := fmt.Sprintf("%s-%s", c.environ.Config().UUID(), serverId)
[20:45] <hml> thumper: ha.  i’m setup with pre-push hooks now.
[20:45] <thumper> looking for a suffix of a security gropu
[20:45] <thumper> however
[20:45] <hml> thumper: and before you asked
[20:45] <thumper> provider/openstack/firewaller.go:237: arg c.environ.Config().UUID() for printf verb %s of wrong type: (string, bool)
[20:46] <thumper> so... the suffix probably isn't what is expected
[20:46] <hml> thumper: I was messing in security group code a few weeks ago
[20:46] <thumper> yeah, I recalled that
[20:47] <thumper> this is clearly a bug though
[20:47] <thumper> the suffix generated is not good
[20:47] <thumper> perhaps it is not good in all the places
[20:47] <thumper> so at least consistently not good
[20:47] <thumper> but I don't know
[20:49] <babbageclunk> thumper: shouldn't we be running go vet in the build?
[20:49] <hml> thumper: question, i have that line of code in my working area, but if i run go vet on firewaller.go, i’m not seeing that output.  any reason why?
[20:49] <thumper> babbageclunk: yes, that is a long standing issue
[20:49] <babbageclunk> oh good
[20:50] <thumper> hml: interesting, the line of code the same? also, what version of go are you using?
[20:50] <hml> thumper: 1.8
[20:51] <thumper> hmm, I'm using 1.6
[20:51] <hml> thumper: the line of code looks the same
[21:18] <hml> babbageclunk: do you have a few minutes for a hangout?  i think i have the cause of the auth bug nailed, but not sure of the best way to resolve it.
[21:18] <babbageclunk> hml: sure - in standup?
[21:19] <hml> see ya there
[21:27] <wallyworld> hml: you solved it?
[21:27] <hml> wallyworld: nope… just know the answer…
[21:27] <hml> wallyworld: join us in standup?
[21:28] <wallyworld> the first step :-)
[21:28] <wallyworld> i have a meeting in 2 minutes but can quickly pop in
[21:59] <babbageclunk> wallyworld: ping me when you're off the phone?
[22:00] <wallyworld> babbageclunk: ping
[22:08] <babbageclunk> wallyworld: ha, was so quick I missed it.
[22:09] <babbageclunk> wallyworld: looks like erroring with no public address causes problems in lxd
[22:09] <wallyworld> babbageclunk: talk in ho?
[22:10] <wallyworld> i didn't think we'd error
[22:10] <wallyworld> i thought we'd fall back to private
[22:10] <wallyworld> under the right circumstances
[22:10] <wpk> Q: is there a publicly available presentation showing how awesome Juju is?
[22:11] <wpk> (something like what Marco did in NOLA)
[22:11] <wallyworld> there would be, not sure who to ask though
[22:13] <wallyworld> babbageclunk: did you want to chat about it?
[22:14] <babbageclunk> wallyworld: no that's fine - I must have misunderstood - taking out the error.
[22:14] <wallyworld> babbageclunk: ok. we should error sometimes though
[22:14] <wallyworld> when we can't quarantee connectivity
[22:14] <babbageclunk> wallyworld: hmm, under what circumstances?
[22:15] <wallyworld> same region/tenant etc
[22:15] <babbageclunk> wallyworld: you mean if we fall back to cloud-local and those other things don't match.
[22:15] <wallyworld> right, but it's going to be provider specific
[22:16] <wallyworld> eg need to account for vpc with aws
[22:17] <babbageclunk> wallyworld: ok, so we need to define a provider-specific way of deciding whether a cloud-local address is usable.
[22:17] <wallyworld> yes. we talked about a new interfcae method
[22:17] <wallyworld> CanModelsConnect() or something
[22:17] <wallyworld> never settled on the name
[22:18] <wallyworld> naming things is hard :-)
[22:18] <babbageclunk> I didn't think I needed to tackle that yet.
[22:18] <wallyworld> was hoping not to but we may need a stub implementation to make lxd work
[22:18] <babbageclunk> Really I don't for now, right? In all of the places where they're not connectable we'll have a public address.
[22:19] <wallyworld> but not for lxd right?
[22:19] <babbageclunk> In that case the private addresses will always be connectable though.
[22:19] <wallyworld> right. but we need a way to tell juju that
[22:20] <wallyworld> so a stub implementation for that method may be needed
[22:20] <babbageclunk> wallyworld: let's hangout!
[22:20] <wallyworld> ok
[23:07] <mup> Bug #1613855 changed: SetAPIHostPorts runs afoul of "state changing too quickly" <juju:Fix Released by mfoord> <juju-core:Fix Released by thumper> <https://launchpad.net/bugs/1613855>
[23:33] <hml> wallyworld: if you get a chance, my subnet PR is updated: https://github.com/juju/juju/pull/7140
[23:33] <wallyworld> looking
[23:42] <wallyworld> hml: just a small tweak, looks good thanks