[00:05] <blahdeblah> I've been digging some more, and I don't think this is a problem with juju or relation scopes; I think it's just a bug with reactive states not firing.
[00:31] <menn0> blahdeblah: ah ok. i've asked around in our standup and the general thinking was that what you're trying should work
[00:32] <menn0> blahdeblah: and certainly if it isn't supported and juju isn't giving you an error then that's a bug
[00:32] <blahdeblah> menn0: yeah - I think this is a charm or layer bug
[00:32] <menn0> blahdeblah: ok well let me know if you want me to look further
[00:32] <blahdeblah> The hooks are definitely firing
[00:32] <blahdeblah> all good - thanks for the help
[00:33] <blahdeblah> menn0: Although if you know anyone around who understands the ins & outs of https://jujucharms.com/docs/2.0/developer-layers-interfaces, please point me to them. :-)
[00:33] <blahdeblah> Ecosystem channel is dead quiet in APAC times.
[00:33] <blahdeblah> esp. with US holidays on
[00:33] <menn0> blahdeblah: I don't think there's any layers experts here atm
[00:34] <menn0> blahdeblah: the eco team are definitely your best bet
[00:36] <blahdeblah> menn0: Yeah - this might end up having to wait until next week.  AFAICT, though, the scopes referred to in the above link don't have anything to do with juju relation scopes as defined in metadata.yaml.  I could be wrong, though.
[01:57] <anastasiamac> axw: forgot to mention at standup - i'll b missing monday one :) have fun \o/
[01:58] <axw> anastasiamac: okey dokey
[01:58] <anastasiamac> axw: and wednesday one :)
[02:35] <babbageclunk> menn0: Can you chuck a tick on https://github.com/juju/juju/pull/6612?
[02:38] <menn0> babbageclunk: done
[02:39] <menn0> babbageclunk: did you try the upgrade with the index missing?
[02:39] <menn0> just in case
[02:41] <babbageclunk> menn0: I mean, I have a test for that case
[02:41] <babbageclunk> menn0: Ok, trying it on the controller I have running now.
[02:53] <wallyworld> axw: if you get a chance, here's a small +37/-30 cmr tweak https://github.com/juju/juju/pull/6613
[02:58] <axw> wallyworld: I don't really understand why you've changed it from token back to ID, we're not supposed to be exposing IDs across controllers
[02:58] <wallyworld> axw: the next step in the processing will take the local info and 1) export, 2) send to other model
[02:59] <wallyworld> so instead of exporting relations as a side effect of loading the info, and then exporting units explicitly later
[02:59] <wallyworld> the exports will all be done together
[02:59] <wallyworld> exporting as a side effect of RemoreRelations() which is a getter is wrong imo
[03:00] <axw> wallyworld: don't understand "take the local info ..." implies we're pushing, I thought this was all going to be a pull model? i.e. I watch relations in the remote side, it doesn't push them to me
[03:01] <wallyworld> quick ho?
[03:01] <axw> sure, see you in 1:1
[03:01] <babbageclunk> menn0: So I tried it with the index dropped and it gives an error - apparently the code isn't 0 sometimes. I'll change it to look before leaping instead.
[03:13] <babbageclunk> menn0: Wow, apparently if you screw up an upgrade step you can really leave the controller pretty hosed.
[03:14] <menn0> babbageclunk: yeah... there was a rough plan of how we might roll back but that was dropped from scope
[03:15] <menn0> babbageclunk: hence the need to make sure upgrade steps are really solid
[03:15] <menn0> babbageclunk: in fact, do you have a unit test which runs the upgrade step twice
[03:15] <menn0> babbageclunk: that's pretty standard ... to help ensure they are idempotent
[03:15] <menn0> babbageclunk: would have caught this
[03:20] <babbageclunk> menn0: I have a test that checks this, although not running it twice, just running it with the index already not existing. It seems like the error code changes for some reason, although the message doesn't.
[03:21] <babbageclunk> menn0: I'll add another call to the upgrade function test just to be extra sure.
[03:29] <menn0> sweet
[03:39]  * menn0 is DONE
[03:39] <menn0> after several super long days this week I'm toast
[03:39] <menn0> have a good weekend all
[04:42] <axw> wallyworld: havent gone anywhere yet :)  lgtm
[04:44] <wallyworld> axw: awesome ty
=== frankban|afk is now known as frankban
[10:39] <voidspace> macgreagoir: the standup idea was fine
[10:39] <voidspace> macgreagoir: what are we doing instead?
[10:39] <voidspace> macgreagoir: I'm still half dead with exhaustion (poorly kid), but working today...
[10:40] <macgreagoir> voidspace: I'm easy, if ngz and frobware are about at 11 to have stand-up earlier. Otherwise,  I guess stick with the usual.
[10:40] <macgreagoir> *mgz
[10:42] <macgreagoir> voidspace: Sick child is no fun! :-/
[10:42] <mgz> macgreagoir: yeah, I'm fine with 11
[10:44] <macgreagoir> voidspace mgz: Cool, let's see if frobware can make 11 and take it from there.
[10:44] <voidspace> mgz: macgreagoir: cool
[10:44] <voidspace> macgreagoir: yeah, the lad is fine - but he has croup and a chest infection, so his sleep (and therefore ours) is very interrupted
[10:45] <voidspace> he's a bit better today and by the end of the weekend he'll be fine
[10:45] <macgreagoir> voidspace: Good luck. You have my sympathy.
[10:45] <voidspace> macgreagoir: thanks
[11:03] <macgreagoir> voidspace frobware HO?
[11:03] <voidspace> macgreagoir: omw
[12:11] <kjackal> Hey just noticed something with the "juju register" command. It does not add the password field inside the ~/.local/..../accounts.yaml . is this intentional?
[12:53] <perrito666> morning all
[12:53] <perrito666> voidspace: sorry to botter, would you mind reviewing https://github.com/juju/juju/pull/6617 and https://github.com/go-goose/goose/pull/34/files they are rather urgent
[12:56] <macgreagoir> mgz: I see some new goose-related PRs are in.
[12:59] <voidspace> perrito666: looking
[13:00] <voidspace> perrito666: 6617 looks fine
[13:00] <voidspace> perrito666: has it been verified that it fixes the issue (no QA steps in PR)?
[13:00] <voidspace> perrito666: if it has been actually tried and we know it works I will LGTM it
[13:06] <voidspace> mgz: could you take a look at https://github.com/go-goose/goose/pull/34/files
[13:06] <voidspace> mgz: I don't feel qualified.
[13:06] <macgreagoir> mgz: fnordahl's juju change lgtm. I'll let you look at the go-goose change (seems OK too, at first glance).
[13:14] <perrito666> voidspace:
[13:14] <voidspace> perrito666
[13:14] <perrito666> I believe you are in cc on the mail where the guy sent the patch
[13:18] <voidspace> perrito666: I can't easily find it if I am
[13:19] <voidspace> perrito666: what's the title?
[13:22] <voidspace> perrito666: I've added my LGTM on the proviso that we know it works
[13:22] <voidspace> perrito666: I think mgz needs to review the goose PR
[13:45] <perrito666> sorry I was afk
[13:46] <perrito666> voidspace: "broken openstack deployment"
[14:03] <mattyw> hey folks, does anyone know of a reason we might get an error calling the is-leader tool? (https://github.com/juju/juju/blob/juju-1.24.7/worker/uniter/runner/jujuc/is-leader.go#L47)
[14:41] <mgz> I approved the goose pr.
[14:52] <macgreagoir> mgz: I had a couple of comments in the PR, but no show-stoppers.
[14:52] <mgz> yeah, I saw
[14:58] <Mmike> marcoceppi, 1.25.8 is still not in the archives - sorry to bother you like this, but customers.... :/
[15:47] <frobware> macgreagoir, voidspace, jam: PTAL @ https://github.com/juju/juju/pull/6618
[15:49] <voidspace> frobware: tal
[15:50] <frankban> hey wallyworld, or anyone: how can I specify to always use local jujud as the agent when bootstrapping? AFAICT from reading the code, --build-agent always builds the agent, and I don't want simplestreams tools in the server for my usecase
[16:02] <frobware> looks like the build bots are out of RAM - /usr/lib/go-1.6/pkg/tool/linux_amd64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
[16:04] <voidspace> frankban: I've had to force it by putting a fake version in place
[16:08] <mgz> frobware: what job, more specifically?
[16:08] <frobware> mgz: http://juju-ci.vapour.ws/job/github-check-merge-juju/296/console
[16:09] <mgz> okay, so probably not cleaning up lxd containers still and no one's been around to manually delete them
[16:14] <frobware> macgreagoir, voidspace, jam: PTAL @ https://github.com/juju/juju/pull/6619
[16:15] <voidspace> frobware: 6618 LGTM
[16:16] <frobware> voidspace: ty
[16:16] <voidspace> frobware: what are the additional print statements for in 6619?
[16:17] <frobware> voidspace: they print to memory files. I then compare and if the nett result of all the stanzas is the same before bridging, then we don't do anything.
[16:17] <voidspace> frobware: ah!
[16:17] <voidspace> frobware: cool, LGTM
[16:17] <frobware> voidspace: I could have compared data structures, but that seemed messier and more involved.
[16:18] <voidspace> frobware: no test for this?
[16:18] <frobware> voidspace: there are already tests - but those tests don't test beyond --activate (that calls ifdown/up)
[16:19] <voidspace> frobware: so you think this change is untestable?
[16:19] <mgz> frobware: http://paste.ubuntu.com/23532856
[16:20] <frobware> voidspace: for each input sample we have we already call the script, then call the script again verifying it is idempotent.
[16:21] <voidspace> frobware: but that will be true both before and after this change
[16:21] <frobware> voidspace: https://github.com/juju/juju/blob/staging/provider/maas/bridgescript_test.go#L130
[16:22] <voidspace> frobware: so it doesn't test the exit call
[16:22] <frobware> voidspace: that should have been line #138
[16:22] <frobware> voidspace: nope
[16:22] <voidspace> frobware: if you think it isn't reasonably  possible to test then fine
[16:22] <voidspace> so long as we've thought about it
[16:23] <voidspace> frobware: I've added a reluctant LGTM ;-)
[16:23] <frobware> voidspace: the problem is, once you get to this part of the code, it calls ifdown/ifup,brtcl,et al and needs to run as root. We could mock all that, but ... ?
[16:23] <voidspace> frobware: yeah, that's a horrible road to go down
[16:24] <frobware> voidspace: IMO, nothing would be gained from mocking those.
[16:24] <frobware> voidspace: I'm open to moving the cur/new comparison to before those calls.
[16:24] <voidspace> yep
[16:24] <frobware> voidspace: mocking perfectly behaving bonded interfaces... nah!
[16:24] <mgz> frobware: okay, manually deleted all those, 12G mem free again, feel free to retrigger check
[16:25] <frobware> mgz: retrigger is just !!retry!! ?
[16:25] <voidspace> frobware: if you can think of a way to make it testable, then great - but don't burn too much time on it
[16:26] <mgz> frobware: yup
[16:28] <frobware> voidspace: I think one problem we have is sepration of concerns: the bridge script should just do the transformation. something else should invoke the $necessary.
[16:33] <voidspace> frobware: yep, that sounds better
[16:35] <frobware> voidspace: http://pastebin.ubuntu.com/23532923/
[16:42] <voidspace> frobware: I think I'm being dumb, how does that help us?
[16:42] <voidspace> frobware: it means there's no output at all for nil changes
[16:42] <voidspace> frobware: so we can now test that?
[16:42] <frobware> voidspace: the unit tests never pass --activate
[16:43] <frobware> voidspace: you'd be disappointed if they did.
[16:43] <voidspace> frobware: so they weren't getting that far
[16:43] <frobware> voidspace: nope, hence why I stuck this after the case where the unit tests never deal with
[16:43] <voidspace> cool
[16:44] <frobware> voidspace: so A or B?
[16:44] <voidspace> hah
[16:44] <frobware> voidspace: Rock and Hard place. :)
[16:44] <voidspace> frobware: with the latest one, can you add a new test case for the "nil change"?
[16:44] <frobware> voidspace: nope, because we never want activate.
[16:45] <voidspace> oh, I see - we'll still exit either way
[16:45] <voidspace> in which case it makes no difference
[16:45] <voidspace> not really
[16:45] <voidspace> frobware: go with what's in the PR
[16:45] <frobware> voidspace: right. what we have now only happens at runtime (as opposed to unit test time)
[16:46] <frobware> voidspace: I would agree that we're not testing this case. But I think the bigger / better change is to split the functionality up as suggested ^^
[16:46] <voidspace> frobware: yep
[16:54] <frankban> voidspace: fake version in place?
[16:54] <voidspace> frankban: I change the version number of juju so that it can't possibly match anything in simplestreams
[16:54] <voidspace> frankban: this forces juju to upload the jujud I provide
[16:54] <voidspace> frankban: I'm currently using 2.3.0
[16:55] <frankban> voidspace: I see, so juju bootstrap --agent-version 99.0.0 should work...
[16:58] <voidspace> frankban: I change the version number in version.go and recompile
[16:58] <voidspace> frankban: I'm not aware of a command line invocation that will work
[16:59] <voidspace> frankban: just because I'm not aware of it doesn't mean there isn't one though
[16:59] <frankban> voidspace: ok, sounds good, ty
[16:59] <voidspace> frankban: it just means I can't help with that, sorry
[16:59] <frankban> voidspace: you already helped patching versions.go could work in my case
[17:02] <frobware> mgz: ongoing problems? http://juju-ci.vapour.ws/job/github-check-merge-juju/298/artifact/artifacts/lxd-err.log
[17:04] <mgz> frobware: >_<
[17:04] <mgz> this stuff is just not well set up
[17:05] <mgz> there's disk space as far as I can see, what does that error mean exactly...
[17:06] <frobware> mgz: so it appears that the container simply doesn't exist??? Is that what I'm seeing from the logs?
[17:09] <mgz> frobware: I think the implication is the zfs filesystem is screwed
[17:09] <mgz> but I'm really not sure
[17:09] <frobware> mgz: why don't we reduce the surface area for things that can go wrong. Let's switch to ufs/ext4. For testing, I care about stability. then speed.
[17:10] <frobware> mgz: I need to EOD. Apologies for leaving this hanging.
[17:11] <mgz> though the error on the run after is different
[17:11] <mgz> I'll restart the box and retry, and leave a note for balloons
=== frankban is now known as frankban|afk