=== wedgwood is now known as wedgwood_away [03:27] davecheney: ping [04:27] unping [04:27] * thumper wanders off for a bit === tasdomas_afk is now known as tasdomas [08:50] wallyworld: ping [08:55] rogpeppe: hello [08:55] wallyworld: i was just looking at the simplestreams stuff [08:55] wallyworld: and realised that i didn't have the first idea about what it's about [08:55] me either :-) [08:55] wallyworld: why "streams" ? [08:56] 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] this stuff was invented by scott moser [08:56] i just provided the go implementation to use it [08:57] wallyworld: yeah, i've been looking at that and trying to work out the reasoning behind the abstractions [08:57] since that's what the image metadata is being done in moving forward [08:57] 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] wallyworld: is there a good overview of simplestreams somewhere? [08:58] not that *I* know - I just looked at some readmes in the project [08:58] i got the lp:simplesytreams source code and poked around a bit [08:58] when i started this stuff, i hadn't even seen the project, so had to reverse engineer everything :-( [08:58] wallyworld: what did you use as a reference for the data format? [08:59] wallyworld: just the simplestreams source code? [08:59] the sample files :-( [08:59] oh lawks [08:59] and then i read the source code [08:59] and the readmes and some gaps were filled in [09:00] and also, i was told via email a few extra tidbits [09:00] rogpeppe: not the best way to implement something is it :-( [09:01] seems weird. [09:01] i'm happy though it works for ec2 and openstack (canonistack) data out of the box [09:01] wallyworld: and as seems to be usual for something with "simple" in the protocol, it seems anything but :-) [09:01] lol [09:01] s/protocol/name/ [09:01] rogpeppe: some of the alias stuff was forced on scott by someone else [09:02] that adds to the complexity [09:03] 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] wallyworld: i can't seem to authenticate to that archive [09:04] hmmm. you might need to be subscribed already to that mailing list [09:04] you can manage your subscriptions via launchpad [09:04] * wallyworld has to go to soccer [09:05] I was trying to not post links people can't read to public channel, but it doesn't matter much :) [09:06] it's not a launchpad list, you need to sign up via the we interface there [09:06] *web [09:06] i guess i'll have to wait for someone to react to the subscription request [09:08] 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] rogpeppe: i don't think crsn is defined as a supported attribute - it is merely a key into the alias map [09:09] it could be called foobar [09:10] but for our purposes, we can assume it's there [09:10] wallyworld: and the code would still work if we renamed it to foobar? [09:10] no. but it's easier that trying to deal with totally generic interface{} types in Go [09:11] rogpeppe: the EC2 metadata is the only thing that uses that attribute afaik [09:11] and it will always be crsn (customer region short name) [09:12] 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] rogpeppe: there's tools in lp:simplestreams (shell scripts and pythin modules) to generate the data i believe [09:13] rogpeppe: the only reason crsn is there (and the alias stuff) is that gustavo didn;t like the verbosity [09:13] so endpoint and region we pulled out of the ec2 image records [09:13] 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] i have no attachment to the name [09:14] wallyworld: cool [09:14] i just wanted something in it's own package that could read the image data we need to consume [09:15] wallyworld: it's really "imagemetadata" or something not too far from that, i think [09:15] sounds good to me [09:15] wallyworld: maybe just "images" :- [09:15] ) [09:15] that works also :-) [09:15] * wallyworld really has to run away now [09:16] wallyworld: have fun! [09:16] will do. thanks for looking at the crap code i wrote [09:50] fwereade: https://codereview.appspot.com/9084045/ [09:53] dimitern, cheers [10:07] dimitern, did you have a change of heart re errRefresh? I thought we decided last night that we could actually eliminate it [10:08] dimitern, by ignoring the initial value of the service's relation count [10:08] 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] 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] 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] fwereade: well, you're basically agreeing with rogpeppe about not using s.doc.RelationCount then? [10:11] 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] dimitern, we need to assert it, but we don't need to validate it when building the txn [10:11] fwereade: +1 [10:12] fwereade: that's what i was trying to get at [10:12] rogpeppe, dimitern: yeah, this stuff is tricky to communicate [10:12] ok, i'll remove the refresh and keep the assert(RC, eq, len(relations)) [10:12] dimitern: sounds good [10:13] dimitern, that's perfect [10:14] dimitern, LGTM with comments/suggestions in the CL then :) [10:14] fwereade: cheers [11:53] 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

