| === wedgwood is now known as wedgwood_away | ||
| thumper | davecheney: ping | 03:27 |
|---|---|---|
| thumper | unping | 04:27 |
| * thumper wanders off for a bit | 04:27 | |
| === tasdomas_afk is now known as tasdomas | ||
| rogpeppe | wallyworld: ping | 08:50 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| wallyworld | that adds to the complexity | 09:02 |
| 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:03 |
| 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:04 | |
| mgz | I was trying to not post links people can't read to public channel, but it doesn't matter much :) | 09:05 |
| 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:06 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 | |
| rogpeppe | wallyworld: have fun! | 09:16 |
| wallyworld | will do. thanks for looking at the crap code i wrote | 09:16 |
| dimitern | fwereade: https://codereview.appspot.com/9084045/ | 09:50 |
| fwereade | dimitern, cheers | 09:53 |
| fwereade | dimitern, did you have a change of heart re errRefresh? I thought we decided last night that we could actually eliminate it | 10:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| fwereade | dimitern, that's perfect | 10:13 |
| fwereade | dimitern, LGTM with comments/suggestions in the CL then :) | 10:14 |
| dimitern | fwereade: cheers | 10:14 |
| 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:53 |
| jamespage | I've not got my maas/juju-core env quite right yet so can't confirm quickly | 11:54 |
| dimitern | jamespage: i fixed this in juju-core | 12:05 |
| dimitern | jamespage: it's in the 1.10 release | 12:06 |
| jamespage | dimitern, +1 - great | 12:11 |
| mgz | no one has been poking me for reviews today... | 13:46 |
| dimitern | mgz: it's a slow day it seems | 13:49 |
| mgz | everyone's packing :) | 13:49 |
| mgz | packing BYTES | 13:49 |
| 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:50 |
| 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:53 |
| mgz | yeah, need to go over that one | 13:56 |
| === wedgwood_away is now known as wedgwood | ||
| 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:04 |
| rogpeppe | gah! | 14:06 |
| mgz | nogah | 14:07 |
| mgz | it will all be okay rog | 14:07 |
| rogpeppe | mgz: apparently the cable is "mostly" been fixed | 14:08 |
| rogpeppe | s/is/has/ | 14:08 |
| mgz | ehehe | 14:08 |
| rogpeppe | *sigh* | 14:09 |
| rogpeppe | fwereade, dimitern, mramm: i think i'm going to give up | 14:12 |
| rogpeppe | fwereade, mramm: please let me know if there is anything i should know about | 14:13 |
| dimitern | rogpeppe: bad luck | 14:13 |
| fwereade | rogpeppe, I think the gist is "see you soon" | 14:14 |
| rogpeppe | fwereade: \o/ | 14:14 |
| fwereade | rogpeppe, is there a pithy name for the "1-buffered chan for mutexed field access" pattern? | 14:46 |
| * 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:47 |
| fwereade | rogpeppe, I'm just about to propose it | 14:52 |
| fwereade | rogpeppe, dimitern: opinions on https://codereview.appspot.com/9175043 much appreciated | 14:58 |
| 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 | 14:59 |
| fwereade | mgz, if you're on reviews, https://codereview.appspot.com/9175043 might be interesting | 15:00 |
| mgz | ta | 15:01 |
| dimitern | fwereade: reviewed | 15:06 |
| fwereade | dimitern, cheers | 15:11 |
| === tasdomas is now known as tasdomas_afk | ||
| 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:50 |
| 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:51 |
| 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:52 |
| fwereade | hazmat, cheers, and you | 15:53 |
| fwereade | hazmat, btw, re wedged unit status, can it be resolved by bouncing the unit agent? | 15:53 |
| hazmat | fwereade, i've had multiple wedged causes.. | 15:54 |
| fwereade | hazmat, ah sorry, I meant the resolved/hook-error one | 15:54 |
| 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 | 15:57 |
| fwereade | hazmat, the other one is interesting too, I made a note on the bug | 16:10 |
| 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:12 |
| hazmat | fwereade, yes.. but i think its juju modifying/terminating the instance. that one needs more analysis. | 16:20 |
| 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:21 |
| fwereade | hazmat, that should cover it, I think | 16:23 |
| rogpeppe | fwereade: did you see my text around major-version upgrades yesterday? | 17:15 |
| fwereade | rogpeppe, I saw it go by and totally failed to do anything with it | 17:16 |
| fwereade | rogpeppe, sorry :( | 17:16 |
| rogpeppe | fwereade: that's fine. i'd appreciate your thoughts at some point though. | 17:17 |
| hazmat | rogpeppe where | 17:20 |
| rogpeppe | hazmat: http://paste.ubuntu.com/5629750/ | 17:21 |
| hazmat | rogpeppe, thanks | 17:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| rogpeppe | hazmat: yes, that's the intent | 17:26 |
| rogpeppe | hazmat: although i see i've managed to omit that detail | 17:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| * 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:32 |
| rogpeppe | right, i'm off | 17:46 |
| rogpeppe | see y'all in Oakie! | 17:46 |
| 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:08 |
| hazmat | mgz, which demo? | 18:36 |
| 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> | 22:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!