[03:27] <thumper> davecheney: ping
[04:27] <thumper> unping
[04:27]  * thumper wanders off for a bit
[08:50] <rogpeppe> wallyworld: ping
[08:55] <wallyworld> rogpeppe: hello
[08:55] <rogpeppe> wallyworld: i was just looking at the simplestreams stuff
[08:55] <rogpeppe> wallyworld: and realised that i didn't have the first idea about what it's about
[08:55] <wallyworld> me either :-)
[08:55] <rogpeppe> wallyworld: why "streams" ?
[08:56] <wallyworld> rogpeppe: i have no idea how the naming was done, i just inherirted the data format. there's a lp project at lp:simplestreams
[08:56] <wallyworld> this stuff was invented by scott moser
[08:56] <wallyworld> i just provided the go implementation to use it
[08:57] <rogpeppe> wallyworld: yeah, i've been looking at that and trying to work out the reasoning behind the abstractions
[08:57] <wallyworld> since that's what the image metadata is being done in moving forward
[08:57] <wallyworld> there was a big email thread on some list somewhere but i haven't seen it - not sure how far ago it was
[08:57] <rogpeppe> wallyworld: is there a good overview of simplestreams somewhere?
[08:58] <wallyworld> not that *I* know - I just looked at some readmes in the project
[08:58] <wallyworld> i got the lp:simplesytreams source code and poked around a bit
[08:58] <wallyworld> when i started this stuff, i hadn't even seen the project, so had to reverse engineer everything :-(
[08:58] <rogpeppe> wallyworld: what did you use as a reference for the data format?
[08:59] <rogpeppe> wallyworld: just the simplestreams source code?
[08:59] <wallyworld> the sample files :-(
[08:59] <rogpeppe> oh lawks
[08:59] <wallyworld> and then i read the source code
[08:59] <wallyworld> and the readmes and some gaps were filled in
[09:00] <wallyworld> and also, i was told via email a few extra tidbits
[09:00] <wallyworld> rogpeppe: not the best way to implement something is it :-(
[09:01] <rogpeppe> seems weird.
[09:01] <wallyworld> i'm happy though it works for ec2 and openstack (canonistack) data out of the box
[09:01] <rogpeppe> wallyworld: and as seems to be usual for something with "simple" in the protocol, it seems anything but :-)
[09:01] <wallyworld> lol
[09:01] <rogpeppe> s/protocol/name/
[09:01] <wallyworld> rogpeppe: some of the alias stuff was forced on scott by someone else
[09:02] <wallyworld> that adds to the complexity
[09:03] <wallyworld> rogpeppe: from mgz: https://lists.canonical.com/mailman/private/cloud/2013-March/004476.html
[09:03]  * wallyworld goes to read the spec of the thing he has just implemented
[09:03] <rogpeppe> wallyworld: i can't seem to authenticate to that archive
[09:04] <wallyworld> hmmm. you might need to be subscribed already to that mailing list
[09:04] <wallyworld> you can manage your subscriptions via launchpad
[09:04]  * wallyworld has to go to soccer
[09:05] <mgz> I was trying to not post links people can't read to public channel, but it doesn't matter much :)
[09:06] <mgz> it's not a launchpad list, you need to sign up via the we interface there
[09:06] <mgz> *web
[09:06] <rogpeppe> i guess i'll have to wait for someone to react to the subscription request
[09:08] <rogpeppe> wallyworld: i see stuff in the go package that doesn't seem to be mentioned in the simplestreams project. e.g. i can't find any occurrence of the string "csrn" (for the RegionAlias field). where's that stuff defined?
[09:09] <wallyworld> rogpeppe: i don't think crsn is defined as a supported attribute - it is merely a key into the alias map
[09:09] <wallyworld> it could be called foobar
[09:10] <wallyworld> but for our purposes, we can assume it's there
[09:10] <rogpeppe> wallyworld: and the code would still work if we renamed it to foobar?
[09:10] <wallyworld> no. but it's easier that trying to deal with totally generic interface{} types in Go
[09:11] <wallyworld> rogpeppe: the EC2 metadata is the only thing that uses that attribute afaik
[09:11] <wallyworld> and it will always be crsn (customer region short name)
[09:12] <rogpeppe> wallyworld: so where's it defined? what code has populated that attribute? it seems like it's part of the data format we're parsing.
[09:12] <wallyworld> rogpeppe: there's tools in lp:simplestreams (shell scripts and pythin modules) to generate the data i believe
[09:13] <wallyworld> rogpeppe: the only reason crsn is there (and the alias stuff) is that gustavo didn;t like the verbosity
[09:13] <wallyworld> so endpoint and region we pulled out of the ec2 image records
[09:13] <rogpeppe> wallyworld: i think i have a slight difficulty with simplestreams as a name for the go package, which sounds very generic, but actually we're interested in parsing something that was produced by simplestreams but is actually more (and less) than that
[09:14] <wallyworld> i have no attachment to the name
[09:14] <rogpeppe> wallyworld: cool
[09:14] <wallyworld> i just wanted something in it's own package that could read the image data we need to consume
[09:15] <rogpeppe> wallyworld: it's really "imagemetadata" or something not too far from that, i think
[09:15] <wallyworld> sounds good to me
[09:15] <rogpeppe> wallyworld: maybe just "images" :-
[09:15] <rogpeppe> )
[09:15] <wallyworld> that works also :-)
[09:15]  * wallyworld really has to run away now
[09:16] <rogpeppe> wallyworld: have fun!
[09:16] <wallyworld> will do. thanks for looking at the crap code i wrote
[09:50] <dimitern> fwereade: https://codereview.appspot.com/9084045/
[09:53] <fwereade> dimitern, cheers
[10:07] <fwereade> dimitern, did you have a change of heart re errRefresh? I thought we decided last night that we could actually eliminate it
[10:08] <fwereade> dimitern, by ignoring the initial value of the service's relation count
[10:08] <fwereade> dimitern, and just asserting that by the time the txn runs, it will have as many relations as we observed it to have when building the txn
[10:09] <dimitern> fwereade: I did remove s.Refresh(), but kept the error to signal the need to get a fresh service from state in the loop, where it should be i think
[10:10] <fwereade> dimitern, I don't actually think we need to refresh the service at all, because we don't need to look at RelationCount and we don't need a fresh service to get the current .Relations()
[10:11] <dimitern> fwereade: well, you're basically agreeing with rogpeppe about not using s.doc.RelationCount then?
[10:11] <fwereade> dimitern, I thought that not needing a frsh relationcount was the major epiphany last night, but it is possible that it was all in my head
[10:11] <fwereade> dimitern, we need to assert it, but we don't need to validate it when building the txn
[10:11] <rogpeppe> fwereade: +1
[10:12] <rogpeppe> fwereade: that's what i was trying to get at
[10:12] <fwereade> rogpeppe, dimitern: yeah, this stuff is tricky to communicate
[10:12] <dimitern> ok, i'll remove the refresh and keep the assert(RC, eq, len(relations))
[10:12] <rogpeppe> dimitern: sounds good
[10:13] <fwereade> dimitern, that's perfect
[10:14] <fwereade> dimitern, LGTM with comments/suggestions in the CL then :)
[10:14] <dimitern> fwereade: cheers
[11:53] <jamespage> hey - can anyone confirm whether bug 1175958 is also a problem from juju-core?
[11:53] <_mup_> Bug #1175958: New peer relations not created when upgrading charms <amd64> <apport-bug> <raring> <juju:New> <juju (Ubuntu):New> <https://launchpad.net/bugs/1175958>
[11:54] <jamespage> I've not got my maas/juju-core env quite right yet so can't confirm quickly
[12:05] <dimitern> jamespage: i fixed this in juju-core
[12:06] <dimitern> jamespage: it's in the 1.10 release
[12:11] <jamespage> dimitern, +1 - great
[13:46] <mgz> no one has been poking me for reviews today...
[13:49] <dimitern> mgz: it's a slow day it seems
[13:49] <mgz> everyone's packing :)
[13:49] <mgz> packing BYTES
[13:50] <mgz> there are some existing reviews to go over, and my own bits to land
[13:50] <dimitern> yeah, i'll start packing soon as well
[13:53] <rogpeppe> mgz: it's not mine, but i've been reviewing this and i'd like to see your views on it: https://codereview.appspot.com/9138044/
[13:56] <mgz> yeah, need to go over that one
[14:04] <rogpeppe> mgz: there are some issues with the parsing, but i'm concerned whether it's exposing the right level of detail. i'm wonder if a higher level interface might work better.
[14:06] <rogpeppe> gah!
[14:07] <mgz> nogah
[14:07] <mgz> it will all be okay rog
[14:08] <rogpeppe> mgz: apparently the cable is "mostly" been fixed
[14:08] <rogpeppe> s/is/has/
[14:08] <mgz> ehehe
[14:09] <rogpeppe> *sigh*
[14:12] <rogpeppe> fwereade, dimitern, mramm: i think i'm going to give up
[14:13] <rogpeppe> fwereade, mramm: please let me know if there is anything i should know about
[14:13] <dimitern> rogpeppe: bad luck
[14:14] <fwereade> rogpeppe, I think the gist is "see you soon"
[14:14] <rogpeppe> fwereade: \o/
[14:46] <fwereade> rogpeppe, is there a pithy name for the "1-buffered chan for mutexed field access" pattern?
[14:47]  * rogpeppe thinks
[14:47] <rogpeppe> fwereade: not sure. "chan as resource holder" is about as good as i've got
[14:47] <rogpeppe> fwereade: what's context will the name be used in?
[14:52] <fwereade> rogpeppe, I'm just about to propose it
[14:58] <fwereade> rogpeppe, dimitern: opinions on https://codereview.appspot.com/9175043 much appreciated
[14:59] <dimitern> fwereade:  will look shortly
[14:59] <rogpeppe> fwereade: will have a look in a bit. i have to take my lunch break and eat food and acquire heavy sacks of compost.
[14:59] <fwereade> dimitern, rogpeppe: np
[15:00] <fwereade> mgz, if you're on reviews, https://codereview.appspot.com/9175043 might be interesting
[15:01] <mgz> ta
[15:06] <dimitern> fwereade: reviewed
[15:11] <fwereade> dimitern, cheers
[15:50] <hazmat> fwereade,  what's the status of --config support for deploy?
[15:50] <fwereade> hazmat, it's not complete but I don't anticipate problems finishing it off
[15:51] <fwereade> hazmat, but it was a bit messier than I hoped and it's taken a little while to massage into shape
[15:51] <hazmat> fwereade, cool.. its the last issue i think before people can start using core for their deployer stacks (ostack, etc)
[15:51] <hazmat> i'm holding off an announce of the new core compatible deployer till it lands
[15:52] <fwereade> hazmat, awesome -- I probably won't propose it today, but hassle me in person if I haven't done so on sunday ;p
[15:52] <hazmat> fwereade, thanks will do, and safe travels
[15:53] <fwereade> hazmat, cheers, and you
[15:53] <fwereade> hazmat, btw, re wedged unit status, can it be resolved by bouncing the unit agent?
[15:54] <hazmat> fwereade, i've had multiple wedged causes..
[15:54] <fwereade> hazmat, ah sorry, I meant the resolved/hook-error one
[15:57] <hazmat> fwereade, i'll check next time i run into it.. its the deployer running that helps me trigger it, but thats in holding pattern and basically done.  the other one looked like more of a state issue.. the status reported missing provider state for the machine.
[15:57] <hazmat> fwereade, i suspect that indeed a restart should fix the resolved wedge
[16:10] <fwereade> hazmat, the other one is interesting too, I made a note on the bug
[16:12] <fwereade> hazmat, finding out what actually happened to the instance is the issue there -- it *looks* like an environ issue not a state issue to me
[16:20] <hazmat> fwereade, yes.. but i think its juju modifying/terminating the instance. that one needs more analysis.
[16:21] <hazmat> fwereade, as afar getting foresenic evidence for this stuff, is there a good set of known things to capture?
[16:21] <hazmat> fwereade,  i was figuring i can grab the unified log and a mongodb dump which should cover everything afaics
[16:23] <fwereade> hazmat, that should cover it, I think
[17:15] <rogpeppe> fwereade: did you see my text around major-version upgrades yesterday?
[17:16] <fwereade> rogpeppe, I saw it go by and totally failed to do anything with it
[17:16] <fwereade> rogpeppe, sorry :(
[17:17] <rogpeppe> fwereade: that's fine. i'd appreciate your thoughts at some point though.
[17:20] <hazmat>  rogpeppe where
[17:21] <rogpeppe> hazmat: http://paste.ubuntu.com/5629750/
[17:21] <hazmat> rogpeppe, thanks
[17:22] <hazmat> rogpeppe, you might also want to account for local changes made to machines during major upgrades
[17:22] <rogpeppe> hazmat: what kind of thing are you thinking of?
[17:23] <hazmat> rogpeppe, i modeled as a separate job upgrade that the agent restarted itself (only that job) into upon seeing the major watch trigger, and could then do local changes after seeing the db upgrade complete.
[17:24] <rogpeppe> hazmat: that's a good point
[17:24] <hazmat> rogpeppe, ie. upgrade major.. barrier for agents into restart mode. db upgrade. local upgrade. restart
[17:25] <rogpeppe> hazmat: perhaps a similar thing should apply as at the server side. we could have a subcommand "upgradeclient" or something
[17:25] <hazmat> rogpeppe, its critical that agents signal into the barrier that their in restart mode, else state usage is uncertain to the db upgrader
[17:26] <rogpeppe> hazmat: yes, that's the intent
[17:26] <rogpeppe> hazmat: although i see i've managed to omit that detail
[17:28] <rogpeppe> hazmat: updated http://paste.ubuntu.com/5629770/
[17:28] <hazmat> rogpeppe, another item worth calling out is that the upgrade coordinator is happening server side, ie possible long run, don't depend on client staying connected
[17:29] <rogpeppe> hazmat: yes. that's kind of implicit, but probably worth mentioning.
[17:29] <rogpeppe> hazmat: all we need is some indicator from each client.
[17:29] <hazmat> rogpeppe, re api wait for reporting upgrade status. a minimal api impl for upgrade that just reports status sounds appropriate
[17:30] <hazmat> either status of agents into the barrier, or simple stage and status.
[17:30] <hazmat> its trickier.
[17:30] <rogpeppe> hazmat: that's not so easy though, as we need to upgrade all the API servers too
[17:30] <hazmat> rogpeppe, yeah.. i'm saying upgrade job can run a minimal api
[17:31] <hazmat> er.. api servers have a minimal upgrade api job
[17:31] <rogpeppe> hazmat: that might work actually - the upgrade job could publish its own address as the only API server address
[17:32]  * hazmat bows out to a meeting
[17:32] <rogpeppe> hazmat: but since the clients are all going to have to reconnect anyway, i'm not sure that emulating a subset of the API is necessary
[17:32] <rogpeppe> hazmat: see ya
[17:46] <rogpeppe> right, i'm off
[17:46] <rogpeppe> see y'all in Oakie!
[18:08] <mgz> so, their demo just demostrated one bug, then that terminating a machine juju-core doesn't recover, unlike juju which starts a new machine
[18:36] <hazmat> mgz, which demo?
[22:41] <TheChistoso|2> hi guys -- sorry to bother you here, but i need help working around https://bugs.launchpad.net/juju-core/+bug/1172973
[22:41] <_mup_> Bug #1172973: sync-tools requires aws credentials be set in the (shell) environment <juju-core:Confirmed> <https://launchpad.net/bugs/1172973>