[00:56] <hazmat> jimbaker, fwereade_ if you guys have a moment, this one needs a review.. https://codereview.appspot.com/5976074/
[00:57] <jimbaker> hazmat, i will take a look after dinner
[01:01] <hazmat> jimbaker, awesome, thanks.. how's the rel-id stuff working out?
[01:05] <jimbaker> hazmat, i just proposed a new version of relation-hook-context
[01:06] <hazmat> jimbaker, cool, looking at it now
[01:06] <jimbaker> unfortunately it seemed to pick up every single change in trunk
[01:06] <hazmat> jimbaker, yeah.. that diff is foobar'd
[01:06] <jimbaker> i can never get lbox to work
[01:06] <hazmat> jimbaker, what's the cli invocation your using?
[01:06] <jimbaker> i just did lbox propose -cr
[01:07] <hazmat> jimbaker, and what's the bzr info on that branch?
[01:07] <jimbaker> probably most relevant is parent branch: /home/jbaker/canonical/juju/mine/relation-id
[01:08] <jimbaker> which has subsequently been merged into trunk
[01:08] <hazmat> yup
[01:08] <hazmat> jimbaker, can you resubmit the merge proposal by hand and remove the pre-req
[01:08] <jimbaker> hazmat, req= ?
[01:08] <hazmat> 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] <hazmat> req=requisite
[01:09] <jimbaker> hazmat, how do i delete the merge proposal? from lp and rietveld?
[01:10] <hazmat> just from lp
[01:10] <hazmat> jimbaker, i'd try removing the pre-requisite branch via editing first
[01:10] <hazmat> the mp on lp
[01:10] <jimbaker> hazmat, ok
[01:11] <jimbaker> hazmat, shouldn't lbox do this? it seems to have a hard time with prereqs
[01:12] <hazmat> 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] <hazmat> at least thats the conditions for your branch and ben's from yesterday
[01:12] <hazmat> perhaps niemeyer knows some more
[01:12] <jimbaker> plus a chain of rereqs
[01:12] <jimbaker> prereqs
[01:12] <hazmat> its not really a chain.. it just cares about the pre-requisite
[01:12] <hazmat> singular
[01:12] <niemeyer> What's up?
[01:13] <hazmat> niemeyer, fun with lbox
[01:13] <niemeyer> Ah, yeah.. it does that still..
[01:13] <niemeyer> jimbaker: You have to merge trunk on the pre-req too
[01:13] <hazmat> 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] <niemeyer> and re-push
[01:14] <jimbaker> 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] <niemeyer> 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] <niemeyer> jimbaker: I'll fix it when I have a moment
[01:14] <hazmat> jimbaker, rel-id-option was foobar'd on target as well though
[01:14] <jimbaker> sorry, the final prereq was relation-id in the chain i mentioned above, not relation-id-option
[01:18] <jimbaker> niemeyer, hazmat, that worked to merge trunk onto relation-id
[01:18] <jimbaker> and repush
[01:26] <hazmat> jimbaker, cool, thanks
[01:26] <hazmat> 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] <jimbaker> hazmat, that's a valid point... i was minimizing the test change here since we did have child relations before
[01:30] <jimbaker> it might make more sense to change it to "Flushed values for hook 'blah' on 'db:0':"
[01:30] <jimbaker> then it will be clearer what is the parent and what are the children, if any
[01:31] <hazmat> jimbaker, yeah.. that sounds good.. else this looks good
[01:32] <jimbaker> hazmat, cool, i can readily make that change after dinner - and merge it into trunk if it's approved ;)
[01:32] <hazmat> jimbaker, sounds good
[01:33] <jimbaker> hazmat, approved, sweet, ttyl
[01:33] <hazmat> jimbaker, but pls put in a bug per the previous review
[01:33] <jimbaker> hazmat, sounds good
[02:13] <hazmat> niemeyer, re showing store url when deploying.. how's this look http://paste.ubuntu.com/913980/
[02:13] <niemeyer> hazmat: +1
[02:14] <niemeyer> hazmat: Thanks
[02:15] <hazmat> niemeyer, np
[02:16] <hazmat> niemeyer, the immortal session stuff is done, if your curious what it looks like https://codereview.appspot.com/5976074/
[02:17] <hazmat> mostly just this one.. https://codereview.appspot.com/5976074/patch/1/6
[02:45] <niemeyer> hazmat: Gosh..
[02:46] <niemeyer> hazmat: I hope you continue working for Canonical for as long as we have to maintain that logic..
[02:46] <niemeyer> (at least!)
[03:03] <hazmat> niemeyer, didn't see that much different than some of the watch stuff that TheMue is doing
[03:04] <niemeyer> hazmat: I must be missing something then..
[03:04] <niemeyer> hazmat: It looks like pretty much the whole file is filled with logic for resetting and reestablishing sessions?
[03:05] <niemeyer> hazmat: and recreating ephemerals, and watches, and ...
[03:05] <hazmat> niemeyer, it is, but it resignals to watches via a synthetic event
[03:05] <niemeyer> hazmat: Heh
[03:05] <niemeyer> hazmat: How is that any similar to what Frank is doing then?
[03:06] <niemeyer> hazmat: Frank has a watch in a loop..
[03:06] <niemeyer> hazmat: and that's it.
[03:11] <hazmat> 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] <jimbaker> looks like http://wtf.labix.org/ is stuck
[04:27] <jimbaker> hazmat, i'm going to file that bug tomorrow, good night all
[08:23] <jamespage> morning folks - anyone around who can help we out with an issue with the charm store?
[08:23] <jamespage> struggling with charms that use symbolic links for hooks.... zookeeper for example
[08:36] <fwereade> jamespage, *possibly*
[08:36] <TheMue> fwereade: moin
[08:36] <fwereade> 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] <fwereade> heya TheMue
[08:36] <jamespage> fwereade, right-oh
[08:37] <jamespage> OK so I tried a juju deploy zookeeper on my local oneiric provider
[08:37] <jamespage> works fine with the charm on local disk in a bzr branch
[08:37] <jamespage> but I get an install error using the one from the charm store
[08:37] <jamespage> the symbolic links in the hooks directory appear to get broken as its deployed into the service unit
[08:38] <jamespage> they are simple files with the name of the target file in them rather than symlinks
[08:40] <fwereade> hmmm, just checking: is this to a recent version of juju?
[08:40] <fwereade> jamespage, ^^
[08:40] <jamespage> fwereade, the zip file containing the charm in ~/.juju/charms looks OK
[08:40] <jamespage> http://paste.ubuntu.com/914260/
[08:41] <jamespage> fwereade, I run from PPA all the time
[08:41] <jamespage>  0.5+bzr504-1juju4~precise1
[08:41] <fwereade> jamespage, what I'm really asking is how long ago you bootstrapped that juju
[08:41] <jamespage> fwereade, this morning
[08:42] <jamespage> and it uses juju-origin: ppa explicitly
[08:42] <fwereade> jamespage, ok then, the obvious answer is not the answer ;)
[08:42] <jamespage> just checks  - the service unit is using 0.5+bzr504-1juju4~oneiric1 as well
[08:43] <fwereade> jamespage, thanks, I'll try to poke around and see what's up
[08:43] <jamespage> fwereade, great - thankyou!
[10:01] <fwereade_> jamespage, fyi, the *problem* is perfectly clear but it's taking a while to figure out what the "right" answer is
[10:03] <jamespage> fwereade_, would you like a bug report?  I'm assuming the problem is not me :-)
[10:10] <fwereade_> jamespage, a bug report would be great, the problem is indeed not you
[10:15] <jamespage> fwereade_, bug 973260
[11:39] <fwereade_> hazmat, btw, if you're on: https://codereview.appspot.com/5980045
[12:25] <hazmat> fwereade_, lgtm
[12:27] <hazmat> fwereade_,  if you have a moment this one could also use a look..  https://codereview.appspot.com/5976074/
[12:27] <fwereade_> hazmat, thanks
[12:27] <fwereade_> hazmat, ofc
[12:33] <fwereade_> jamespage, it's in trunk now, thank you for catching that
[12:34] <jamespage> fwereade_, np - thanks for fixing up so quickly
[12:34] <jamespage> I need to pester SpamapS_to get the daily PPA daily again :-)
[12:46] <hazmat> yeah.. it looked like a patch conflict from the packaging
[13:23] <fwereade_> hazmat, semi-review on https://codereview.appspot.com/5976074/ -- let me know your thoughts
[13:31] <hazmat> 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] <hazmat> we're not doing either of those in juju
[13:33] <hazmat> fwereade_, if your up for another one... https://codereview.appspot.com/5966076/
[13:35] <fwereade_> hazmat, oo, nice
[13:36] <fwereade_> hazmat, perhaps document those drawbacks a little more obviously
[16:39] <hazmat> bcsaller, review delivered on sub-agent
[16:39] <hazmat> off to get some stitches out, bbiab
[16:39] <bcsaller> hazmat: thanks
[17:12] <jimbaker> wtf.labix.org has not run since r499
[17:35] <niemeyer> 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] <niemeyer> jimbaker: The logic for waiting for bootstraps seems a bit borked
[17:36] <jimbaker> niemeyer, ok - maybe we can diagnose. in any event, just wanted to point out that it has been stuck
[17:37] <niemeyer> jimbaker: Yeah, it's getting repeatedly stuck due to this bug
[17:38] <jimbaker> niemeyer, how often does it get stuck?
[17:38] <niemeyer> jimbaker: I last unblocked it on 494
[17:39] <jimbaker> niemeyer, any logs you might have would be helpful
[17:40] <niemeyer> jimbaker: http://wtf.labix.org/500/ec2-wordpress.out
[17:43] <jimbaker> 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] <niemeyer> jimbaker: Possibly
[17:43] <jimbaker> so the problem may be not in the loop to connect, but in the connection phase itself
[17:53] <hazmat> 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] <niemeyer> hazmat: I don't know, but that seems to have been raised a single time..
[17:54] <niemeyer> hazmat: and it actually exited.. in one of those attempts, though, it never went back
[17:54] <niemeyer> hazmat: The ps above shows the leak, too
[19:06] <SpamapS> hazmat: perhaps we should push this back to galapagos? https://bugs.launchpad.net/juju/+bug/897645
[19:27] <hazmat> SpamapS, yeah.. that seems reasonable
[20:02] <niemeyer> The interface of running juju-admin was broken again.. that's why juju status was hanging
[20:03] <niemeyer> usage: juju-admin initialize [-h] --instance-id INSTANCE_ID --admin-identity
[20:03] <niemeyer>                              ADMIN_IDENTITY --constraints-data
[20:03] <niemeyer>                              CONSTRAINTS_DATA --provider-type PROVIDER_TYPE
[20:03] <niemeyer> juju-admin initialize: error: argument --constraints-data is required
[20:03] <niemeyer> I'll just skip everything until the last revision
[20:09] <SpamapS> --constraints-data is required? WTF?
[20:09] <SpamapS> oh
[20:09] <SpamapS> thats a mid-merge problem?
[20:10] <fwereade> 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] <niemeyer> SpamapS: Yeah..
[20:10] <fwereade> SpamapS, is something else going on?
[20:10] <niemeyer> fwereade: Yeah, except it means the client and the server must be precisely in the same rev for this to work
[20:11] <fwereade> niemeyer, for bootstrap to work, yes
[20:11] <niemeyer> fwereade: FOr juju to work, yes :)
[20:11] <fwereade> niemeyer, having the same rev at bootstrap time should not be an issue, surely?
[20:11] <niemeyer> fwereade: Client before deadline with new server doesn't work.. client after the deadline with old server doesn't work
[20:12] <fwereade> how can a client be bootstrapping an old server?
[20:12] <niemeyer> fwereade: I can imagine several such ways
[20:13] <fwereade> niemeyer, hm, I can see how a non-updated client could get newer code from the PPA that it didn't cover
[20:13] <niemeyer> fwereade: I don't know if it's a problem in practice.. if you considered that with SpamapS, must be all good
[20:13] <fwereade> niemeyer, ...are you talking about people messing around with juju-origin for the old-server-bootstrapped-by-new-client problem?
[20:14] <niemeyer> fwereade:  I'm not really bringing any specific scenario up.. just stating the fact that compatibility has been broken at revision 500.
[20:15] <fwereade> niemeyer, I see :(
[20:15] <fwereade> SpamapS, can I assist in any way?
[20:17] <SpamapS> We get skew all the time
[20:17] <SpamapS> 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] <fwereade> SpamapS, +10 on that
[20:17] <SpamapS> fwereade: for the immediate time being, all is well, no worries.
[20:18] <fwereade> SpamapS, cool
[20:19] <fwereade> 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] <fwereade> 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] <niemeyer> Revision 512 is green on wtf..