[00:03] <thumper> wallyworld: added a comment to that review...
[00:03] <wallyworld> ok
[00:04] <wallyworld> thumper: it needs to be a file, not a dir
[00:04] <thumper> filepath.Join(c.MkDir(), "somefile"),
[00:04] <wallyworld> doh
[00:05] <wallyworld> sigh
[00:05] <wallyworld> fair point
[00:29] <mup> Bug #1559280 changed: creating hosted model config: opening model: endpoint: expected string, got nothing <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559280>
[00:29] <mup> Bug #1559285 changed: creating hosted model config: opening model: storage-endpoint: expected string, got nothing <bootstrap> <ci> <juju-core:New> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559285>
[01:07] <wallyworld> thumper: that bug is fix committed, i wonder if we could remove the blocker tag to unblock master
[01:15] <cherylj> katco: can you review?  http://reviews.vapour.ws/r/4247/
[01:21] <axw> wallyworld: guessing wildly, I'm wondering if the --config CI is passing has an "authorized-keys" with an empty string value
[01:22] <axw> wallyworld: in controller/modelamanager we don't update the attrs if there's an existing key
[01:22] <axw> wallyworld: we don't check if the value is empty tho
[01:22] <wallyworld> axw: i suspect the same - i am updating the code to account for that - i have passing tests but it is still failing in live testing bit i am close
[01:22] <axw> wallyworld: ok cool
[01:23] <davecheney> lucky(~/src/github.com/juju/juju) % juju kill-controller testing
[01:23] <davecheney> error: controller testing not found
[01:23] <davecheney> lucky(~/src/github.com/juju/juju) % juju bootstrap --upload-tools testing aws/ap-southeast-2
[01:23] <davecheney> ERROR cannot create controller "local.testing" info: model info already exists
[01:23] <davecheney> is it deleted or not !?!?
[01:24] <cherylj> there's already a bug for that, davecheney.  I've had to manually delete things out of cache.yaml to work around it
[01:24] <davecheney> thanks
[01:29] <wallyworld> axw: it's failing because jujud bootstrap command is getting passed a controller model config which still has authorized-keys-path and it creates a cfg using NoDefaults which means this is not stripped out and causes havoc further down the line
[01:29] <axw> wallyworld: argh, of course
[01:30] <wallyworld> axw: i wonder if bootstrap jujud should be using WithDefaults
[01:30] <axw> wallyworld: where?
[01:31] <wallyworld> jujud/bootstrap.go Run()
[01:31] <axw> wallyworld: i don't think so. by that stage, it should have a complete config
[01:31] <wallyworld> but there i think it is simply using what was passed from the bootstrap cmd
[01:32] <wallyworld> so may not be complete
[01:32] <wallyworld> i could be wrong
[01:32] <axw> wallyworld: pretty sure it shouldn't be, possibly broken during changes. will look
[01:34] <wallyworld> axw: so what we should be doing is stripping authorized-keys-path on the bootstrap client side when we read the keys, i'm guessing we don't do that
[01:34] <axw> wallyworld: yep
[01:35] <axw> wallyworld: atm on server we'll ignore authorized-keys if authorized-keys-path is set
[01:35] <axw> wallyworld: so we should remove authorized-keys-path after reading
[01:35] <wallyworld> yep
[01:35] <axw> from hosted model config
[01:35] <axw> wallyworld: actually we do remove after reading, just not from hosted model config
[01:35] <wallyworld> axw: that is done if UseDefaults is used
[01:36] <wallyworld> in my case though host model config does not have that key i don't think
[01:37] <wallyworld> hosted
[01:37] <axw> wallyworld: if bootstrap config has authorized-keys-path, it must've come from --config. everything in --config will be added to hosted model config
[01:38] <wallyworld> yeah
[02:07] <wallyworld> axw: here's a fix http://reviews.vapour.ws/r/4252/
[02:14] <thumper> wallyworld: what was your thinking on unblocking?
[02:14] <wallyworld> thumper: i think we should
[02:15] <thumper> wallyworld: have you personally run the tests on windows?
[02:15] <wallyworld> no, don't have windows
[02:15] <thumper> I'd like to wait until at least someone has run the windows tests
[02:15] <wallyworld> ok
[02:16] <axw> wallyworld: reviewed
[02:16] <wallyworld> ta
[02:31] <natefinch> wallyworld: is the timestamp in a bzr commit ref reliable?  e.g. ian.booth@canonical.com-20141121040613-ztm1q0iy9rune3zt ?  can I parse that timestamp and trust that if I compare two of them, the later one definitely comes from a later ref?
[02:32] <natefinch> wallyworld: context - I'm trying to write an automated dependencies.tsv merge tool
[02:32] <wallyworld> natefinch: i think so
[02:32] <wallyworld> natefinch: for bzr , the rev id is monotonic
[02:33] <wallyworld> ally increasing
[02:33] <wallyworld> so simplier to use that i think
[02:33] <natefinch> I wasn't sure if the id was reliable... either one is fine, I just want to be able to tell which one is later
[02:33] <natefinch> since basically every time I merge dependencies.tsv I just pick whichever commit is later
[02:45] <axw> wallyworld: I've repro'd the "cannot obtain provisioning script" bug, digging in now
[02:45] <wallyworld> axw: what did you do to repro?
[02:46] <axw> wallyworld: bootstrapped lxd provider, added another lxc machine OOB and did "add-machine ssh:.."
[02:46] <wallyworld> axw: hmmm, ok. i basically did the same thing except my bootstrap machine manual
[02:46] <axw> wallyworld: yeah I think I did that last time I tested and that worked
[02:47] <wallyworld> ok, at least then it is explainable
[03:14] <axw> wallyworld: hrm, CI definitely is bootstrapping with manual tho
[03:14] <wallyworld> yeah, go figure
[03:14] <axw> wallyworld: anyway, *seems* to be related to ControllerInstances not returning any instances
[03:15] <davecheney> thumper: http://reviews.vapour.ws/r/4254/
[03:15] <wallyworld> axw: i'm also at a loss as to why show-controller is failing in the restore job
[03:15] <wallyworld> i've asked for more info like the yaml files and args passed to show-controller
[03:16] <axw> wallyworld: ok, haven't gotten to that one yet. I think I see the problem with manual
[03:16] <axw> wallyworld: we're setting use-sshstorage too late now
[03:17] <axw> wallyworld: (dumb config attr name, but still required)
[03:17] <wallyworld> axw: does that explain why it works sometimes?
[03:17] <menn0> thumper: http://reviews.vapour.ws/r/4255/ pls
[03:17] <axw> wallyworld: it would work if the controller machine were able to ssh to itself as ubuntu
[03:18] <wallyworld> which i think it could for me
[03:18] <wallyworld> as i copied my ssh keys across
[03:19] <axw> wallyworld: that'll do it. also, the machine agent will write the "system" public key
[03:19] <axw> but asynchronously, so it's racy
[03:19] <wallyworld> joy
[03:19] <wallyworld> axw: i've gone through the python CI scripts for the restore job and everything appears ok. i though we may have had an issue with default-model name was the same as the controller name which is what the scripts do but i tested that and show-controller worked
[03:20] <wallyworld> so it appears the scripts bootstrap, do some stuff, then attempt to call show-controller and that fails
[03:21] <axw> wallyworld: is the script swallowing stderr? I don't see any error messages, just the backtrace
[03:21] <wallyworld> yeah, that's part of the issue, i haven't checked but it must be
[03:22] <wallyworld> there's not much to go on
[03:28] <wallyworld> axw: can we rename that use-sshstorage attribute then if you are in the area and we need to retain it for 2.0?
[03:28] <axw> wallyworld: yup
[03:28] <wallyworld> \o/
[03:40] <axw> wallyworld: the issue with lxd is that we're filtering machines by hosted model UUID, and not controller model UUID
[03:40] <wallyworld> axw: for which issue?
[03:40] <axw> wallyworld: so ControllerInstances fails if you call it with the hosted model config
[03:41] <wallyworld> ah the ssh-storage one
[03:41] <axw> wallyworld: no, related, but different
[03:41] <axw> wallyworld: lxd as controller vs manual as controller
[03:41] <axw> you can't add-machine ssh with either
[03:41] <wallyworld> right, both causes affect the ProvisioningScript
[03:42] <axw> yup
[03:42] <axw> wallyworld: I think I might simplify the ProvisioningScript code a bit. we get the Environ to get the addresses ... but we already store addresses in state
[03:42] <axw> so I'll just have it grab them out of state
[03:42] <wallyworld> sgtm
[04:30] <axw> wallyworld: https://github.com/juju/juju/pull/4816
[04:31] <wallyworld> looking
[04:40] <wallyworld> axw: hoow does that simplifcation work around the bug?
[04:40] <axw> wallyworld: environs.APIInfo calls ControllerInstances. ControllerInstances is broken for lxd and manual when called with hosted model config
[04:40] <axw> possibly other providers too
[04:41] <wallyworld> ah right, that's the bit i was missing, that APIInfo called ControllerInstances
[04:53] <mup> Bug #1559706 changed: TestFinalizeCredentialInvalidFilePath fails on windows <blocker> <ci> <regression> <unit-tests> <windows> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1559706>
[05:04] <axw> wallyworld: no rush, PR to drop use-sshstorage: https://github.com/juju/juju/pull/4817
[05:04] <wallyworld> ok, will look in 5
[05:11] <wallyworld> axw: small one also http://reviews.vapour.ws/r/4260/
[05:13] <axw> wallyworld: LGTM
[05:13] <wallyworld> ta
[05:44] <mup> Bug #1555744 changed: kill-controller / destroy-controller prevents reuse of controller name <docteam> <juju-release-support> <juju-core:Invalid by wallyworld> <https://launchpad.net/bugs/1555744>
[05:44] <mup> Bug #1559844 opened: InvalidVolumme.NotFound error destroying aws environment <juju-core:Triaged> <https://launchpad.net/bugs/1559844>
[05:46] <axw> wallyworld: last one: https://github.com/juju/juju/pull/4819
[05:46] <wallyworld> ok
[05:54] <wallyworld> axw: lgtm
[05:54] <axw> wallyworld: ta
[05:55] <axw> wallyworld: see my reply to your comment?
[05:55] <wallyworld> no, looking
[05:55] <wallyworld> yeah probably
[06:05] <wallyworld> axw: do you have a recollection of an destroying aws environment and getting an InvalidVolume.NotFound error as per the bug above? i seem to recall we had seen that and may it was supposed to be fixed
[06:06] <axw> wallyworld: I don't recall anything specific, sorry
[06:06] <wallyworld> sure, np
[08:02] <wallyworld> axw: our cleanup after failed bootstrap still could leave inconsisent metadata; this pr partially addresses that http://reviews.vapour.ws/r/4262/
[08:30] <axw> wallyworld: you can't environs.Prepare with an existing controller name, so most of that doesn't make sense. it works because you're reinstating old stuff, but it would be simpler to just check if the environs.Prepare error is not "AlreadyExists", and revert only then
[08:30] <axw> I mean, it makes sense, but it's not very straight forward
[08:32] <axw> wallyworld: actually, it doesn't do the right thing in that case. I'll just comment on the PR
[09:25] <axw> wallyworld: just need to write some tests for login itself, then I can propose the basics
[09:31] <wallyworld> axw: sgtm, admin controller branch currently in CI
[09:44] <TheMue> morning
[10:02] <dimitern> voidspace, ping
[10:09] <mup> Bug #1542206 changed: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Invalid> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[10:21] <voidspace> dimitern: got someone with me, be free about 11'ish
[10:25] <dimitern>  voidspace ok, ping me then please
[11:04] <voidspace> dimitern: ping
[11:04] <voidspace> dimitern: actually, gimme 5  - gonna reboot
[11:04] <dimitern> voidspace, sure
[11:04] <voidspace> dimitern: half my windows have dissappeared and won't return *grrr*
[11:07] <voidspace> dimitern: aaaaand back
[11:07] <voidspace> dimitern: you wanna hangout?
[11:10] <dimitern> voidspace, hey, omw
[11:45] <jamespage> dimitern, morning - do we have any other flags on network-get other than primary-address?
[11:45] <jamespage> I could really do with understanding the cidr for a binding as well
[11:45] <jamespage> that is discoverable - but just wondered...
[11:47] <dimitern> jamespage, not yet, but more args are planned
[11:47] <dimitern> jamespage, well, it wasn't really possible to report back anything but the address until the multi-nic work
[11:48] <dimitern> jamespage, so now I guess we can give you the full proposed YAML/JSON output, as discussed in the network-get spec?
[11:49] <jamespage> dimitern, well we can parse a yaml OK :-)
[11:49] <jamespage> dimitern, is that already accessible?
[11:50] <jamespage> or is that work for you?
[11:51] <dimitern> jamespage, now almost the complete information about machine's interfaces and addresses is available in state and to network-get
[11:51] <jamespage> dimitern, ok - so I just need to parse that
[11:51] <jamespage> right-oh
[11:52] <dimitern> jamespage, just a sec, let me paste a straw-man proposal of what network-get can return without --primary-address
[11:59] <dimitern> jamespage, how does this look ? http://paste.ubuntu.com/15455682/
[12:05] <voidspace> dimitern: https://github.com/juju/juju/pull/4822
[12:05] <voidspace> dimitern: http://reviews.vapour.ws/r/4264/
[12:06] <jamespage> dimitern, is cidr-address the ip address with the netmask? or the subnet cidr?
[12:07] <dimitern> voidspace, LGTM
[12:07] <dimitern> jamespage, yeah, like in /e/n/i: address 10.20.19.100/23
[12:07] <dimitern> s/\23/\24/
[12:09] <dimitern> jamespage, please note there are potentially multiple devices that will be returned for a given binding
[12:09] <voidspace> dimitern: thanks
[12:14] <lq> http://linkcash.co/2Zn
[12:15] <jamespage> dimitern, why would multiple bindings be returned?
[12:15] <jamespage> sorry devices, not bindings?
[12:17] <dimitern> jamespage, well, if you have 2 addresses from the same subnet of the same device
[12:18] <dimitern> jamespage, or alternatively - 2 devices each with addresses from the same space the binding is on
[12:18] <dimitern> jamespage, s/each with addresses/each with an address/
[12:32] <axw> wallyworld: replied to your PR if you want to take another look
[12:32] <wallyworld> sure
[12:33] <wallyworld> axw: so it ensures that current account value is correct for example?
[12:33] <axw> wallyworld: yep. current account is per controller
[12:34] <axw> wallyworld: remove the controller and it doesn't make sense anymore, so we remove that info
[12:34] <wallyworld> right, but then we should ensure it is reset to what it was
[12:35] <wallyworld> i guess that happens when we reset the current controller
[12:35] <axw> wallyworld: there's two possibilities: you just created hte controller, or you didn't. if you created it, there was no value. if you didn't, attempting to create the controller again fails
[12:36] <axw> (and you don't update models/accounts/bootstrap-config)
[12:36] <wallyworld> and it decorateAndWrite fails half way through, restting current controller should be enough
[12:37] <axw> wallyworld: resetting current-controller and removing the controller from ClientStore
[12:37] <wallyworld> yes
[12:37]  * axw nods
[12:37] <wallyworld> we remove current controller but don't currently reset
[12:38] <axw> wallyworld: so: move defer up, like you did; reset current-controller; don't remove controller if errors.IsAlreadyExist(err)
[12:38] <axw> wallyworld: agree?
[12:38] <wallyworld> axw: yep, i've already fixed the error check
[12:39] <axw> cool
[12:44] <wallyworld> axw: should be good to go
[12:46] <axw> wallyworld: still a bit weird: cannot destroy newly created controller details "my-controller" info
[12:46] <axw> wallyworld: "controller %q details" would be less weird to me
[12:47] <axw> dropping info
[12:47] <wallyworld> ffs, i'm tired
[12:47] <wallyworld> fixing
[12:47] <axw> no doubt
[12:48] <axw> wallyworld: LGTM, thanks
[12:48] <wallyworld> so as of now, i can't quite see the failure mode that would lead to people not being able to bootstrap with the same controller name after a failed attempt. there's a bug or two on that. maybe we have fixed stuff the past week or two
[12:49] <axw> wallyworld: you mean with that fix?
[12:49] <axw> wallyworld: if environs.Prepare fails half way through then you're buggered (without that fix)
[12:49] <wallyworld> yeah, once this goes in, plus i think there's been other small cleanips
[12:50] <wallyworld> i was more hoping out loud we'd be ok now
[12:50] <axw> wallyworld: yeah, otherwise it's down to hitting ctrl-c or power out at the wrong time
[12:51] <axw> wallyworld: I think kill-controller should be expected to work if environs.Prepare returns successfully
[12:51] <wallyworld> axw: i think so too
[12:51] <axw> wallyworld: it would be nice if we had some way to do the prepare transactionally/atomically
[12:51] <wallyworld> yup
[12:52] <axw> wallyworld: write to a separate directory and slide the symlink or something
[12:52] <wallyworld> juju 2.1 :-)
[12:52] <axw> wallyworld: yeah, inclined not to worry about that for now
[12:52] <wallyworld> we got to get this farking adminbranch landed
[13:15] <jamespage> dimitern, which golang version do I need for lxd support?
[13:17] <mgz> jamespage: 1.3 or later
[13:17] <jamespage> mgz, ta
[13:22] <natefinch> jamespage: One thing to keep in mind - if you're using the client built for trusty, it won't have LXD, since it wasn't built with 1.3+
[13:23] <jamespage> natefinch, yes I just hit that
[13:23] <jamespage> natefinch, rebuilding with 1.3
[13:23] <jamespage> its in backports afterall
[13:23] <natefinch> cool
[13:26] <dimitern> jamespage, on trusty you'll need to add trusty-backports to /etc/apt/sources.list and then do apt-get update
[13:29] <axw> wallyworld: for the morning: https://github.com/juju/juju/pull/4823
[13:29] <wallyworld> ok, ty
[13:30]  * axw away
[13:59] <katco> morning all
[14:00] <natefinch> morning
[14:01] <rick_h_> morning katco
[14:01] <katco> natefinch: how's the family?
[14:01] <katco> rick_h_: heyo
[14:01] <katco> rick_h_: hey, i was wondering this over the weekend: are you a full stack guy, or a unit test guy?
[14:02] <natefinch> katco: good.  snow day today
[14:02] <katco> natefinch: uh oh
[14:02] <rick_h_> katco: both!
[14:02] <katco> natefinch: we woke up sat. morning to heavy snow, 1" on the ground. by noon it was all gone and sunny.
[14:02] <rick_h_> katco: I cringe when there's a PR that doesn't address both ends imo
[14:02] <rick_h_> katco: hah, gotta love first day of sprint
[14:02] <rick_h_> spring
[14:03] <rick_h_> damn, been working here too long to s/sping/sprint
[14:03] <katco> rick_h_: where do you feel full-stacks should live? ci?
[14:03] <katco> rick_h_: lol
[14:03] <natefinch> katco: yeah, it's like 5 inches here... gonna be 40° later, but still gotta snowblow or it'll take forever to melt
[14:03] <rick_h_> katco: yes, in a perfect world they're in CI and part of gating landing
[14:03] <katco> rick_h_: cool
[14:03] <rick_h_> katco: only when they take too long to run, should they not be gating landings, and then there's a push to figure out why/speed up
[14:03] <rick_h_> katco: imo and all that :)
[14:04] <katco> rick_h_: hey, everyone's got an elbow ;)
[14:04] <rick_h_> e.g. can we gate on a test on a single platform/etc so that they can be part of the gating process still
[14:05] <rick_h_> but yea, I've seen too many unit tests break an API that isn't noticed because nothing full stack was run that used it.
[14:05] <rick_h_> katco: kind of like updating the mock, and missing that updating the mock means the real things needs an update
[14:08] <katco> rick_h_: yeah, that is definitely an antipattern
[14:08] <rick_h_> katco: that being said, I like it when unit tests break right at the point of function X and say "oh, yea...that got an unexpected arg" and fixing things is much simpler/etc
[14:09] <rick_h_> katco: and with tons more of those, it's much more bitesize/managable to work on a smaller chunk of code
[14:09] <katco> rick_h_: yeah me too. i like it even better when the unit test that tests the actual api meets your interfaces breaks when you change your interface ;)
[14:10] <rick_h_> :)
[14:12] <katco> rick_h_: so when do you get the new camper?
[14:14] <rick_h_> katco: hopefully April sometime
[14:14] <rick_h_> katco: my luck, right before sprints start :P
[14:14] <katco> rick_h_: doh... well maybe you can get it prepped and then go for a get-away when you get back ;)
[14:15] <rick_h_> katco: actually, so think I figured out my camper guy's trip this summer. Figure on heading to St Lious
[14:15] <rick_h_> my wife doens't have an iterest, but taking the boy to the arch would be cool, and we go by chicago
[14:15] <katco> rick_h_: dude! if you make the trip, definitely keep me in the loop!
[14:15] <katco> rick_h_: no pun intended
[14:16] <katco> rick_h_: we have some fantastic natl. parks around here
[14:17] <rick_h_> katco: yea, I think we'll head past chicago, stay somewhere there, hit up chicago for a day, crash, go on to your area. Crash, see the arch/etc. And head back. It's like 8hrs so split between two days makes for a relaxing week trip.
[14:18] <katco> rick_h_: yeah that sounds like a fun trip
[14:19] <jamespage> dimitern, force of habit - I keep creating lxc containers, not lxd ones...
[14:20] <jamespage> dimitern, also noted that lxd in s bundle always creates trusty machines
[14:20] <jamespage> dimitern, resulting in a mismatch when the service is then deployed to them...
[14:23] <natefinch> jamespage: the always trusty thing may just be a problem with configuration.  You need to import non-trusty images and alias them as ubuntu-<series>
[14:24] <natefinch> jamespage: so, like from https://jujucharms.com/docs/devel/config-LXD#images - lxd-images import ubuntu xenial amd64 --sync --alias ubuntu-xenial
[14:24] <jamespage> natefinch, with the maas provider?
[14:24] <jamespage> I'm running from a branch right now....
[14:24] <natefinch> jamespage: sorry, no, I was talking about the lxd provider, sorry, I may have misunderstood your comment.
[14:25] <jamespage> natefinch, I keep doing "juju add-unit --to lxc:1"
[14:25] <jamespage> rather than lxd:1
[14:25]  * jamespage faceplants
[14:25] <natefinch> jamespage: oh, I see
[14:25] <natefinch> jamespage: heh yeah
[14:26] <dimitern> jamespage, sorry, was afk - did you managed to sort it out?
[14:31] <jamespage> dimitern, yeah
[14:37] <jamespage> dimitern, ok - so seeing some oddness with lxd containers
[14:37] <jamespage> specifically
[14:37] <jamespage> I've had a container come up without a default route
[14:37] <jamespage> and two subsequent ones come up without and interfaces...
[14:40] <mup> Bug #1559293 changed: show-controller fails <ci> <show-controller> <juju-ci-tools:Triaged> <juju-core:Invalid> <juju-core admin-controller-model:Invalid> <https://launchpad.net/bugs/1559293>
[14:40] <dimitern> jamespage, so we've seen issues like that and that's why we do ifup -a || true at the end of the runcmds generated for container userdata
[14:40] <dimitern> jamespage, so I suspect those containers with the issues will recover after cloud-init has completed?
[14:41] <jamespage> dimitern, it never completes afaict
[14:41] <jamespage> as it can't download juju tools...
[14:42] <dimitern> jamespage, is the container on trusty?
[14:42] <jamespage> dimitern, no its all on xenial
[14:43] <dimitern> jamespage, anything useful in /var/lib/lxd/ ? e.g. cloud-init-output.log?
[14:45] <dimitern> jamespage, I've seen an issue with the xenial image my vmaas had (apt-get update was failing with unsigned index or something like that), so I did update the images in my vmaas and retried - this time was ok
[14:45] <jamespage> dimitern, I'm not having trouble with physical xenial hosts - just the containers...
[14:48] <dimitern> jamespage, so the provisioning does not complete for any lxd containers?
[14:48] <jamespage> dimitern, it managed one but that was then missing a default route
[14:49] <jamespage> dimitern, then other ones did not have any configured network interfaces - and nothing in the lxd profile either - let me recheck that
[14:49] <dimitern> jamespage, if you can paste some logs from the host machine I'll have a look
[14:50] <Guest_98765> Allah is doing
[14:50] <jamespage> dimitern, http://paste.ubuntu.com/15463715/
[14:51] <Guest_98765> sun is not doing Allah is doing
[14:51] <Guest_98765> moon is not doing Allah is doing
[14:51] <jamespage> dimitern, http://paste.ubuntu.com/15463718/
[14:51] <Guest_98765> stars are not doing Allah is doing
[14:51] <jamespage> lxd profile for machine
[14:51] <Guest_98765> planets are not doing Allah is doing
[14:52] <Guest_98765> galaxies are not doing Allah is doing
[14:52] <Guest_98765> oceans are not doing Allah is doing
[14:52] <Guest_98765> mountains are not doing Allah is doing
[14:52] <Guest_98765> trees are not doing Allah is doing
[14:52] <Guest_98765> mom is not doing Allah is doing
[14:53] <Guest_98765> dad is not doing Allah is doing
[14:53] <Guest_98765> boss is not doing Allah is doing
[14:53] <Guest_98765> job is not doing Allah is doing
[14:53] <Guest_98765> dollar is not doing Allah is doing
[14:53] <Guest_98765> degree is not doing Allah is doing
[14:53] <Guest_98765> medicine is not doing Allah is doing
[14:54] <Guest_98765> customers are not doing Allah is doing
[14:54] <dimitern> jamespage, ok, that was useful - it fails to store br-eth1.2667 for machine-2  :(
[14:54] <dimitern> jamespage, can you also paste the log of machine-0 please ?
[14:54] <Guest_98765> you can not get a job without the permission of allah
[14:54] <jamespage> dimitern, sure one sec
[14:54] <Guest_98765> you can not get married without the permission of allah
[14:55] <Guest_98765> nobody can get angry at you without the permission of allah
[14:55] <Guest_98765> light is not doing Allah is doing
[14:55] <dimitern> jamespage, also a paste of "ifconfig -a" on machine-2 will hopefully explain why br-eth1.2667 was not added
[14:55] <katco> natefinch: so you're working on the rest of that bug now... eta?
[14:55] <Guest_98765> fan is not doing Allah is doing
[14:55] <Guest_98765> businessess are not doing Allah is doing
[14:55] <Guest_98765> america is not doing Allah is doing
[14:56] <Guest_98765> fire can not burn without the permission of allah
[14:56] <natefinch> katco: this afternoon.  Mostly propagated all the changes needed, just need to throw in some more tests
[14:56] <Guest_98765> knife can not cut without the permission of allah
[14:56] <katco> natefinch: awesome, ty.
[14:56] <Guest_98765> rulers are not doing Allah is doing
[14:57] <Guest_98765> governments are not doing Allah is doing
[14:57] <Guest_98765> sleep is not doing Allah is doing
[14:57] <Guest_98765> hunger is not doing Allah is doing
[14:57] <Guest_98765> food does not take away the hunger Allah takes away the hunger
[14:58] <Guest_98765> water does not take away the thirst Allah takes away the thirst
[14:58] <Guest_98765> seeing is not doing Allah is doing
[14:58] <Guest_98765> hearing is not doing Allah is doing
[14:58] <Guest_98765> seasons are not doing Allah is doing
[14:58] <Guest_98765> weather is not doing Allah is doing
[14:59] <Guest_98765> humans are not doing Allah is doing
[14:59] <Guest_98765> animals are not doing Allah is doing
[14:59] <rick_h_> hmm, no one has ops here eh?
[14:59] <Guest_98765> the best amongst you are those who learn and teach quran
[14:59] <katco> rick_h_: it's never come up
[15:00] <natefinch> heh
[15:00] <rick_h_> katco: yea, reaching out to IS on how to fix it, what practice we have there
[15:00] <natefinch> I just ignored the guy
[15:00] <Guest_98765> one letter read from book of Allah amounts to one good deed and Allah multiplies one good deed ten times
[15:00] <katco> same
[15:00] <natefinch> but it would be nice to be able to punt people so we don't all have to do that
[15:01] <Guest_98765> hearts get rusted as does iron with water to remove rust from heart recitation of Quran and rememberance of death
[15:01] <Guest_98765> heart is likened to a mirror
[15:01] <Guest_98765> when a person commits one sin a black dot sustains the heart
[15:02] <TheMue> It's no guy, it's just a bot.
[15:03] <jamespage> dimitern, http://paste.ubuntu.com/15463811/
[15:03] <jamespage> dimitern, and http://paste.ubuntu.com/15463817/
[15:08] <dimitern> jamespage, thanks, unfortunately the logging level is not high enough to understand the problem - can you please try this:
[15:09] <dimitern> jamespage, first run $ juju set-model-config logging-config='<root>=TRACE'
[15:09] <dimitern> jamespage, and then bounce all jujud processes on machine-0, and paste the log again?
[15:10] <mup> Bug #1560061 opened: Eth0 device type determined to be "" <ci> <deploy> <juju-core:Incomplete> <juju-core maas-spaces-multi-nic-containers-with-master:Triaged> <https://launchpad.net/bugs/1560061>
[15:13] <katco> ericsnow: natefinch: btw, https://github.com/juju/juju/pull/4805 very good work guys. you should be super proud :)
[15:14] <ericsnow> katco, natefinch: +1
[15:21] <natefinch> my baby's all grown! *sniff*
[15:22] <katco> ericsnow: natefinch: finishing up the tests for the charm list-resources and then we're just doing bug fixes!
[15:23] <dimitern> jamespage, any luck?
[15:25] <katco> cherylj: speaking of which, tyvm for landing that
[15:26] <ericsnow> cherylj: yeah, thanks!
[15:26] <cherylj> katco, ericsnow my pleasure!
[15:26] <natefinch> cherylj: ditto! :)
[15:27] <natefinch> katco: reading the card I'm working on... it seems like the scope is a little vague.  "add channels wherever we use charm.URL"  I had only been adding channels to the calls required for list-resources.  I can add it elsewhere as well, but it's the sort of change that spiders out to a lot of code.
[15:27] <cherylj> I wanted to get it in there while there were no conflicts :)
[15:27] <natefinch> good thinking
[15:27] <katco> cherylj: hehe
[15:28] <katco> natefinch: does the stand-alone charm command support formatting flags?
[15:29] <natefinch> katco: looks like it, yes
[15:29] <natefinch> katco: looks like they use the formatter stuff just like juju uses
[15:31] <ericsnow> natefinch: really all that matters for channels is the code that interacts with the charm store (relative to resources)
[15:32] <ericsnow> natefinch: so the touches to that code will bleed through the API too
[15:32] <natefinch> ericsnow: yeah
[15:32] <natefinch> ericsnow: and stuff like add pending resources
[15:32] <ericsnow> the only other bit is the updates poller, which we still haven't sorted out
[15:33] <ericsnow> natefinch: sorry the card wasn't more clear
[15:37] <natefinch> ericsnow: right, so I have changes to use a charmstore.Charm type (url + channel) propagated through a lot of the code here: https://github.com/juju/juju/pull/4790/files
[15:37] <ericsnow> natefinch: I'll take a look
[15:38] <natefinch> of course, maybe we should just be using the channel value on charm.Url :/
[15:38] <natefinch> rogpeppe: charm.URL has a Channel field.. should we just use that for tracking the channel a URL is assigned to?
[15:38] <rogpeppe> natefinch: no, you should never use it
[15:39] <rogpeppe> natefinch: it's going to be deleted
[15:39] <ericsnow> rogpeppe: I had a hunch :)
[15:39] <natefinch> rogpeppe: well, so, Eric and I were lamenting that we have to change the signature of 1000 methods that used to take charm.URL to now take a URL + channel... why would we not just use the channel field on URL?
[15:40] <rogpeppe> natefinch: you only need to change that for methods that can take an unresolved url
[15:40] <natefinch> rogpeppe: yes, but it propagates out through the code more than you might think
[15:41] <rogpeppe> natefinch: for example?
[15:42] <rogpeppe> natefinch: this is in cmd/juju/service?
[15:43] <natefinch> rogpeppe: everywhere we use charmstore.Charm here (and some API methods I havent' fixed yet, but that's not going to be affected by changing charm.URL): https://github.com/juju/juju/compare/feature-resources...natefinch:list-resources-channels?expand=1
[15:44] <natefinch> rogpeppe: basically any time we have a URL that needs to be passed to the charmstore, we need the channel as well
[15:44] <jamespage> dimitern, sorry been otp
[15:44] <rogpeppe> natefinch: any time you have an unresolved URL, right?
[15:44] <ericsnow> rogpeppe: my "unresolved url" you mean those without a revision (e.g. revision -1)?
[15:44] <dimitern> jamespage, np
[15:45] <natefinch> rogpeppe: we need it even for specifically revisioned urls, because different channels can have different resources associated with the same revision of the charm
[15:45] <rogpeppe> ericsnow: yes
[15:45] <jamespage> dimitern, http://paste.ubuntu.com/15464291/
[15:46] <ericsnow> rogpeppe: I was under the impression that a "resolved" url may still be available in different channels
[15:46] <rogpeppe> natefinch: oh really? oh no.
[15:46] <natefinch> rogpeppe: and we'd need to store the channel for a service, so we know which channel to look for updates to the charm
[15:46] <ericsnow> (aside from "unpublished")
[15:46] <rogpeppe> this model is totally broken
[15:46] <natefinch> rick_h_: ^
[15:47] <dimitern> jamespage, cheers, looking
[15:47]  * rick_h_ tries to parse the traceback
[15:47] <natefinch> rick_h_: rogpeppe is surprised that the same rev of a charm can have different resources in different channels
[15:47] <rick_h_> natefinch: ugh
[15:48] <natefinch> rogpeppe: you can publish mysql-3 with resource-1 to dev and with resource-2 to stable, in theory
[15:49] <rogpeppe> natefinch: that goes against the whole notion of dev vs stable AFAICS
[15:51] <natefinch> rogpeppe: well, think about it.. .you publish mysql-3 & resource-1 to stable... then you want to update the resource, so you publish mysql-3 & resource-2 to dev for CI to test....
[15:51] <rick_h_> rogpeppe: dev vs stable is just a tag on a revision
[15:51] <rick_h_> rogpeppe: every charm revision can have the latest blessed set of resources/charm.
[15:52] <rick_h_> rogpeppe: the whole point of resources is you update them, and get a new stable set, without needing to update the charm revision
[15:52] <rogpeppe> rick_h_: and if an old revision doesn't work with one of the newly published resources?
[15:53] <natefinch> rogpeppe: resources are keyed off channel + charm-rev
[15:53] <rick_h_> rogpeppe: older revision of the charm?
[15:53] <rick_h_> rogpeppe: publishing will require the resource revisions
[15:54] <rick_h_> rogpeppe: so updating resources requires a new publish with the previous charm revision + the new resource revisions
[15:54] <rick_h_> rogpeppe: it's a forward rolling set, if the older revision doesn't work, it's ok because it was published with a different revisioned resource that at one time did work
[15:55] <rogpeppe> rick_h_: i am still deeply concerned about these semantics
[15:55] <rick_h_> rogpeppe: then let's chat about them please because they're getting delivered and quickly as we get the feature out the door
[15:56] <rogpeppe> rick_h_: i would be very happy to have a chat about them
[15:56] <rick_h_> natefinch: are you free in 20?
[15:56] <rick_h_> natefinch: will invite you into the chat I've got with the ui team then plkease
[15:56] <natefinch> rick_h_: I can be. yes
[15:56] <ericsnow> katco: ^^^
[15:57] <dimitern> jamespage, can you also paste the /e/n/i on machine-0 ?
[15:57] <katco> rick_h_: yeah toss me an invite as well if you don't mind
[15:57] <rick_h_> katco: rgr
[15:57] <katco> rick_h_: ta
[15:57] <jamespage> dimitern, erm 'destroy-controller' just executed - have to free up the env for my eod
[15:57] <ericsnow> rick_h_: me too :)
[15:57] <rick_h_> ericsnow: :)
[15:58] <dimitern> jamespage, ah, ok then
[15:58] <dimitern> jamespage, we something's odd about the created bridges there - br-eth1 does not seem to appear, and that's causing the issues
[15:58] <dimitern> s/we/well/
[16:00] <redir> morning katco, cherylj
[16:00] <cherylj> hey there redir!  Welcome aboard :)
[16:00] <redir> thanks
[16:01] <cherylj> redir: how are you finding your first day?
[16:01] <rick_h_> redir: hey, you're not started yet have you? I thought it was april?
[16:01] <redir> first order of business is to fill out the new starter stuff
[16:01] <cherylj> fun stuff
[16:01] <katco> redir: hey there!
[16:01] <redir> rick_h_: it was. but things went much more smoothly than expected
[16:01] <rick_h_> redir: awesome to hear, welcome back to the party
[16:01] <redir> thanks!
[16:02] <katco> ericsnow: natefinch: perrito666: this is a new member of tanazanite, Reed Simpson, aka redir
[16:02] <ericsnow> redir: welcome!
[16:02] <redir> cherylj: so far, 2 minutes in it is awesome:)
[16:02] <katco> :)
[16:03] <redir> thanks, ericsnow:)
[16:04] <katco> redir: be sure to reach out if you need any help with the new starter task
[16:04] <redir> katco: will do
[16:05] <katco> ericsnow: natefinch: perrito666: wow, i misremembered his last name. what a welcome :( this is Reed O'Brien
[16:05] <alexisb> redir, welcome!
[16:06] <redir> no worries, I always wanted to be a famous hockey player
[16:06] <katco> :)
[16:06] <alexisb> :)
[16:06] <redir> thanks alexisb, everyone:)
[16:10] <lazyPower> o/ redir
[16:10] <lazyPower> welcome aboard
[16:11] <redir> thanks lazyPower
[16:11] <katco> redir: lazyPower is on our ecosystems team. they do a lot of charming and community outreach. he's a great person to know and generally awesome
[16:11] <lazyPower> woo
[16:11] <lazyPower> i dont know that i can live up to that description, but hey o/ :D
[16:12] <lazyPower> have a charm question? i'll help ya whip it into shape or get you in touch with the ppl that can make it happen
[16:12]  * redir gets notepad
[16:12] <lazyPower> katco is elnode finished? :D
[16:13] <katco> lazyPower: it is not... last problem i ran into was emacs specific though. getting emacs to start with no stdin or something
[16:14] <lazyPower> next sprint we should make that a bounty and have a hack session on it
[16:15] <redir> how many teams are there?
[16:15] <redir> quick what are they?
[16:15] <lazyPower> tanzanite, sapphire, moonstone, onyx and uhh
[16:15] <katco> lazyPower: bzzzzz! incorrect
[16:15] <rick_h_> someone doesn't read the juju mailing list :P
[16:15] <katco> lazyPower: redir: there are 2: tanzanite (your team) and onyx
[16:16] <lazyPower> oh right
[16:16] <rick_h_> :)
[16:16] <lazyPower> the great restructuring of the minerals
[16:16] <redir> diamonds await
[16:16] <lazyPower> welp nothing to do here
[16:16]  * lazyPower jetpacks away
[16:17] <redir> so 2 teams: black and blue
[16:17] <natefinch> welcome redir!
[16:17] <redir> :)
[16:17] <redir> thanks natefinch
[16:17] <redir> which color is ecosystems?
[16:19] <katco> redir: that's an entirely different macro-team
[16:19] <katco> redir: tanzanite and onyx are sub-teams of juju-core
[16:19] <redir> is there a map?
[16:19] <redir> :)
[16:20] <rick_h_> only in our heads :)
[16:20] <natefinch> there used to be moonstone and sapphire, but they've been merged into tanzanite and onyx
[16:20] <mgz> I think eco uses colourless mana
[16:20] <katco> mgz: +1
[16:20] <redir> I see
[16:21]  * redir imagines ecosystems to be earth, wind, and fire.
[16:21] <natefinch> redir: mostly fire :)
[16:22]  * natefinch doesn't even know what that means.
[16:22]  * redir doesn't either but they are colourless
[16:23] <hatch> wb redir :D
[16:23] <redir> thanks, hatch
[16:28] <rick_h_> natefinch: ericsnow katco and optionally redir please join https://plus.google.com/hangouts/_/canonical.com/ui-daily?authuser=1
[16:28] <rick_h_> updating authuser as required
[16:34] <mup> Bug #1559844 changed: InvalidVolumme.NotFound error destroying aws environment <juju-core:Triaged> <https://launchpad.net/bugs/1559844>
[16:34] <mup> Bug #1560107 opened: juju client doesn't pass version and other useful metadata to api calls <juju-core:New> <https://launchpad.net/bugs/1560107>
[16:37] <mup> Bug #1542206 opened: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[16:42] <mgz> has some one added redir to github/lp grouos yet?
[16:43] <alexisb> mgz, probably not yet, there will be some delay in official registration stuff for redir, given his start date got bumped up
[16:44] <mgz> alexisb: I was just doing it for niedbalski and wondered if I could save effort :)
[16:44] <mgz> redir: what's your github username?
[16:46] <cherylj> hey redir, I'm working on getting you a room for the QA sprint next week.  Would you want to attend all 5 days?  (I personally won't fly in until Monday evening)
[16:52] <redir> mgz reedobrien
[16:52] <redir> cherylj: whatever you want me there for
[16:53] <redir> I can do all five days or partial if you prefer
[16:54] <mgz> redir: github has sent you an email, accept that, then go to github.com/orgs/juju/people and set your membership to public
[16:54] <redir> I am trying to reset my lp account. I have 2FA setup on it, but it doesn't like my 2FA codes
[16:54] <redir> any way to get someone to clear that?
[16:55] <redir> mgz: done
[16:56] <katco> ericsnow: natefinch: https://github.com/juju/charmstore-client/pull/6
[16:57] <ericsnow> katco: k
[16:57] <katco> ericsnow: natefinch: note that i've had to subvert the full-stack tests since the charmstore doesn't yet support resources
[16:58] <mgz> redir: did you do the reset sequence?
[16:58]  * katco heats up some lunch
[16:58] <mup> Bug #1542206 changed: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[16:58] <mgz> redir: if you tried that and it didn't work, er... I always bugged selene or someone, I think the right channel is...
[16:59] <mgz> redir: #canonical-support on the canonical network
[17:01] <redir> mgz: I tried to resync
[17:01] <redir> mgz: I don't see a way to reset the sequence
[17:01] <redir> mgz: not on the canonical network yet
[17:01] <mgz> alexisb: bug 1542206
[17:01] <mup> Bug #1542206: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[17:02] <redir> I'll try a little more then bail until I have access there
[17:02] <alexisb> mgz, looking
[17:04] <mup> Bug #1542206 opened: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[17:10] <ericsnow> katco: PR reviewed (mostly LGTM)
[17:14] <natefinch> katco, ericsnow: well, I was reviewing the PR until.... No server is currently available to service your request.
[17:15] <katco> natefinch: getting that too :(
[17:15] <natefinch> you know it's bad when you can't even get to the status page
[17:15] <katco> natefinch: status.github.com is even down
[17:15] <natefinch> katco: heh
[17:16] <natefinch> katco: http://i.cubeupload.com/D6bRPx.png
[17:17] <redir> buh
[17:18] <katco> natefinch: status seems to be up. looking at several graphs with a shelf in the last minute or so :p
[17:19] <natefinch> oh yeah, so it is
[17:19]  * natefinch puts away his sword.
[17:19] <cherylj> natefinch: back in my day, that used to say "Compiling!"
[17:19] <cherylj> ;)
[17:20] <cherylj> and when I worked in AIX, it was a legitimate excuse
[17:20] <natefinch> cherylj: for Juju it should say "running unit tests"
[17:20] <cherylj> took over an hour to build a kernel on our POS machines
[17:20] <cherylj> natefinch: ha, no kidding
[17:20] <katco> ericsnow: natefinch: fyi, i copy/pasted the help text from core's help text
[17:21] <natefinch> katco: hmm... I wonder if our help text is wrong, too, then
[17:21] <redir> cherylj: point of sale machines? :)
[17:22] <cherylj> redir: no, no IBM sold that off long ago
[17:22] <cherylj> ;)
[17:22] <cherylj> toshiba - those suckers
[17:22] <redir> so the other PoS machines
[17:22] <cherylj> redir: so, should I book your room for a checkin  Sunday, checkout Friday?
[17:23] <redir> cherylj: sounds perfect
[17:23] <redir> thanks
[17:23] <cherylj> redir: kk, I'll submit a request to the sprint organizer
[17:23] <rick_h_> redir: ok, does your login work?
[17:24] <alexisb> dimitern, ping
[17:24] <dimitern> alexisb, pong
[17:24] <alexisb> heya dimitern happy monday :)
[17:25] <alexisb> on bug 1542206, cheryl's last comment...
[17:25] <mup> Bug #1542206: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[17:25] <alexisb> it looks like juju is failing the bootstrap
[17:25] <alexisb> could that potentially be a bug in the spaces work for providers that dont currently support spaces?
[17:25] <dimitern> alexisb, :)
[17:25] <redir> rick_h_: yes!
[17:26] <cherylj> alexisb, dimitern : in all fairness, it could also be completely unrelated to spaces :)
[17:26] <cherylj> and that error is a red herring
[17:26] <dimitern> alexisb, I suspect that's an issue with joyent
[17:26] <alexisb> dimitern, ok, can we please work with cheryl to dig a bit
[17:26] <dimitern> alexisb, as there's no other issue recently related to that on any other cloud
[17:26] <alexisb> it is important to get beta3 out this week
[17:26] <dimitern> cherylj, alexisb, sure
[17:28] <alexisb> thanks dimiter
[17:28] <tvansteenburgh> hey guys, can the value for 'series' in metadata.yaml be a string, or must it be a list?
[17:28] <cherylj> oh hell.  mgz I see the model migration test failed in a different spot that passed in the previous run
[17:29] <mgz> cherylj: hm, but still a 20m timeout
[17:29] <cherylj> yes
[17:30] <mgz> cherylj: it's the how-good-are-you-at-reading-deadlock-gopanics test!
[17:30] <mgz> is the the same one, is it a different one? :)
[17:31] <natefinch> tvansteenburgh: always a list I believe
[17:31] <tvansteenburgh> natefinch: ta
[17:32] <mgz> cherylj: well, that sucks
[17:33] <cherylj> mgz: yeah.  They're in completely separate packages
[17:33] <mgz> latest one is useless, it's in the parent process
[17:33] <mgz> so, no clue to what caused the actual test binary to fail
[17:33] <cherylj> yeah
[17:33] <mgz> (fail to exit)
[17:36] <dimitern> mgz, can you get the cloud-init-output.log and machine-0.log of a joyent bootstrap instance that failed?
[17:36] <dimitern> mgz, with --keep-broken I guess..
[17:37] <mgz> dimitern: yeah, with the issue it's intermittent
[17:37] <dimitern> mgz, hmm I'm now beginning to suspect that was caused due to the MADE-state-workers changes
[17:42] <cherylj> oh boy
[17:42] <cherylj> mgz, dimitern I think it's related to the same change that broke restore
[17:43] <cherylj> https://github.com/juju/juju/commit/104e75494e9fc97cb2a0084b4384936abcee9622
[17:44] <dimitern> cherylj, uh oh that definitely looks promising as a cause
[17:45] <mgz> ...yup, that seems likely
[17:46] <cherylj> so, we can revert just the joyent part of that change
[17:46] <cherylj> or we can figure out why sometimes the filter doesn't work in joyent
[17:48] <dimitern> cherylj, it looks like one attempt passed ok though: http://reports.vapour.ws/releases/3791/job/joyent-deploy-trusty-amd64/attempt/1929
[17:48] <mgz> dimitern: it is intermittent
[17:48] <dimitern> an that's without a bundle - just deploy
[17:49] <cherylj> dimitern: right, I suspect that there's some state where if we try to get the joyent instances that match our filter, we don't get a complete list
[17:49] <mgz> so likely an ordering issue or similar in the bootstrap process
[17:50] <dimitern> ah, I see
[17:50] <mgz> did the machine we just created appear in our list run after or something
[17:50] <mgz> sometimes yeay sometimes ney
[17:59] <natefinch> rogpeppe: so... about that Channel field on charm.URL.....
[17:59] <rogpeppe> natefinch: make a new type
[17:59] <cherylj> mgz ... so revert the joyent part?
[18:00] <ericsnow> rogpeppe: could we include the charm store macaroon on that type?  It would be optional.
[18:00] <natefinch> rogpeppe: Why not use the field?
[18:00] <rogpeppe> natefinch: because it's not part of the URL
[18:00] <rogpeppe> natefinch: it's very wrong to use it. please don't.
[18:02] <natefinch> rogpeppe: it not being part of the URL makes sense.  I guess this is a consequence of the URL no longer being a sufficient unique identifier
[18:02] <rogpeppe> natefinch: yes that's right
[18:02] <mgz> cherylj: I would be tempted to for beta3, but this probably needs some more serious bug fixing, admin-controller likely depends on storage being gone?
[18:02] <rogpeppe> natefinch: that's part of the reasons for my rant earlier
[18:02] <natefinch> rogpeppe: we were headed down that road already, I just wanted to make sure there wasn't a shortcut
[18:02] <natefinch> rogpeppe: yeah, I totally understand.
[18:02] <cherylj> mgz: we haven't completely removed storage - maas still uses it
[18:03] <rogpeppe> natefinch: BTW I don't think that the channel is sufficient either
[18:03] <rogpeppe> natefinch: you probably want to pass around the full tuple
[18:03] <rogpeppe> natefinch: because a channel + a URL doesn't uniquely identify things
[18:03] <ericsnow> rogpeppe: what about the charm store macaroon on that new type?
[18:04] <rogpeppe> ericsnow: i guess it depends what you call the type
[18:04] <ericsnow> rogpeppe: the charm ID and the macaroon are pretty tightly coupled on the core side
[18:04] <ericsnow> rogpeppe: maybe it should just be a core type
[18:06] <natefinch> rogpeppe: I've made a github.com/juju/juju/charmstore.Charm type that contains the URL and the channel.  Probably adding the macaroon is a good idea.  I'm less certain about the resources.. channel+URL is unique-enough to get the expected resources (whether or not store resources are overridden is stored elsewhere)
[18:06] <rogpeppe> natefinch: i don't think the macaroon should be there really.
[18:07] <redir> rogpeppe!
[18:07] <rogpeppe> redir: yo!
[18:07] <rogpeppe> redir: you made it back!
[18:07] <rogpeppe> redir: welcome again :)
[18:07] <rogpeppe> natefinch: what are you going to use it for?
[18:08] <mgz> cherylj: good/bad news on ppc64 failure... just more timing prone issues
[18:08] <natefinch> rogpeppe: authenticating with the charmstore.  It probably doesn't need to be on the type, since it's not really part of the identity of the charm
[18:08] <rogpeppe> natefinch: channel+URL is not unique enough to get the expected resources over time
[18:08] <rogpeppe> natefinch: sorry, my question was really: what are you going to use the Charm type for?
[18:08] <redir> thanks rogpeppe
[18:09] <cherylj> mgz: we could also have this "ErrNotBootstrapped" error be one of the ones we retry in the bootstrap (just like upgrade in progress)
[18:09] <natefinch> rogpeppe: mainly right now for querying the charmstore for updates to the charm and/or associated resources
[18:09] <rogpeppe> natefinch: and please don't call it Charm - it's not a charm but some kind of identifier for a charm
[18:09] <ericsnow> rogpeppe: +1
[18:10] <rogpeppe> natefinch: do all resources get pulled into the environment when you deploy a charm?
[18:10] <rogpeppe> s/environment/model/
[18:10] <mup> Bug #1560152 opened: Local charm fails to deploy if it's too big <juju-core:New> <https://launchpad.net/bugs/1560152>
[18:10] <natefinch> rogpeppe: we grab all the metadata pre-emptively, grab bytes on-demand
[18:12] <rogpeppe> natefinch: so if you do juju deploy somecharm-5, then juju deploy somecharm-5 again and the default resources have changed, what will happen?
[18:12] <cherylj> perrito666: did you see bug 1557726?
[18:12] <mup> Bug #1557726: Restore fails on some openstacks <backup-restore> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1557726>
[18:12] <natefinch> rogpeppe: you get different resources and when you look at juju list-resources, you'll be told the first deploy has updates available for its resources
[18:13] <rogpeppe> natefinch: so the service holds the whole tuple of charm + resources?
[18:13] <natefinch> rogpeppe: basically the same as if you deploy wordpress twice, and the charm gets updated in between
[18:13] <natefinch> rogpeppe: correct
[18:13] <mup> Bug #1560152 changed: Local charm fails to deploy if it's too big <juju-core:New> <https://launchpad.net/bugs/1560152>
[18:15] <cherylj> hey mgz, I see that bug 1542206 was originally opened in Feb, which was before the change to joyent to use tags for controller instances
[18:15] <mup> Bug #1542206: space discovery still in progress <ci> <intermittent-failure> <joyent-provider> <precise> <regression> <juju-core:Triaged> <juju-core maas-spaces-multi-nic-containers:Invalid> <https://launchpad.net/bugs/1542206>
[18:15] <cherylj> mgz: the link to the failures in the bug seem to start on Mar 15
[18:16] <rogpeppe> natefinch: so i guess you could just call it CharmURLWithChannel.
[18:16] <rogpeppe> natefinch: type CharmURLWithChannel struct {charm.URL; Channel Channel}
[18:16] <mgz> cherylj: I think we have some wrong symptom association
[18:17] <cherylj> mgz: yeah, I was hoping that was the case
[18:17] <rogpeppe> natefinch: bulky but accurate
[18:17] <natefinch> rogpeppe: I'd rather call it something that is somewhat more extensible, on the thought that we may add/change data in it later (if we decide we want to give a single number to a charm + resource tuple, for example). CharmID I think would work.
[18:17] <mgz> cherylj: I rejigged the rule to make it more specific
[18:17] <mgz> cherylj: so, it should now match just on this issue
[18:18] <cherylj> mgz: k, thanks.  Should I update the bug to be more specific?  (That the bootstrap fails with "model is not bootstrapped")
[18:18] <mgz> cherylj: yeah, that's a good idea
[18:18] <rogpeppe> natefinch: yeah, that would probably be ok.
[18:23] <perrito666> cherylj: hi, just coming today, was a bit ill, I see it, I seem to have introduced that with k3 support
[18:23] <cherylj> perrito666: :(  hope you're feeling better
[18:23] <cherylj> sorry to make things worse with that bug :)
[18:23] <perrito666> cherylj: sort of, lots of white rice
[18:23] <perrito666> simple fix, actually
[18:24] <perrito666> openstack should actually be returning 300 and its returning 200
[18:25] <perrito666> cherylj: how blocking this is? (do you need me to fix it now or can I fix it tomorrow?)
[18:25] <mgz> perrito666: we are probably talking about two bugs
[18:25] <cherylj> perrito666: it is not blocking
[18:25] <mgz> one is rackspace/keystone 3 the other is joyent/storage
[18:26] <perrito666> mgz: the response pasted in the bug is about opesntack returning an unexpected http code
[18:26] <cherylj> perrito666: yeah, I'm talking about the keystone 3 bug
[18:26] <mgz> also *hugs*
[18:26] <perrito666> mgz: dont hug me or ill have to run to the bathroom
[18:28] <mup> Bug #1560152 opened: Local charm fails to deploy if it's too big <juju-core:New> <https://launchpad.net/bugs/1560152>
[18:32] <perrito666> mgz: the links on the bug, actually the first, havent checked the second, are 404ing
[18:37] <katco> fwereade_: hey, is it true you prefer exported test suites?
[18:39] <mgz> perrito666: from the log?
[18:40] <perrito666> http://juju-ci.vapour.ws:8080/view/Juju%20Revisions/job/functional-backup-restore-jujuqa-stack/
[18:40] <perrito666> mgz: that one
[18:40] <mgz> perrito666: are you logged in with developer credentials from lp:cloud-city?
[18:40] <mgz> ...not lp: but lp:etcetc/
[18:41] <katco> marcoceppi: hey, our final patch to the charm cmd is under review: https://github.com/juju/charmstore-client/pull/6
[18:41] <katco> marcoceppi: it will be landed soon
[18:42] <perrito666> mgz: meh I was unlogged
[18:42] <perrito666> mgz: I would have expected more smart from jenkins
[18:42] <mgz> it's Security
[18:42] <natefinch> katco: we should get rogpeppe to review that, though it's past EOD for him
[18:42] <rogpeppe> natefinch: i'm working late today
[18:42] <rogpeppe> natefinch: trying to get the deploy-with-channels stuff landed for you
[18:43] <mgz> everything has to be a huh-dunno not a no-way or you leak the super-sekret test names
[18:43] <natefinch> rogpeppe: I figured that would be a big change.  I have some code that may help / complicate it for you
[18:43] <marcoceppi> katco: thanks, we'll need this and the charm-help pull req to complete this (and the store updated)
[18:43] <rogpeppe> natefinch: it's only big because i couldn't resist cleaning things up a bit
[18:43] <perrito666> mgz: ok, give me some guidance here :p
[18:44] <katco> marcoceppi: what is required in the store?
[18:44] <perrito666> I see a build history whose newest build is feb 27
[18:44] <marcoceppi> katco: the latest charmstore deployed, it failed friday
[18:44] <katco> marcoceppi: ahh
[18:44] <rogpeppe> natefinch: i might have got the wrong end of the stick and not done nearly as much as i need to though
[18:44] <katco> marcoceppi: and what do you mean by a PR against charm-help?
[18:45] <mgz> perrito666: you don't have the creds to hand? lp:~juju-qa/+junk/cloud-city
[18:45] <marcoceppi> katco: https://github.com/juju/charmstore-client/pull/2
[18:45] <natefinch> rogpeppe: here's what I have, which has the CharmID type: https://github.com/juju/juju/pull/4790/files
[18:45] <katco> marcoceppi: ah ok. i thought you were asking me to do other things :)
[18:45] <natefinch> rogpeppe: I only did the part that was needed for juju charm list-resources, so there's a lot of other touches that would need to be made for general charm/channel usage, like deploy
[18:46] <natefinch> cherylj, katco: so if resources is merged, does that mean any new changes should go against master, or should we still be doing PRs versus the feature branch?
[18:47] <katco> natefinch: cherylj: good question. i think since they're bug fixes they can go against master?
[18:57] <rogpeppe> natefinch: ha, you've duplicated quite a bit of what i've already done today...
[18:57] <natefinch> rogpeppe: I was afraid of that
[18:58] <natefinch> rogpeppe: sorry I didn't ping you earlier today... I was still thinking of my change as being quite focused, though of course it spiraled out from the original intent of just supporting channels in one call.
[19:03]  * redir goes to grab lunch. Taking some of the getting started reading ianb send to me.
[19:03] <redir> bbiab
[19:03] <rogpeppe> natefinch: this what i'm on currently (just the dependency update) https://github.com/juju/juju/pull/4807/files
[19:04] <rogpeppe> natefinch: just running the tests (all passing so far, but probably 3 hours to go until they're finished...)
[19:04] <rogpeppe> natefinch: i've added some ericsnow TODOs :)
[19:05] <ericsnow> rogpeppe: :)
[19:09] <natefinch> rogpeppe: 3 hours until the work on the tests is finished, or 3 hours until the tests finish running?
[19:09] <rogpeppe> natefinch: the latter
[19:10] <rogpeppe> natefinch: probably a slight exaggeration
[19:10] <rogpeppe> natefinch: but my machine does seem to be slow today
[19:10] <natefinch> rogpeppe: ok, good. I was gonna say, maybe compiling on your smart phone is not the best idea
[19:11] <natefinch> s/compiling/running tests
[19:11] <rogpeppe> natefinch: i should get a sodding great water cooled monster to run the tests on
[19:12] <rogpeppe> natefinch: ... alternatively maybe i should rig up a charm for parallelising the test running on ec2
[19:12] <natefinch> rogpeppe: my 2.5 year old core i7 does ok... like 15-20 minutes
[19:13] <natefinch> rogpeppe: I do have a really fast (for 2.5 years ago) SSD which I think helps
[19:13] <rogpeppe> natefinch: mine's probably not that much longer than that tbh. it just feels like 3h.
[19:13] <natefinch> rogpeppe: certainly
[19:13] <cherylj> natefinch, katco, yes if you have new changes / bug fixes for resources, please make them against master
[19:13] <natefinch> rogpeppe: have you tried Russ' gt?
[19:13] <rogpeppe> natefinch: i have a lovely 1TB SSD sitting on the shelf waiting for the day that I can waste upgrading to it
[19:13] <rogpeppe> natefinch: it didn't work so well for me
[19:13] <natefinch> rogpeppe: it worked at times for me, but was definitely flaky at times, too
[19:14] <katco> cherylj: cool, ty. ericsnow: natefinch: bug fixes go against master now
[19:14] <katco> cherylj: should we delete the feature branch?
[19:14] <ericsnow> katco: k
[19:18] <rogpeppe> natefinch: i'd very much appreciate a review of the above PR BTW - what was originally reviewed was very different to what it is now
[19:18] <natefinch> rogpeppe: absolutely
[19:18] <rogpeppe> natefinch: thanks
[19:19] <rogpeppe> i'm sure the ec2 tests didn't used to take 2 1/2 minutes to run
[19:19] <rogpeppe> i wonder what's going on there
[19:27] <rogpeppe> ooh, we're on w
[19:28] <rogpeppe> natefinch: yay! tests passed.
[19:29] <rogpeppe> natefinch: did you wanna take a look before I push it?
[19:35] <natefinch> rogpeppe: I'm looking
[19:36] <redir> back
[19:39] <cherylj> thumper: http://reviews.vapour.ws/r/4267/
[19:40] <thumper> cherylj: not bad, +8,634 −146
[19:40] <thumper> smaller than I thought
[19:40] <cherylj> heh
[19:42] <natefinch> rogpeppe: lgtm... very nice to have all that bakery nonsense wrapped up in a reusable place
[19:42] <katco> cherylj: hey, do you know if we should delete our feature branch?
[19:42] <cherylj> katco: not required, but you can if you'd like
[19:43] <katco> ericsnow: natefinch: any objections?
[19:43] <cherylj> katco: I imagine we're going to do a bit of pruning after we ship 2.0.0
[19:43] <natefinch> katco: seems like a good idea so no one twiddles against it by accident
[19:43] <ericsnow> katco: sounds good
[19:43] <thumper> +1 to deleting the merged feature branch
[19:44] <katco> natefinch: also going to delete nate-minver
[19:44]  * cherylj is secretly paranoid that the merge didn't actually happen properly
[19:44] <katco> cherylj: looks like you can restore branches. plus i guarantee you we have copies floating around on people's local machines ;)
[19:44] <natefinch> katco: glad to have it done with. :)
[19:45] <cherylj> haha, ok thanks :)
[19:45] <katco> thumper: is there anything we can do to help out onyx?
[19:46] <thumper> yes
[19:46] <thumper> katco: do you have some time now?
[19:46] <katco> thumper: 15m
[19:46] <thumper> you can't do much in 15 minutes :)
[19:46] <thumper> I mean, does your team have spare capacity
[19:46] <katco> thumper: ericsnow has more time :) and i'll have time after
[19:46] <cherylj> har har
[19:47] <natefinch> thumper: lol, spare capacity
[19:47] <katco> thumper: er strike that. i won't have time after. ericsnow does though
[19:47] <thumper> katco: I think we need to think carefully about what we have committed to over the whole team
[19:47] <thumper> we have already said that model migration won't be fully functional
[19:47] <rogpeppe> natefinch: thanks
[19:47] <thumper> is there something else that we have fully committed to that needs work?
[19:48]  * katco scans feature list
[19:48] <natefinch> thumper: all the charmstore part of resources :/  I mean, we plan to do it, but it's not at all done yet.
[19:48] <thumper> katco: probably best to sync up with alexisb and wallyworld
[19:48] <katco> thumper: planned on doing so in this afternoon's release standup
[19:48] <thumper> natefinch: that would be a first focus then I guess
[19:48] <thumper> kk
[19:48] <katco> thumper: i was just referring to today's deadline
[19:49] <thumper> oh, just for today?
[19:49] <thumper> no
[19:49] <thumper> we're good
[19:49] <natefinch> sorry, I should butt out, katco has it all under control.
[19:49] <katco> thumper: yes if you were trying to push for something
[19:49]  * natefinch goes back to teh coding
[19:49] <thumper> we are... but nothing that more hands will help in the short timeframe
[19:49] <katco> thumper: ok, just thought we'd check :)
[19:49] <thumper> cheers
[19:55] <rogpeppe> aargh, i'd forgotten you can't reply to reviewboard comments directly in the summary section
[19:55] <katco> rogpeppe: you can i think
[19:56] <rogpeppe> katco: i always do "Add comment" (thinking it's gonna reply) and it opens a new issue instead.
[19:56] <katco> rogpeppe: yeah i think you have to click on the comment in the gutter, then there's like an "add reply" or something
[19:56] <rogpeppe> katco: i'll look harder next time
[19:57] <rogpeppe> ericsnow: i've made some replies to your review comments but they're all in the same place.
[19:57] <ericsnow> rogpeppe: k
[19:57] <rogpeppe> s/same place/wrong place/
[19:59] <rogpeppe> katco: i don't think you can click the comment in the gutter from the overview mode, unless i'm missing something
[20:00] <rogpeppe> ericsnow: are you ok with me landing it?
[20:00] <katco> rogpeppe: maybe i'm misinterpreting what overview mode is
[20:01] <rogpeppe> katco: the page you get by following the original review link
[20:01] <ericsnow> rogpeppe: yep
[20:01] <rogpeppe> katco: not the page with all the complete diffs on
[20:01] <rogpeppe> ericsnow: ta
[20:01] <natefinch> katco: I'm going to be a bit late on proposing my PR.  I spent a bunch of time doing code reviews and meetings etc.  But it should be done tonight.
[20:14] <mup> Bug #1560191 opened: kill-controller is hinky without a model-controller behind it <juju-core:New> <https://launchpad.net/bugs/1560191>
[20:14] <mup> Bug #1560192 opened: Restoring admin: model configuration has no admin-secret <backup-restore> <ci> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1560192>
[20:20] <mup> Bug #1560201 opened: The Client.WatchAll API command never responds when the model has no machines <juju-core:New> <https://launchpad.net/bugs/1560201>
[20:20] <mup> Bug #1560203 opened: stringForwarderSuite.TestRace sometimes fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1560203>
[20:22] <rogpeppe> ericsnow: while i'm looking at the code, can I ask you what the "Spec" in CharmstoreSpec stands for?
[20:23] <ericsnow> rogpeppe: specification
[20:23] <ericsnow> rogpeppe: really the for the client though :/
[20:23] <rogpeppe> ericsnow: ok. thats... not what i expected.
[20:24] <rogpeppe> ericsnow: i thought it might have been Specialization
[20:25] <thumper> davecheney: wondering about your take on this bug: https://github.com/lxc/lxd/issues/1781
[20:26] <thumper> davecheney: due to pathological juju bug, created a very long path
[20:29] <mup> Bug #1560201 changed: The Client.WatchAll API command never responds when the model has no machines <juju-core:New> <https://launchpad.net/bugs/1560201>
[20:29] <mup> Bug #1560203 changed: stringForwarderSuite.TestRace sometimes fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1560203>
[20:36] <cherylj> thumper, menn0 model-migration is merged!
[20:37] <thumper> \o/
[20:37]  * thumper does a little dance
[20:38]  * fwereade_ cheers
[20:38] <fwereade_> thumper, I'm in the hangout
[20:38] <alexisb> :)
[20:38] <thumper> ƪ(˘⌣˘)┐ ƪ(˘⌣˘)ʃ ┌(˘⌣˘)ʃ
[20:39] <cherylj> hey perrito666, looking back on bug 1536792
[20:39] <mup> Bug #1536792: Some providers release wrong resources when destroying hosted models <juju-core:In Progress> <https://launchpad.net/bugs/1536792>
[20:39] <cherylj> perrito666: why was joyent not fixed yet?
[20:40] <cherylj> perrito666: was it waiting for the change to use tags instead of storage?
[20:40] <natefinch> gah, people need to stop calling things resources when they're not *Resources* ... messes me up every time
[20:44] <mup> Bug #1560201 opened: The Client.WatchAll API command never responds when the model has no machines <juju-core:New> <https://launchpad.net/bugs/1560201>
[20:44] <mup> Bug #1560203 opened: stringForwarderSuite.TestRace sometimes fails <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1560203>
[20:48] <natefinch> man I hate external tests
[21:10] <menn0> cherylj, thumper : woot!
[21:11] <perrito666> cherylj: sorry I am back, I am not sure I know what you are talking about
[21:16] <perrito666> cherylj: oh, joyent was going to be done by an external
[21:16] <cherylj> hmm
[21:17] <perrito666> natefinch: you need to stop picking names extremely common in computers and repurposing them perhaps?
[21:20] <natefinch> perrito666: well, *someone* needs to stop picking those names... :)
[21:22] <redir> natefinch: perrito666 they need to be more resourceful
[21:27] <ericsnow> redir: I see what you did there <wink>
[21:28] <redir> ;)
[21:56] <davecheney> umm, ++ /var/lib/jenkins/juju-ci-tools/ec2-run-instance-get-id
[21:56] <davecheney> euca-run-instances: error (InstanceLimitExceeded): Your quota allows for 0 more running instance(s). You requested at least 1
[21:56] <davecheney> CI just told me to go rewrite it in erlang
[21:56] <mup> Bug #1559310 changed: bootstrap fails: "model is not bootstrapped" <bootstrap> <ci> <juju-core:Incomplete> <juju-core admin-controller-model:Triaged> <https://launchpad.net/bugs/1559310>
[21:57] <rogpeppe> ericsnow: ping
[21:57] <ericsnow> rogpeppe: hey
[21:58] <rogpeppe> ericsnow: so, when deploying with a channel, i can deploy the charm ok, but presumably we need some way to say what the channel was in the deploy API request, right? have you done that bit?
[21:58] <ericsnow> rogpeppe: we've done nothing like that
[21:59] <rogpeppe> ericsnow: ah, so your resources stuff is assuming that the channel is in the state, but so far there's nothing to put it there?
[22:00] <ericsnow> rogpeppe: I believe that natefinch is still working on the bit that passes the channel for the resource-related API call
[22:00] <rogpeppe> natefinch: ok
[22:00] <rogpeppe> ericsnow: ok
[22:03] <rogpeppe> natefinch: i'd be interested to hear your plans here
[22:03] <ericsnow> rogpeppe: I expect he'll be back later
[22:04] <rogpeppe> ericsnow: do you know what the status of making changes to the API currently are?
[22:04] <rogpeppe> ericsnow: am I allowed to add new API parameters to existing calls without creating a new version?
[22:05] <ericsnow> rogpeppe: not positive, but I believe so relative to the 2.0 release
[22:05]  * ericsnow checks docs
[22:10] <ericsnow> rogpeppe: best I've found: https://github.com/juju/juju/blob/master/doc/design/juju-api-implementation-guide.md#versioning
[22:22] <katco> cherylj: available for a call?
[22:35] <urulama> rogpeppe: need a channel as a parameter?
[22:37] <katco> rogpeppe: ah i see the scrollback now. natefinch is assuming the channel will be there and is assuming published for now. no plans to do anything more than consume what's stored
[22:53] <mup> Bug #1560237 opened: worker/peergrouper: intermittent data race <juju-core:New> <https://launchpad.net/bugs/1560237>
[23:00] <axw> wallyworld: my desktop has decided now would be a good time to start cutting out again
[23:00] <axw> so may be late to or drop out of standup
[23:00] <anastasiamac> axw: ack
[23:26] <rogpeppe> ericsnow, natefinch, katco: here's the PR (sketchy tests I'm afraid but I think worth it anyway) https://github.com/juju/juju/pull/4833
[23:28] <rogpeppe> axw: fancy a review? ^
[23:29] <axw> rogpeppe: in standup, a bit later sorry
[23:29] <rogpeppe> axw: np
[23:40] <rogpeppe> please, can someone review this branch? it's almost midnight here and I really need to get this landed. https://github.com/juju/juju/pull/4833
[23:40] <rogpeppe> ericsnow, natefinch, katco: ^
[23:40] <rogpeppe> wallyworld: ^
[23:40] <ericsnow> rogpeppe: looking
[23:41] <rogpeppe> ericsnow: thanks
[23:46] <rogpeppe> ericsnow: please don't wait until the end of the review if you have some comments, so i can get on with fixing things
[23:47] <ericsnow> rogpeppe: nothing so far
[23:47] <rogpeppe> ericsnow: cool
[23:47] <ericsnow> rogpeppe: just getting my bearing relative to some of the refactors you did (nice ones :)
[23:58] <rogpeppe> ericsnow: in 1m20s i'm gonna turn into a pumpkin
[23:58] <ericsnow> rogpeppe: LGTM
[23:58] <ericsnow> ha, what timing
[23:58] <rogpeppe> ericsnow: phew!
[23:59] <ericsnow> rogpeppe: thanks for the hard work on this
[23:59] <rogpeppe> ericsnow: saved from pumpkinhood
[23:59] <rogpeppe> ericsnow: np
[23:59] <ericsnow> rogpeppe: there are still a few things we have to sort out still