[11:54] I've not got my maas/juju-core env quite right yet so can't confirm quickly [12:05] jamespage: i fixed this in juju-core [12:06] jamespage: it's in the 1.10 release [12:11] dimitern, +1 - great [13:46] no one has been poking me for reviews today... [13:49] mgz: it's a slow day it seems [13:49] everyone's packing :) [13:49] packing BYTES [13:50] there are some existing reviews to go over, and my own bits to land [13:50] yeah, i'll start packing soon as well [13:53] 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] yeah, need to go over that one === wedgwood_away is now known as wedgwood [14:04] 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] gah! [14:07] nogah [14:07] it will all be okay rog [14:08] mgz: apparently the cable is "mostly" been fixed [14:08] s/is/has/ [14:08] ehehe [14:09] *sigh* [14:12] fwereade, dimitern, mramm: i think i'm going to give up [14:13] fwereade, mramm: please let me know if there is anything i should know about [14:13] rogpeppe: bad luck [14:14] rogpeppe, I think the gist is "see you soon" [14:14] fwereade: \o/ [14:46] rogpeppe, is there a pithy name for the "1-buffered chan for mutexed field access" pattern? [14:47] * rogpeppe thinks [14:47] fwereade: not sure. "chan as resource holder" is about as good as i've got [14:47] fwereade: what's context will the name be used in? [14:52] rogpeppe, I'm just about to propose it [14:58] rogpeppe, dimitern: opinions on https://codereview.appspot.com/9175043 much appreciated [14:59] fwereade: will look shortly [14:59] 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] dimitern, rogpeppe: np [15:00] mgz, if you're on reviews, https://codereview.appspot.com/9175043 might be interesting [15:01] ta [15:06] fwereade: reviewed [15:11] dimitern, cheers === tasdomas is now known as tasdomas_afk [15:50] fwereade, what's the status of --config support for deploy? [15:50] hazmat, it's not complete but I don't anticipate problems finishing it off [15:51] hazmat, but it was a bit messier than I hoped and it's taken a little while to massage into shape [15:51] fwereade, cool.. its the last issue i think before people can start using core for their deployer stacks (ostack, etc) [15:51] i'm holding off an announce of the new core compatible deployer till it lands [15:52] 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] fwereade, thanks will do, and safe travels [15:53] hazmat, cheers, and you [15:53] hazmat, btw, re wedged unit status, can it be resolved by bouncing the unit agent? [15:54] fwereade, i've had multiple wedged causes.. [15:54] hazmat, ah sorry, I meant the resolved/hook-error one [15:57] 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] fwereade, i suspect that indeed a restart should fix the resolved wedge [16:10] hazmat, the other one is interesting too, I made a note on the bug [16:12] 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] fwereade, yes.. but i think its juju modifying/terminating the instance. that one needs more analysis. [16:21] fwereade, as afar getting foresenic evidence for this stuff, is there a good set of known things to capture? [16:21] fwereade, i was figuring i can grab the unified log and a mongodb dump which should cover everything afaics [16:23] hazmat, that should cover it, I think [17:15] fwereade: did you see my text around major-version upgrades yesterday? [17:16] rogpeppe, I saw it go by and totally failed to do anything with it [17:16] rogpeppe, sorry :( [17:17] fwereade: that's fine. i'd appreciate your thoughts at some point though. [17:20] rogpeppe where [17:21] hazmat: http://paste.ubuntu.com/5629750/ [17:21] rogpeppe, thanks [17:22] rogpeppe, you might also want to account for local changes made to machines during major upgrades [17:22] hazmat: what kind of thing are you thinking of? [17:23] 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] hazmat: that's a good point [17:24] rogpeppe, ie. upgrade major.. barrier for agents into restart mode. db upgrade. local upgrade. restart [17:25] hazmat: perhaps a similar thing should apply as at the server side. we could have a subcommand "upgradeclient" or something [17:25] 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] hazmat: yes, that's the intent [17:26] hazmat: although i see i've managed to omit that detail [17:28] hazmat: updated http://paste.ubuntu.com/5629770/ [17:28] 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] hazmat: yes. that's kind of implicit, but probably worth mentioning. [17:29] hazmat: all we need is some indicator from each client. [17:29] rogpeppe, re api wait for reporting upgrade status. a minimal api impl for upgrade that just reports status sounds appropriate [17:30] either status of agents into the barrier, or simple stage and status. [17:30] its trickier. [17:30] hazmat: that's not so easy though, as we need to upgrade all the API servers too [17:30] rogpeppe, yeah.. i'm saying upgrade job can run a minimal api [17:31] er.. api servers have a minimal upgrade api job [17:31] 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] 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] hazmat: see ya [17:46] right, i'm off [17:46] see y'all in Oakie! [18:08] 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] mgz, which demo? [22:41] 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