| hazmat | jimbaker, fwereade_ if you guys have a moment, this one needs a review.. https://codereview.appspot.com/5976074/ | 00:56 |
|---|---|---|
| jimbaker | hazmat, i will take a look after dinner | 00:57 |
| hazmat | jimbaker, awesome, thanks.. how's the rel-id stuff working out? | 01:01 |
| jimbaker | hazmat, i just proposed a new version of relation-hook-context | 01:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| jimbaker | hazmat, how do i delete the merge proposal? from lp and rietveld? | 01:09 |
| 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:10 |
| jimbaker | hazmat, shouldn't lbox do this? it seems to have a hard time with prereqs | 01:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| jimbaker | niemeyer, hazmat, that worked to merge trunk onto relation-id | 01:18 |
| jimbaker | and repush | 01:18 |
| 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:26 |
| 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:30 |
| hazmat | jimbaker, yeah.. that sounds good.. else this looks good | 01:31 |
| 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:32 |
| 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 | 01:33 |
| hazmat | niemeyer, re showing store url when deploying.. how's this look http://paste.ubuntu.com/913980/ | 02:13 |
| niemeyer | hazmat: +1 | 02:13 |
| niemeyer | hazmat: Thanks | 02:14 |
| hazmat | niemeyer, np | 02:15 |
| hazmat | niemeyer, the immortal session stuff is done, if your curious what it looks like https://codereview.appspot.com/5976074/ | 02:16 |
| hazmat | mostly just this one.. https://codereview.appspot.com/5976074/patch/1/6 | 02:17 |
| niemeyer | hazmat: Gosh.. | 02:45 |
| niemeyer | hazmat: I hope you continue working for Canonical for as long as we have to maintain that logic.. | 02:46 |
| niemeyer | (at least!) | 02:46 |
| hazmat | niemeyer, didn't see that much different than some of the watch stuff that TheMue is doing | 03:03 |
| 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:04 |
| 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:05 |
| niemeyer | hazmat: Frank has a watch in a loop.. | 03:06 |
| niemeyer | hazmat: and that's it. | 03:06 |
| 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. | 03:11 |
| jimbaker | looks like http://wtf.labix.org/ is stuck | 04:27 |
| jimbaker | hazmat, i'm going to file that bug tomorrow, good night all | 04:27 |
| 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:23 |
| 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:36 |
| 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:37 |
| jamespage | they are simple files with the name of the target file in them rather than symlinks | 08:38 |
| 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:40 |
| 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:41 |
| 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:42 |
| fwereade | jamespage, thanks, I'll try to poke around and see what's up | 08:43 |
| jamespage | fwereade, great - thankyou! | 08:43 |
| fwereade_ | jamespage, fyi, the *problem* is perfectly clear but it's taking a while to figure out what the "right" answer is | 10:01 |
| jamespage | fwereade_, would you like a bug report? I'm assuming the problem is not me :-) | 10:03 |
| fwereade_ | jamespage, a bug report would be great, the problem is indeed not you | 10:10 |
| jamespage | fwereade_, bug 973260 | 10:15 |
| fwereade_ | hazmat, btw, if you're on: https://codereview.appspot.com/5980045 | 11:39 |
| hazmat | fwereade_, lgtm | 12:25 |
| 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:27 |
| fwereade_ | jamespage, it's in trunk now, thank you for catching that | 12:33 |
| 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:34 |
| hazmat | yeah.. it looked like a patch conflict from the packaging | 12:46 |
| fwereade_ | hazmat, semi-review on https://codereview.appspot.com/5976074/ -- let me know your thoughts | 13:23 |
| 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:31 |
| hazmat | fwereade_, if your up for another one... https://codereview.appspot.com/5966076/ | 13:33 |
| fwereade_ | hazmat, oo, nice | 13:35 |
| fwereade_ | hazmat, perhaps document those drawbacks a little more obviously | 13:36 |
| === SpamapS_ is now known as SpamapS | ||
| hazmat | bcsaller, review delivered on sub-agent | 16:39 |
| hazmat | off to get some stitches out, bbiab | 16:39 |
| bcsaller | hazmat: thanks | 16:39 |
| jimbaker | wtf.labix.org has not run since r499 | 17:12 |
| 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:35 |
| 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:36 |
| niemeyer | jimbaker: Yeah, it's getting repeatedly stuck due to this bug | 17:37 |
| jimbaker | niemeyer, how often does it get stuck? | 17:38 |
| niemeyer | jimbaker: I last unblocked it on 494 | 17:38 |
| jimbaker | niemeyer, any logs you might have would be helpful | 17:39 |
| niemeyer | jimbaker: http://wtf.labix.org/500/ec2-wordpress.out | 17:40 |
| 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:43 |
| 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:53 |
| 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 | 17:54 |
| SpamapS | hazmat: perhaps we should push this back to galapagos? https://bugs.launchpad.net/juju/+bug/897645 | 19:06 |
| hazmat | SpamapS, yeah.. that seems reasonable | 19:27 |
| niemeyer | The interface of running juju-admin was broken again.. that's why juju status was hanging | 20:02 |
| 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:03 |
| SpamapS | --constraints-data is required? WTF? | 20:09 |
| SpamapS | oh | 20:09 |
| SpamapS | thats a mid-merge problem? | 20:09 |
| 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:10 |
| 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:11 |
| fwereade | how can a client be bootstrapping an old server? | 20:12 |
| niemeyer | fwereade: I can imagine several such ways | 20:12 |
| 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:13 |
| niemeyer | fwereade: I'm not really bringing any specific scenario up.. just stating the fact that compatibility has been broken at revision 500. | 20:14 |
| fwereade | niemeyer, I see :( | 20:15 |
| fwereade | SpamapS, can I assist in any way? | 20:15 |
| 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:17 |
| fwereade | SpamapS, cool | 20:18 |
| 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:19 |
| 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 | 20:20 |
| niemeyer | Revision 512 is green on wtf.. | 21:20 |
| === samkottle is now known as samkottler | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!