/srv/irclogs.ubuntu.com/2012/03/29/#juju-dev.txt

hazmatSpamapS, zmq is awesome..  but this shit is hard enough without a src of truth00:42
hazmat;-)00:42
hazmatSpamapS, zmq is definitely on my radar for fun00:43
hazmatSpamapS, replacing debug log with zmq would work well, although rsyslogd would work as well for that case00:43
hazmatSpamapS, i'd like to ideally extract the key exchange and encryption from saltstack into a standalone lib for zmq cross dc relay or perhaps just start afresh with keyczar00:44
hazmatSpamapS, the problem with mq, esp a no persistence one like zmq, is that handling failures.. i mean we kill sigkill agents all day long, and they will come up and do the right thing00:46
hazmater.. we can00:46
hazmatbecause their state based00:46
fwereade_RAWR02:06
fwereade_http://paste.ubuntu.com/904867/02:06
fwereade_hazmat, I'll have another review for you in just a mo :)02:07
hazmatfwereade_, nice02:07
hazmatfwereade_, this expiration stuff is going to take up the rest of my night.. i don't see myself getting to the env settings02:08
fwereade_hazmat, sadly this has distracted me from both the logging and the warning but they're trivial by comparison02:08
fwereade_hazmat, tbh that's a good thing for me; we have slightly increased dependency on syncing and on default-series02:09
fwereade_hazmat, I'd hate to redo it so soon ;)02:09
hazmatfwereade_, how so re dep on sync?02:09
hazmatbcsaller, ping02:10
bcsallerhazmat: pong02:10
fwereade_hazmat, we need providers for constraints, and providers need environments02:10
fwereade_hazmat, so get-constraints also syncs02:10
hazmatbcsaller, i was wondering if rebase might work better than merge, i hope that diagram was helpful02:10
bcsallerhazmat: rebase doesn't really work either, I'd already merged trunk02:11
hazmatbcsaller, uncommit can undo some of it02:11
fwereade_hazmat, once different-syncing gets there it won't be any harder to fix; it's just finding and killing another set_config_state02:12
fwereade_hazmat, and bootstrap needs default-series to, er, pick a series02:12
hazmatfwereade_, why does get-constraint sync?02:12
* hazmat feels like he's missing something02:13
fwereade_hazmat, because it seems wrong to get the environment out of the config file02:13
hazmatthe provider needs an env.. but its not using it02:13
fwereade_hazmat, and I need an env to get a provider to get an actual constraints object02:14
hazmatfwereade_, but in the remote case the provider works against state02:14
hazmater. the provisioning agent case02:14
hazmatwhich follows that the cli could do the same02:14
hazmatits a bit odd isn't it02:15
hazmatyou need the disk env to get to the provider so it can read so it can populate the provider ;-)02:15
fwereade_hazmat, hmm, yeah; the PA waits for /environment (which only shows up when the cli syncs) and the cli *could* read stuff directly from there02:15
fwereade_hazmat, but tbh I'd rather get the state from where I know I'm meant to, even if I have to  send it tere first02:15
hazmatbcsaller, i think i see what the problem is..02:17
hazmateffectively it merged something which didn't have the commit after it merged something with the commit02:17
bcsallerI can't parse that :)02:18
bcsallereh, maybe I can02:18
hazmatbcsaller, so looking at the lineage.. http://kapilt.com/files/subreltype-graph.png02:19
bcsalleryeah02:19
bcsallerthat looks to be too far back for uncommit, I'll see if I can rebase 506 maybe02:21
hazmatbcsaller, nm.. i can't make heads or tails of it02:21
hazmatbcsaller, my thoughts where play capture changes via bzr diff and rollback .. the easiest thing might just be staging your files onto a fresh branch02:22
hazmatbut the pipeline complicates that, since its flowed through02:22
hazmati guess status-changes reapplied isn't the worst thing, but it wasn't immediately clear that was the only thing yanked02:22
bcsallerno, it wasn't clear, I agree02:23
hazmatbcsaller, so when was the last non-merge work?02:27
hazmatin terms of rev02:27
bcsallerlooks like r52102:28
hazmatbcsaller, yeah. its also yanking force-upgrade02:28
hazmatthats borked02:28
hazmatbcsaller, 521 looks good02:30
fwereade_hazmat, https://codereview.appspot.com/595704302:30
hazmatbcsaller, try this.. bzr uncommit -r 521 && bzr merge ../../trunk02:32
hazmatthe resulting diff looks a bit better02:32
hazmatbcsaller, make a copy first :-)02:32
hazmatfwereade_, oi! env constraints02:33
fwereade_hazmat, yeah, I needed a new node to make the warnings possible, so I thought I might as well do something useful with it :p02:35
fwereade_hazmat, warnings not actually done yet, but... ;)02:35
fwereade_hazmat, if you didn't see it: http://paste.ubuntu.com/904867/02:35
hazmatbcsaller, the resulting diff looks pretty good.. although it still has jimbaker's machine agent refactor.. but i think thats as far back in history we can go without making more work02:36
hazmatdoh02:36
hazmatthat's so odd02:38
hazmatthe diff looks good pre-merge commit, but then i commit the new merge, and its bad again02:38
bcsallerhazmat: rerunning tests now for sanity check02:39
hazmatbcsaller, that didn't quite work its really odd02:39
hazmatthe diff looks good pre-merge commit, but then i commit the new merge, and its bad again02:39
hazmati'm going to try a different merge algorithm.. its detecting the criss-cross but then it goes bonkers02:40
hazmatafter the merge commit02:40
bcsallerso strange02:40
hazmatbcsaller, yeah.. you can take rev 521, and diff to trunk and see the correct diff.. but if you merge for 522...02:42
hazmatbcsaller, did you base/merge this branch on jim's machine-agent before it was on trunk?02:45
bcsallerhazmat: yes, I think I did, I'd needed to get moving and it was already slated to go in. That could be the source of the issue though02:46
=== samkottle is now known as samkottler
hazmatfwereade__, i'm probably not going to get to those reviews till the am03:14
hazmatfwereade__, i think the subordinate branches bzr problems are unf*cked though03:15
hazmattbd03:15
fwereade__hazmat, that's a relief03:15
fwereade__hazmat, btw, astoundingly, the legacy stuff appears to block what it should; there will be one more review when the tests have passed03:16
fwereade__hazmat, warning about ignored constraints is not going to happen tonight I'm afraid03:17
hazmatfwereade__, fair enough03:19
hazmatfwereade__, is it night?03:19
fwereade__hazmat, I don;t think it's started getting light again, but it's not far off ;p03:19
hazmatfwereade__, thanks again03:19
fwereade__hazmat, a pleasure03:19
=== bigjools-afk is now known as jtvs-evil-twin
=== jtvs-evil-twin is now known as bigjools_
TheMuemorning, back from the gym, now ready to start08:51
rogpeppeTheMue: hiya09:05
TheMuerogpeppe: moin09:05
fwereaderogpeppe, TheMue, heyhey09:06
rogpeppeTheMue: watcher ready to submit, at last!09:06
rogpeppefwereade: yo!09:06
TheMuefwereade: also moin to you09:06
* fwereade cheers09:06
TheMuerogpeppe: i've seen and will do it in a few minutes09:06
fwereadeupdate, restarting09:06
TheMuerogpeppe: and then i have to look how i will use it for my config node. one way is a kind of wrapper, another one is just return the pure change and let the caller decide. i've got to check where and how the information is used today.09:10
rogpeppeTheMue: what code watches config nodes? and what do it do in response?09:12
TheMuerogpeppe: that's what i have to check.09:13
TheMuerogpeppe: today there are callbacks listening to changes of the config nodes of services or units09:15
rogpeppeTheMue: the way i'd imagined the watchers being used is that they'd be wrapped to create a similar interface but a different channel type that represents the higher-level changes in a nice way.09:15
TheMuerogpeppe: that's my favorite idea too09:16
TheMuerogpeppe: seen your last comment. the code will go in as it is now. ideas for tomb changes should be discussed somewhere else.10:05
rogpeppeTheMue: yeah, please submit10:06
rogpeppeTheMue: i was responding to gustavo's remarks10:06
TheMuerogpeppe: yip, but he i approved it and it will be closed after the submit. so i don't know if it's the right forum for a further discussion abot tomb.10:07
rogpeppeTheMue: sure.10:08
fwereadeallenap, ping10:26
allenapfwereade: Hi.10:26
fwereadeallenap, just wondering whether we'd verified my maas-name branch against a real maas?10:26
fwereadeallenap, if we haven't I would be much obliged if you would just have a go with lp:~fwereade/juju/shadow-trunk-120410:27
allenapfwereade: I haven't I'm afraid. I'll ask if someone can have a go. What command should we try?10:28
fwereadeallenap, I guess just `juju deploy --constraints maas-name=whatever ...`10:28
allenapfwereade: Thanks.10:29
fwereadeallenap, and maybe follow up with a `juju set-constraints -s maas-name=another` and `juju add-unit` to make sure that works10:29
fwereadeallenap, there are no constraints on add-unit at the moment10:30
fwereadeallenap, it's something I believe niemeyer would disapprove of -- but I would be very willing to write a branch for it if it strikes you as a needlessly infuriating omission10:31
fwereadeallenap, sorry, the followup set-constraints should have a service-name arg after the "-s"10:31
fwereadeallenap, (btw, please tell whoever it is not to forget to set juju-origin)10:33
allenapfwereade: Okay... I'll try and understand all that and get it done :)10:34
fwereadeallenap, sorry, I've been a bit buried in it for a while, I lack normal-person context, please bug me if anything is unclear10:35
allenapHehe :)10:35
fwereadehazmat, ping11:31
hazmatfwereade, pong11:32
* hazmat is still in a bootup sequence11:32
fwereadehazmat, just a status update: I have 4 reviews, one of which is moderately large but actually doesn't seem to bad when I see it in rietveld, 2 of which are trivial followups, and the final one is doc fixes only11:33
fwereadehazmat, and I'm as sure as I can be that the final code branch does what it should on both EC2 and local providers11:34
hazmatfwereade, excellent.. i'll give it a try with a legacy env11:34
fwereadehazmat, sweet11:35
fwereadehazmat, for reference:https://codereview.appspot.com/5957043/ https://codereview.appspot.com/5952045/ https://codereview.appspot.com/5956044/ https://codereview.appspot.com/5946047/11:36
hazmatfwereade, thanks11:36
fwereadehazmat, and the final code branch is lp:~fwereade/juju/warn-ignored-constraints11:36
hazmatfwereade, unsupported provider constraints are supposed to warn?12:09
hazmatfwereade, ie.. --constraints on bootstrap just get silently ignored12:09
fwereadehazmat, ...crap12:22
hazmatfwereade, for example setting zone on local provider12:23
hazmatfwereade, no worries.. works well otherwise12:23
fwereadehazmat, yeah, just an oversight on bootstrap12:23
fwereadehazmat, ty, nice catch12:23
fwereadehazmat, actually, huh, that's odd, let me investigate12:24
fwereadehazmat, works for me... http://paste.ubuntu.com/905506/12:25
fwereadehazmat, what are you seeing?12:29
hazmatfwereade, oh.. same thing12:32
fwereadehazmat, the INFO logging is a bit noisy which doesn't help12:32
hazmatmissed the warning at the top12:33
hazmatit only takes one missing inline callbacks to ruin a morning12:42
fwereadehazmat, man, tell me about it12:45
hazmatfwereade, can you verify this works for you..12:46
hazmat./bin/juju bootstrap -e aws --constraints="ec2-zone=b"12:46
hazmat./bin/juju deploy -e aws -n 2 --constraints="instance-type=m1.large" --repository=examples local:mysql12:46
fwereadehazmat, just a mo12:46
hazmatfwereade, never mind12:46
fwereadehazmat, working now?12:46
hazmati should try that with the right juju-origin12:46
fwereadehazmat, heh12:46
fwereade_hazmat, incidentally, yeah, that works for me13:00
hazmatfwereade_, even with the warning branch as origin, the bootstrap fails to initialize for me.. just finishing up the tx managed session branch, will investigate more13:02
fwereade_hazmat, disturbing... I got an m1.small and 2 m1.larges running in us-east-1b13:04
fwereade_hazmat, *possibly* a wrong PYTHONPATH?13:20
fwereade_hazmat, I confused myself with one of those the other day13:20
fwereade_hazmat, incidentally, pre-existing bug? terminate-machine should also do env-config syncing in case access stuff has changed13:32
fwereade_heya niemeyer13:57
fwereade_brb, quick walk around the block13:59
andrewsmedinals -lsa14:08
andrewsmedinals -lsa14:08
andrewsmedinaops :p14:08
rogpeppe niemeyer, TheMue: i'm thinking for projects we don't mind losing r60 suport for we should just remove all our go tags. then we won't have to remember to tag every time tip changes. we'll only have to add a tag when we start to rely on something from go1.1.14:12
niemeyerfwereade_: Heya14:13
niemeyerrogpeppe: Why would we need to remove the tags?14:13
rogpeppeniemeyer: because the tags are there, they'll be used by preference instead of tip.14:13
rogpeppeniemeyer: which means we have to remember to tag on every push14:14
niemeyerrogpeppe: Hmm14:14
niemeyerrogpeppe: I've tested yesterday, and mgo looked alright without any tags14:15
niemeyerrogpeppe: Did I do something wrong?14:15
rogpeppeniemeyer: has it still got some old tags?14:15
niemeyerrogpeppe: All of them14:15
rogpeppeniemeyer: hmm, maybe i'm mistaken. let me check.14:16
rogpeppeniemeyer: no, i'm right.14:17
rogpeppeniemeyer: if you go get mgo, you get revision 114, not revision 11514:18
rogpeppeniemeyer: because 114 has the go.weekly.2012-01-20 tag14:18
niemeyerrogpeppe: Hmm.. ok.. that's probably what I wanted indeed, at least in that case14:19
rogpeppeniemeyer: because it was just a comment change?14:19
niemeyerrogpeppe: No, because mgo has releases.. intermediate changes shouldn't be published before announced14:20
rogpeppeniemeyer: ah, in that case you'll definitely want to do explicit tagging.14:20
niemeyerrogpeppe: So which projects do you suggest we take tags out?>14:20
rogpeppeniemeyer: any projects we don't have explicit releases for. gozk, gnuflag, juju itself while we're developing it.14:22
rogpeppegoamz seems to have a release tag.14:22
niemeyerrogpeppe: Sound good14:22
niemeyers14:22
niemeyermthaddon: ping14:23
mthaddonniemeyer: howdy14:24
niemeyermthaddon: Heya.. I've heard things went well?14:25
mthaddonniemeyer: you did? excellent. What things?14:25
niemeyermthaddon: Your progress on the store :)14:25
mthaddonniemeyer: erm, seems to be going okay, I just had a question about how to "reset mongodb" in a replicated configuration - will db.dropDatabase() work, or is something else needed?14:26
niemeyermthaddon: I'd suggest cleaning up the files in both machines14:27
niemeyermthaddon: and restarting the database14:27
mthaddonniemeyer: which files?14:27
niemeyermthaddon: The files backing the database14:27
niemeyermthaddon: Sorry, not the database.. the files backing mongodb14:27
niemeyermthaddon: Just remove them and start anew14:28
mthaddonniemeyer: so just remove all the files in the directory defined as "dbpath" in /etc/mongodb.conf"?14:28
niemeyermthaddon: Right14:28
mthaddonok, will do - thx14:28
hazmatassuming only one db.. dropDatabase should work though14:29
hazmatniemeyer, why would you recommend manually deleting files?14:29
niemeyerhazmat: Because I'm lazy, most critically14:31
niemeyerhazmat: There's no chance of getting this one wrong14:32
mthaddonhazmat: how would dropDatabase work in a replicated setting?14:34
niemeyermthaddon: It should actually work..14:34
niemeyermthaddon: It's just another operation in the oplog14:34
mthaddonok, maybe I'll try that on the master and see - can always take a look and delete files if that doesn't work as expected14:35
niemeyermthaddon: Sure, try it out.. just make sure you got the right database please14:35
niemeyermthaddon: mongo creates databases on demand14:35
niemeyermthaddon: Which means a typo would go unperceived14:35
mthaddonnot if I check it before and afterwards :)14:35
niemeyermthaddon: Right, exactly14:36
niemeyermthaddon: show collections should tell you're in the right place14:36
mthaddonyep14:36
rogpeppeniemeyer: doing ssh connect. shall i make it support multiple zookeeper servers? or shall i stick with current functionality?14:36
niemeyerhazmat: That's why.. :)14:36
mthaddonniemeyer: I take it it's just the "juju" db we care about, not the "local" db?14:36
niemeyermthaddon: Right.. the local database is for maintenance of mongo itself14:36
niemeyermthaddon: It's not replicated14:37
robbiew$ juju deploy mysql -e AWS14:40
robbiew2012-03-29 09:39:12,678 INFO Searching for charm cs:oneiric/mysql in remote charm repository: https://store.juju.ubuntu.com14:40
robbiew2012-03-29 09:39:14,711 INFO Connecting to environment...14:40
robbiew2012-03-29 09:39:17,923 INFO Connected to environment.14:40
robbiew2012-03-29 09:39:20,506 INFO Charm deployed as service: 'mysql'14:40
robbiew2012-03-29 09:39:20,507 INFO 'deploy' command finished successfully14:40
robbiew\0/14:40
niemeyerrobbiew: What.. really!? :-)14:43
robbiewniemeyer: yep14:44
robbiewI had to set default back to oneiric, b/c we have no precise charms I guess14:45
robbiewbut still...awesome14:45
robbiewniemeyer: not sure if outside folks can see the store yet...as my ssh connections on ubuntu.com and canonical.com domains go through chinstrap14:46
niemeyerrobbiew: We have a few, but way less14:46
niemeyerrobbiew: We need search now ;)14:46
robbiewyep....baby steps14:47
mthaddonniemeyer: code updated and nagios check seems happier thx14:47
SpamapSkeepalives.. causing problems since 199514:51
SpamapSthe charm store is *live*14:53
SpamapS    charm: cs:oneiric/thinkup-014:53
SpamapSrobbiew: re us having no charms for precise.. I had a brief chat w/ m_3 about that yesterday...14:53
SpamapSrobbiew: we're going to run the charm tester with all of the oneiric charms on precise.. and fix them for precise.. then I'll have a LOSA pull the big handle that changes the series to precise as soon as all the tests pass. :)14:54
rogpeppeniemeyer: i just deleted the tags on gozk/zookeeper14:56
robbiewSpamapS: coolio14:56
niemeyerrogpeppe: Have you trying pulling?15:09
niemeyerErm15:09
niemeyerrogpeppe: Have you tried pulling?15:09
niemeyermthaddon: Superb15:09
niemeyermthaddon: SpamapS and robbiew are already seeing the post-drop database?15:10
mthaddonyep15:10
niemeyermthaddon: Brilliant, thank you15:10
mthaddonnp15:10
niemeyermthaddon: Sorry for all the mess that was involved in getting this out15:10
mthaddonno problem - looking forward to the juju-ised version when we get there15:11
hazmatnice15:11
rogpeppeniemeyer: pulling what? gozk?15:11
niemeyermthaddon: It's ironic that I've worked so much to make it trivial to deploy, but the main blockers were not technical15:11
niemeyerrogpeppe: The branch you deleted the tags on15:11
rogpeppeniemeyer: yeah, it seems to go get fine15:11
niemeyerrogpeppe: Have you tried pulling the branch, and checking to see if the tags are there?15:12
rogpeppeniemeyer: yeah.15:12
rogpeppeniemeyer: (they're not)15:13
niemeyerrogpeppe: Cool, did you have to delete the branch in launchpad?15:14
rogpeppeniemeyer: no. i just did a lightweight checkout, then a few "bzr tag --delete"s15:14
niemeyerrogpeppe: Hmm.. interesting.. I hadn't tried that.15:15
niemeyerrogpeppe: Pushing tag removals doesn't work15:15
rogpeppeniemeyer: i used the same approach we were taking to adding tags.15:15
niemeyerrogpeppe: Right, cool.. it's just that removing a local tag and pushing doesn't work.. I wasn't expecting the lightweight checkout to work either. Awesome that it works.15:16
rogpeppeniemeyer: cool.15:16
rogpeppeniemeyer: i get tags are treated like sets.15:17
rogpeppes/get/guess/15:17
robbiewSpamapS: how soon can we get the juju version with the correct store URL in precise?15:32
niemeyerOkay!15:33
niemeyerI guess it's time to pretend this is a holiday :)15:34
niemeyerI'll step out for lunch, and pack to the trip when I'm back15:34
niemeyerCheers all!15:34
SpamapSrobbiew: I can upload today15:40
rogpeppeniemeyer: you off for the rest of the day?15:41
rogpeppeis there a meeting today?15:41
robbiewSpamapS: cool15:47
robbiewSpamapS: would that mean people would get it in the beta 2 upgrade?15:47
SpamapSrobbiew: possibly, I'll ask release team about universe packages15:48
SpamapSrobbiew: FYI, beta freeze was just lifted, so I'll upload juju shortly15:55
robbiewSpamapS: no worries..I'm leaving it out of the release announcement, given it wasn't *technically* part of the beta 215:56
robbiewwe can blog/tweet the shit out of it today/tomorrow anyway15:56
fwereade_SpamapS, so, no chance for any new merges before then?15:59
SpamapSfwereade_: juju isn't going on any CDs, so arguably we can keep changing things forever.. but at some point.. we need to stabilize and *test*. :)16:04
fwereade_SpamapS, believe me, that's what I want to do ;)16:05
SpamapSfwereade_: we have some merges to get in for security problems pointed out by jdstrand .. I'm sure we can also get a few important things in before release day. :)16:05
fwereade_SpamapS, cool, I'm just stressing out because I *do* have golang work as well, I've had a ludicrously painful push to get constraints into a state I'm not too embarrassed about, and I fear that if I don't draw a line under it *now* I'm going to end up back off in goland with my reviews quietly rotting in the sun16:07
fwereade_SpamapS, but none of that is your problem, sorry16:07
SpamapSfwereade_: given the deadline for the python version (1 month ago..) and the deadline for the golang version.. (???) .. perhaps we can persuade your golang fellows to wait a bit while we sort out the python mess?16:08
fwereade_SpamapS, no doubt that will be doable -- the rotting golang reviews are indeed less important at this time -- but IIRC this was originally timeboxed to 2 weeks and I think I've used most of them already ;)16:10
SpamapSfwereade_: 2 galactic standard weeks.. read the fine print. ;)16:11
fwereade_SpamapS, haha :)16:11
SpamapSfwereade_: to the more practical point.. are you all that far away from finishing that last constraints branch?16:15
fwereade_SpamapS, there are always possible enhancements but IMO my last branch is good enough16:15
SpamapSfwereade_: so just waiting for +1's?16:16
fwereade_SpamapS, frankly the 6am one was close enough, today's work is just polishing little rough edges as I come across them16:16
fwereade_SpamapS, yeah, but that's not a "just" IME16:16
* hazmat dives back into the review stack16:35
hazmatthere's gold in here16:35
robbiewlol16:39
=== marrusl_ is now known as marrusl
jimbakerthat was painful. finally tracked down the proximate source of a failure in the reworked relation hook context. most likely just a weird test setup issue, but at least i have something i can troubleshoot17:41
* niemeyer heading off.. see you all later!18:06
fwereade__niemeyer, enjoy18:07
hazmatfwereade__, the look env constraints look really nice19:55
* hazmat wonders on the difference between irrelevant and invalid19:56
hazmatfwereade__, all the branches look good, except the doc branch, where i'd like some additional context if you intended it as dev or user doc20:05
SpamapShazmat: i think there's something wrong with the store caching21:17
hazmatSpamapS, how so?21:18
SpamapShttp://paste.ubuntu.com/906286/21:18
SpamapSThe first thing that gets cached fails every time for me21:18
SpamapSends up with an empty file instead of the zip file21:18
SpamapSeverything after that works fine21:18
hazmatSpamapS, it looks like the charm store is empty at the moment21:34
hazmati'm getting not found json responses to all my queries.21:34
SpamapSweird, I've been deploying stuff since it went live :)21:35
SpamapShazmat: hm actually I think just mysql is messed up21:36
SpamapSother charms are fine21:36
SpamapSI just always do mysql first :)21:36
hazmatSpamapS, yeah.. seems to work well outside of mysql21:49
SpamapShazmat: ssl verify branch polished up all shiny for you now :)23:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!