[00:56] jimbaker, fwereade_ if you guys have a moment, this one needs a review.. https://codereview.appspot.com/5976074/ [00:57] hazmat, i will take a look after dinner [01:01] jimbaker, awesome, thanks.. how's the rel-id stuff working out? [01:05] hazmat, i just proposed a new version of relation-hook-context [01:06] jimbaker, cool, looking at it now [01:06] unfortunately it seemed to pick up every single change in trunk [01:06] jimbaker, yeah.. that diff is foobar'd [01:06] i can never get lbox to work [01:06] jimbaker, what's the cli invocation your using? [01:06] i just did lbox propose -cr [01:07] jimbaker, and what's the bzr info on that branch? [01:07] probably most relevant is parent branch: /home/jbaker/canonical/juju/mine/relation-id [01:08] which has subsequently been merged into trunk [01:08] yup [01:08] jimbaker, can you resubmit the merge proposal by hand and remove the pre-req [01:08] hazmat, req= ? [01:08] jimbaker, bcsaller and i wasted an hr on this problem yesterday.. it ended up being the easiest thing to do unfoobar lbox was to delete the merge proposal [01:08] req=requisite [01:09] hazmat, how do i delete the merge proposal? from lp and rietveld? [01:10] just from lp [01:10] jimbaker, i'd try removing the pre-requisite branch via editing first [01:10] the mp on lp [01:10] hazmat, ok [01:11] hazmat, shouldn't lbox do this? it seems to have a hard time with prereqs [01:12] jimbaker, yeah.. it should.. it seems to fall down for pre-requistes that have been merged, along with a pre-existing merge proposal for the branch in question [01:12] at least thats the conditions for your branch and ben's from yesterday [01:12] perhaps niemeyer knows some more [01:12] plus a chain of rereqs [01:12] prereqs [01:12] its not really a chain.. it just cares about the pre-requisite [01:12] singular [01:12] What's up? [01:13] niemeyer, fun with lbox [01:13] Ah, yeah.. it does that still.. [01:13] jimbaker: You have to merge trunk on the pre-req too [01:13] niemeyer, it seems like lbox respects the merge proposal in preference to rediscovering the prerequisite or taking the pre-requisite on the cli explicitly [01:13] and re-push [01:14] hazmat, it also was having a prereq issue for relation-ids-command with prereq of relation-hook-context with prereq of relation-id-option, prior to mergin [01:14] jimbaker: lbox must pick trunk after the pre-req is merge, but it doesn't do that yet, so you have to merge trunk on the pre-req and repush it, so that the diff against it is right [01:14] jimbaker: I'll fix it when I have a moment [01:14] jimbaker, rel-id-option was foobar'd on target as well though [01:14] sorry, the final prereq was relation-id in the chain i mentioned above, not relation-id-option [01:18] niemeyer, hazmat, that worked to merge trunk onto relation-id [01:18] and repush [01:26] jimbaker, cool, thanks [01:26] jimbaker, is it meaningful to distinguish self._context on change flushing via omission of the rel-id? seems like we'd always want the rel-id here, as there is no contextual ref in the log to the rel in question [01:30] hazmat, that's a valid point... i was minimizing the test change here since we did have child relations before [01:30] it might make more sense to change it to "Flushed values for hook 'blah' on 'db:0':" [01:30] then it will be clearer what is the parent and what are the children, if any [01:31] jimbaker, yeah.. that sounds good.. else this looks good [01:32] hazmat, cool, i can readily make that change after dinner - and merge it into trunk if it's approved ;) [01:32] jimbaker, sounds good [01:33] hazmat, approved, sweet, ttyl [01:33] jimbaker, but pls put in a bug per the previous review [01:33] hazmat, sounds good [02:13] niemeyer, re showing store url when deploying.. how's this look http://paste.ubuntu.com/913980/ [02:13] hazmat: +1 [02:14] hazmat: Thanks [02:15] niemeyer, np [02:16] niemeyer, the immortal session stuff is done, if your curious what it looks like https://codereview.appspot.com/5976074/ [02:17] mostly just this one.. https://codereview.appspot.com/5976074/patch/1/6 [02:45] hazmat: Gosh.. [02:46] hazmat: I hope you continue working for Canonical for as long as we have to maintain that logic.. [02:46] (at least!) [03:03] niemeyer, didn't see that much different than some of the watch stuff that TheMue is doing [03:04] hazmat: I must be missing something then.. [03:04] hazmat: It looks like pretty much the whole file is filled with logic for resetting and reestablishing sessions? [03:05] hazmat: and recreating ephemerals, and watches, and ... [03:05] niemeyer, it is, but it resignals to watches via a synthetic event [03:05] hazmat: Heh [03:05] hazmat: How is that any similar to what Frank is doing then? [03:06] hazmat: Frank has a watch in a loop.. [03:06] hazmat: and that's it. [03:11] niemeyer, yeah.. not much in common, persistent watches and persistent sessions, both both are basically just processing watch events, the session code also traps on conn errors though. [04:27] looks like http://wtf.labix.org/ is stuck [04:27] hazmat, i'm going to file that bug tomorrow, good night all [08:23] morning folks - anyone around who can help we out with an issue with the charm store? [08:23] struggling with charms that use symbolic links for hooks.... zookeeper for example [08:36] jamespage, *possibly* [08:36] fwereade: moin [08:36] jamespage, there were a couple of recent changes I wasn't directly involved in but I think I remember the thrust of it [08:36] heya TheMue [08:36] fwereade, right-oh [08:37] OK so I tried a juju deploy zookeeper on my local oneiric provider [08:37] works fine with the charm on local disk in a bzr branch [08:37] but I get an install error using the one from the charm store [08:37] the symbolic links in the hooks directory appear to get broken as its deployed into the service unit [08:38] they are simple files with the name of the target file in them rather than symlinks [08:40] hmmm, just checking: is this to a recent version of juju? [08:40] jamespage, ^^ [08:40] fwereade, the zip file containing the charm in ~/.juju/charms looks OK [08:40] http://paste.ubuntu.com/914260/ [08:41] fwereade, I run from PPA all the time [08:41] 0.5+bzr504-1juju4~precise1 [08:41] jamespage, what I'm really asking is how long ago you bootstrapped that juju [08:41] fwereade, this morning [08:42] and it uses juju-origin: ppa explicitly [08:42] jamespage, ok then, the obvious answer is not the answer ;) [08:42] just checks - the service unit is using 0.5+bzr504-1juju4~oneiric1 as well [08:43] jamespage, thanks, I'll try to poke around and see what's up [08:43] fwereade, great - thankyou! [10:01] jamespage, fyi, the *problem* is perfectly clear but it's taking a while to figure out what the "right" answer is [10:03] fwereade_, would you like a bug report? I'm assuming the problem is not me :-) [10:10] jamespage, a bug report would be great, the problem is indeed not you [10:15] fwereade_, bug 973260 [11:39] hazmat, btw, if you're on: https://codereview.appspot.com/5980045 [12:25] fwereade_, lgtm [12:27] fwereade_, if you have a moment this one could also use a look.. https://codereview.appspot.com/5976074/ [12:27] hazmat, thanks [12:27] hazmat, ofc [12:33] jamespage, it's in trunk now, thank you for catching that [12:34] fwereade_, np - thanks for fixing up so quickly [12:34] I need to pester SpamapS_to get the daily PPA daily again :-) [12:46] yeah.. it looked like a patch conflict from the packaging [13:23] hazmat, semi-review on https://codereview.appspot.com/5976074/ -- let me know your thoughts [13:31] fwereade_, thanks.. regarding the costs, it comes out to two primary things.. watches which check watch events have to accept a session event, and sequence node based patterns/algorithms (ie. like the std zk lock recipe) need to be rethought [13:31] we're not doing either of those in juju [13:33] fwereade_, if your up for another one... https://codereview.appspot.com/5966076/ [13:35] hazmat, oo, nice [13:36] hazmat, perhaps document those drawbacks a little more obviously === SpamapS_ is now known as SpamapS [16:39] bcsaller, review delivered on sub-agent [16:39] off to get some stitches out, bbiab [16:39] hazmat: thanks [17:12] wtf.labix.org has not run since r499 [17:35] jimbaker: wtf 9867 1.2 7.1 7606936 35736 pts/2 Sl+ 09:21 3:14 python /home/wtf/ftests/build/juju/bin/juju status [17:36] jimbaker: The logic for waiting for bootstraps seems a bit borked [17:36] niemeyer, ok - maybe we can diagnose. in any event, just wanted to point out that it has been stuck [17:37] jimbaker: Yeah, it's getting repeatedly stuck due to this bug [17:38] niemeyer, how often does it get stuck? [17:38] jimbaker: I last unblocked it on 494 [17:39] niemeyer, any logs you might have would be helpful [17:40] jimbaker: http://wtf.labix.org/500/ec2-wordpress.out [17:43] niemeyer, interesting that it is getting "Too many open files" (so presumably some sort of cleanup is not occurring) after it fails to access s3 [17:43] jimbaker: Possibly [17:43] so the problem may be not in the loop to connect, but in the connection phase itself [17:53] niemeyer, isn't this the problem.. ERROR Cannot connect to environment: DNS lookup failed: address 's3.amazonaws.com' not found: [Errno -2] Name or service not known. [17:53] hazmat: I don't know, but that seems to have been raised a single time.. [17:54] hazmat: and it actually exited.. in one of those attempts, though, it never went back [17:54] hazmat: The ps above shows the leak, too [19:06] hazmat: perhaps we should push this back to galapagos? https://bugs.launchpad.net/juju/+bug/897645 [19:27] SpamapS, yeah.. that seems reasonable [20:02] The interface of running juju-admin was broken again.. that's why juju status was hanging [20:03] usage: juju-admin initialize [-h] --instance-id INSTANCE_ID --admin-identity [20:03] ADMIN_IDENTITY --constraints-data [20:03] CONSTRAINTS_DATA --provider-type PROVIDER_TYPE [20:03] juju-admin initialize: error: argument --constraints-data is required [20:03] I'll just skip everything until the last revision [20:09] --constraints-data is required? WTF? [20:09] oh [20:09] thats a mid-merge problem? [20:10] SpamapS, --constraints-data is required to bootstrap the current code, which should be fine because current code send a cloud-init which includes --constraints-data for initialize [20:10] SpamapS: Yeah.. [20:10] SpamapS, is something else going on? [20:10] fwereade: Yeah, except it means the client and the server must be precisely in the same rev for this to work [20:11] niemeyer, for bootstrap to work, yes [20:11] fwereade: FOr juju to work, yes :) [20:11] niemeyer, having the same rev at bootstrap time should not be an issue, surely? [20:11] fwereade: Client before deadline with new server doesn't work.. client after the deadline with old server doesn't work [20:12] how can a client be bootstrapping an old server? [20:12] fwereade: I can imagine several such ways [20:13] niemeyer, hm, I can see how a non-updated client could get newer code from the PPA that it didn't cover [20:13] fwereade: I don't know if it's a problem in practice.. if you considered that with SpamapS, must be all good [20:13] niemeyer, ...are you talking about people messing around with juju-origin for the old-server-bootstrapped-by-new-client problem? [20:14] fwereade: I'm not really bringing any specific scenario up.. just stating the fact that compatibility has been broken at revision 500. [20:15] niemeyer, I see :( [20:15] SpamapS, can I assist in any way? [20:17] We get skew all the time [20:17] Its why I've proposed that we develop a feature where the client pushes *all* of juju onto the bootstrap node or into file storage and that we no longer try to disribute from "distro" or "ppa" after bootstrap. [20:17] SpamapS, +10 on that [20:17] fwereade: for the immediate time being, all is well, no worries. [20:18] SpamapS, cool [20:19] SpamapS, I am concerned that I misjudged the --constraints-data thing: my thinking was "either juju-origin matches the client, in which case we're golden; or it doesn't, in which case we're dealing with someone who should know what they're doing" [20:20] SpamapS, to be fair juju-origin has bitten all of us enough times that assuming people know what they're doing is a touch optimistic [21:20] Revision 512 is green on wtf.. === samkottle is now known as samkottler