[00:03] Hmm.. weird problem here.. after a successful install hook.. [00:03] http://paste.ubuntu.com/698811/ [00:14] SpamapS, trying to think where to start there with that (twisted's reactor structure makes such output frequently useless) [00:15] SpamapS, is it related at all to the bug you just reported (bug 861298)? [00:15] <_mup_> Bug #861298: libasound2 addition to linaro-x11-base seems suspicious < https://launchpad.net/bugs/861298 > [00:15] jimbaker: I'm betting that the ZK connection failed for some reason... and it just needs to be handled/reconnected [00:15] (wrong bug # obviously) [00:15] jimbaker: same env, but I don't think its related no [00:17] SpamapS, so is the agent still running on that node? [00:18] jimbaker: oo, darn, I destroyed the env.. didn't check [00:18] SpamapS, making agents robust against failure with upstart is something we discussed, i assume it's still not there yet [00:19] SpamapS, no worries, random failures are easy enough to recreate ;) [00:19] (of the sort seen here, seriously) [00:19] jimbaker: I'll report it if I see it again [00:19] this particular case is a *very* busy nova compute machine [00:20] so its entirely possible that ZK was overwhelmed or something else weird happened [00:20] SpamapS, ahh, that will much more likely expose things [00:21] SpamapS, also i need to review https://code.launchpad.net/~hazmat/txzookeeper/errors-with-path/+merge/77254, this looks good for getting somewhat better info - knowing the actual path is a pretty big signal, especially as we add more nodes [00:22] +1 for that [00:22] useful errors was a theme of an entire month of development we did at my last job [00:23] Because we had so many confused 3 hour pager responses where you spent 3 hours just trying to figure out WTF happened [00:24] jimbaker, SpamapS: upstart is rather critical for orchestra too, I think it's likely to be top of my list as soon as I'm not thinking about the charm store [00:24] i do wonder if niemeyer is trying to intentionally pun on wtf with the waterfall at http://wtf.labix.org/wtf/ [00:24] i'm sure he is [00:24] jimbaker: Yes :-) [00:26] potential recursive acronym, too: WTF Test Failures [00:26] fwereade: Hah, nice [00:27] niemeyer: if anyone asks, you could say that, and act all mystified -- "does WTF stand for something else as well? goodness me!" [00:27] fwereade: Totally :- [00:27] ) [00:29] biab, i'm going to hang out over at the python in the cloud meetup going on locally in boulder shortly [00:30] someone will be demoing some sort of python mgmt tool for running apps in ec2 [00:44] niemeyer: ok, I thought I was ready to merge resolve-formula-names (hm, which should be called merge-charm-names) [00:44] niemeyer: then I thought the breaking UI changes might need some documentations [00:45] niemeyer: ...then I thought "NO TIME NO TIME" [00:45] niemeyer: er, opinions? [00:45] fwereade: Hm [00:46] fwereade: One thing we definitely have to do is sending a mail to ensemble@ pointing out what is going on, how the interface is changing, and why [00:47] niemeyer: indeed -- shall I try to get that in before the merge? [00:49] fwereade: Yeah, it feels like a good idea to point to people in sync with the merge [00:49] fwereade: So that trunk users will get to know about it [00:49] fwereade: and PPA users in a bit [00:50] niemeyer: ok, I'll write something up now [00:50] niemeyer: still ensemble@lists.ubuntu.com then? [01:09] Talk done!.. wahoo.. [01:09] its very easy to slip up charm/formula [01:17] jimbaker: and the saga continues.. [01:17] hazmat: Woohay [01:17] hazmat: how was it? [01:21] fwereade: Sorry [01:21] fwereade: juju@ [01:22] fwereade: As hazmat just said, easy to slip :) [01:22] niemeyer: absolutely :) [01:22] niemeyer: I wondered if you meant it, because I could swear I signed up to juju@ but still seem to be getting all my mails from ensemble@ [01:24] fwereade: Hmm.. there's an alias between them so it continues working [01:24] fwereade: I don't think we should be getting emails from the old address, though [01:25] niemeyer: don't worry about it, I'll double-check, maybe aI got confused around the changeover [01:28] fwereade: What might be going on is that people (like me!) are still using the old address [01:30] niemeyer: ah, could be [01:33] niemeyer, the company is opdemand, they are currently demoing wordpress ;) [01:33] http://www.opdemand.com/ [01:35] they publish information from one tier to another tier [01:39] jimbaker: pvt [01:50] ouch just got dissed hard by the opscode (adam) from stage [01:50] idempotency... see me after class [02:01] hazmat: Very noble of him :-) [02:06] hazmat: The best answer to a public insult is making juju rock harder [02:08] <_mup_> juju/env-origin r374 committed by jim.baker@canonical.com [02:08] <_mup_> Fixed review points [02:15] <_mup_> juju/env-origin r375 committed by jim.baker@canonical.com [02:15] <_mup_> Merged trunk [05:16] oh, i'm glad i just tried running ./test against trunk, the failures are there, not in the merge with env-origin [05:19] we should rename the juju binary to just jj [05:20] SpamapS, please don't give anyone any ideas on that ;) [05:21] SpamapS, i assume you're seeing the same failure as here: http://wtf.labix.org/366/unittests.out.FAILED [05:23] looks like it was introduced in r365 [05:23] bcsaller, have you tried looking at trunk since your merge? [05:28] jimbaker: yeah, its a known issue, sorry. Still trying to get omega in the proper state to merge, it was missing some tests and we know how testing goes... esp. with this level of system interaction [05:28] bcsaller, ok, thanks for the update [05:28] jimbaker: it happened because lxc-lib is a prereq to omega but other thing depending on it got merged first [05:30] bcsaller, ok, makes sense [05:30] presumably one of these things corrects the ppa name too [05:31] although i would expect the bridge to the support of juju-origin in my env-origin branch would take care of that regardless [05:33] jimbaker: it will, but I think I will do that in a subsequent branch, using the ppa to get started with local dev (and fixing trunk tonight) seems fine [05:35] <_mup_> juju/env-origin r376 committed by jim.baker@canonical.com [05:35] <_mup_> Merged trunk [05:36] bcsaller, sounds like a good plan to me [05:36] cool [05:52] jimbaker: I don't like typing juju .. its all right index finger.. jj would be a nice shortened version. :) [05:52] we can just symlink it in the package. :) [05:53] SpamapS, i wonder if my typing here is canonical - i use index for j, middle for u, so it's not as bad in this case [05:54] (that's probably a misuse of canonical...) [05:54] (more like standard i guess) [05:59] fwereade, is local resolution of charms now broken? [06:00] i noticed the change to the series, but i'm seeing this on the machine agent [06:02] fwereade, so i'm seeing this, http://paste.ubuntu.com/698912/ - anyway, i guess it will have to wait until tomorrow, just using irc async here :) [06:07] SpamapS, apparently my typing is nonstandard. darn. http://en.wikipedia.org/wiki/Touch_typing [06:29] jimbaker: very nonstandard, I don't even know how you reach u with your middle finger [06:47] fwereade: one thing about this breakage.. now any version before this is completely broken because the PPA package wants local: prefixed [06:47] CharmStateNotFound: Charm 'local:hadoop-slave-1' was not found [06:48] thats not something you mentioned in your email. :-/ [07:28] <_mup_> juju/env-origin r377 committed by jim.baker@canonical.com [07:28] <_mup_> Remove tabs in rst file [09:14] hurray, all tests pass [10:36] rog: belated /cheer [10:36] :-) [10:37] my computer made the requisite sound effect when you mentioned my name [10:37] well ok, it was a sort of bleep, but close enough [10:37] rog: haha, awesome [10:49] SpamapS: hm, I hadn't considered that side effect [10:53] SpamapS: I kinda feel that we're still (just barely) in "developing, expect breakage" mode, and so it's (just barely) acceptable, if annoying [10:54] SpamapS: am I right in thinking that error shows up when you have an env running, you upgrade juju locally, and then try to issue commands to the env running the old version? [10:55] SpamapS: ...or, yes, also if you try to run any older version against the PPA [10:55] SpamapS: is my interpretation sane? [13:59] <_mup_> Bug #862415 was filed: Juju bootstrap node disappearance < https://launchpad.net/bugs/862415 > [14:03] <_mup_> Bug #862417 was filed: Cloud Foundry server charm was not found on the instance < https://launchpad.net/bugs/862417 > [14:04] <_mup_> Bug #862418 was filed: Add a way to show warning/error messages back to the user < https://launchpad.net/bugs/862418 > [14:04] <_mup_> Bug #862417 was filed: Cloud Foundry server charm was not found on the instance < https://launchpad.net/bugs/862417 > [14:06] SpamapS: whenever you're awake, let me know if you have the final juju package for oneiric :) [14:07] <_mup_> Bug #862422 was filed: Add a "block" add/remove unit hook < https://launchpad.net/bugs/862422 > [14:19] i can never remember where to create a new issue for code review... [14:37] is it standard to always create a new branch when making some changes? if i haven't done that, how can i change the branch name? [14:39] rog: depends: if I'm doing a significant chunk of work I'll start by branching, if I'm just (say) addressing a minor review point in an existing branch I'll continue the existing one [14:40] rog: there's a line between them but I find its location varies with my current levels of optimism, forgetfulness, foolishness [14:41] rog: offhand, I'm not sure how best to retroactively branch something without the process being somewhat manual [14:42] rog: you could just bzr diff --old=[revision you wanted to branch from] > somewhere [14:42] rog: bzr revert -r [that revision again] [14:42] rog: bzr commit [14:42] rog: ...and then branch from there and apply the patch [14:43] rog, and everyone else: if there's a better way I'd love to hear it :) [14:43] at the moment, i'm trying a branch and then a merge with the changes i made in the old branch [14:43] dunno if it'll work. we'll see. [14:44] rog: I think I tried something like that once, and it went wrong -- if you then revert the parent branch, and *then* merge from it again, I think it'll try to apply your subsequent unchanges [14:45] rog: ...er, if you see what I mean [14:47] fwereade: hmm, not sure i do. is that something i shouldn't do, or something i will inevitably do? [14:49] fwereade: it *seems* to have worked [14:49] except the log history is no longer linear, which might be a problem [14:49] rog: possibly I misunderstood what I did, or what you did [14:50] i did: cd $HOME/gozk; bzr branch lp:gozk my-upcoming-revision; cd my-upcoming-revision; bzr merge ../zk; bzr commit [14:50] where $HOME/gozk/zk was the place i'd been doing the edits [14:55] rog: ah, yes, that sounds fine [14:55] rog: I'd been imagining a situation where you'd made several commits already to the wrong branch [14:56] fwereade: i made commits, but hadn't pushed [14:57] rog: still sounds fine :) [14:57] cool [14:57] * fwereade crosses fingers [14:58] * rog also crosses his fingers. [15:04] bcsaller, none of the things that had lxc-lib as a pre-requisite got merged first.. they where using what was already committed to trunk [15:05] lxc-lib-clone changed the api [15:09] hazmat, yes, that's what we are seeing on wtf.labix.org right now [15:10] jimbaker, it should be okay after lxc-omega gets merged, but breaking trunk isn't [15:10] hazmat, agreed with that for sure [15:11] (invariably when trunk is broken and i do a merge, i blame my branch first. goose chase, not productive... anyway, it happens) [15:17] fwereade: yes, all older versions of juju break when they deploy because they pull from the PPA [15:17] fwereade: breaking stuff is fine, but telling us about it *well before* committing would be quite helpful. [15:18] why are we committing to trunk without running the test suite? [15:19] Every time I've merged one of my little fixes in, I merge and then run the test suite. :-P [15:19] SpamapS, fwereade, agreed. and announce it here would be nice. the other thing that bit me last night [15:20] SpamapS, jimbaker: I'm sorry, it was entirely wrong to assume anyone else had the faintest idea what I was up to :( [15:20] it never really crossed my mind that niemeyer and I had talked about it lots, but not with everyone [15:21] fwereade, no worries, just some suggestions to get everyone in the loop first. this channel has its deficiencies, but i poll it much more frequently than email ;) [15:21] (much more signal for what i immediately need to know) [15:22] jimbaker: definitely [15:22] At this point nobody can test the packages in 11.10 properly.. it only works by using juju-branch: lp:ubuntu/oneiric/juju but thats not the end of the world [15:23] The email as great.. and its the only reason I didn't go "WTF!!" right away.. I knew what was up. Its just that the scope of the breakage may not have been fully explored. Given the velocity you all are maintaining, I'm not surprised (or upset :) [15:23] s/email as/email was/ [15:24] SpamapS: so, the stuff that's currently in 11.10 is old, and therefore broken; I had the impression we were planning to slip in a last-minute update (er... tonight?) with lxc stuff, and origin stuff ...and this stuff [15:25] SpamapS: and that implies the breakage is at least somewhat temporary [15:25] SpamapS: have I misunderstood the plans? [15:26] we are planning to update again. The point of updating before then though, was to allow testing of what was done up until now. [15:27] SpamapS: indeed :( [15:27] Don't worry, I totally understand the implications and reasons behind this incompatible change. I'm only frustrated that I pushed so hard to get a somewhat new version in that is totally broken. :-/ [15:28] "old" is the revision from Monday morning btw. [15:28] SpamapS: and now you're stuck only able to test the moving target that is trunk :( [15:28] No I can test using juju-branch: [15:28] SpamapS: heh, "old" is everything before this morning :( [15:28] SpamapS: ah, good [15:29] SpamapS: which is to say, "less bad" [15:29] SpamapS: in future I will definitely make sure people know of breaking changes well in advance (if I can't avoid making them at all) [15:30] SpamapS: is there anything I can do to mitigate the pain now? [15:30] no. :-/ [15:30] Just git 'er done. :) [15:31] seriously, ignore my whining.. you all have important work to do. [15:31] yeah, but so do you, and I'm sorry to have disrupted it :( [15:32] It only means the bugs that I might find now will be found after you're done.. and you'll have more of a time crunch to fix them next week. [15:33] fwereade: please don't feel guilty in any way. You guys can't stop for every squirrel crossing the road. ;) [15:34] SpamapS: don't worry, I'm neither sobbing nor rending my clothes [15:34] SpamapS: still wish I'd done it differently, but we live and learn ;) [15:35] fwereade, please no self-flagellation, ok? ;) [15:36] jimbaker: i've just pushed a new gozk merge request. any comments or feedback welcome. [15:36] https://code.launchpad.net/~rogpeppe/gozk/update-event-interface/+merge/77560 [15:37] rog, thanks! [15:37] SpamapS: so basically all charms are broken now, right? [15:37] * robbiew notes this is why we need juju pulling from the archive at release...not a ppa :/ [15:38] I realize we need this change to allow for the store to work...which means **WE** will need to fix everyone's charm before release [15:38] not fair to expect authors to go back and do that now, imo [15:38] and apparently there's no legacy support :/ [15:40] robbiew: all charms and all juju deployments from 11.10 are broken, yes. Tracking in bug 828147 [15:40] <_mup_> Bug #828147: Ensemble branch option needs to allow for distro pkg, ppa, and source branch install < https://launchpad.net/bugs/828147 > [15:41] awesome [15:41] robbiew: there is a workaround, which is to add 'juju-branch: lp:ubuntu/oneiric/juju' to your environment config [15:42] robbiew, really hope that branch gets approved soon [15:42] in terms of env-origin [15:42] jimbaker: that change must get in [15:42] agreed [15:42] The alternative is to patch the distro version to default to pulling from the distro. I've tried that in a privately built package and it works fine, but the problem is the deployed provisioning agent then still has the distro version deploying from _PPA .. [15:43] Anyway, the best thing to do is probably to just test from the PPA.. ignore the distro package.. and try to help these guys finish off the work so we can upload "the real juju" ASAP [15:44] agreed [15:44] a hack in the distro is suboptimal [15:44] worst case.. if something goes horribly wrong and we can't do that.. we can regress the PPA to the distro version and move daily builds to a different PPA. [15:44] if env-origin works, then we can just use that set to the archive, right? [15:45] fwereade, re robbiew's point - the backwards breaking change seems to be only to change the directory structure. i understand with the juju rename there's been some drastic changes already. but we could make it easier possibly by assuming oneiric [15:45] robbiew: env-origin is intelligent, and chooses distro when your client version came from the distro [15:45] cool [15:45] Its probably going to break horribly on OS X tho. :P [15:45] robbiew, env-origin does the right thing [15:45] SpamapS, it doesn't know about os x yet [15:46] jimbaker: it shouldn't really. Serious users will probably be very explicit about their environments.yaml [15:46] SpamapS, the workaround is to set juju-origin manually [15:46] SpamapS, agreed [15:46] SpamapS, it might be something as simple as that for os x/non ubuntu clients, it basically insists that this setting be made [15:47] Actually I think it should just choose distro at that point. [15:48] SpamapS, also a reasonable choice [15:48] hmm.. something's borked with juju-branch too actually [15:49] Ahh, my AMI's are out of date and couldn't download packages. [15:52] SpamapS, jimbaker: it seems that it would be better to insist on explicit default-series *everywhere* than to special-case non-ubuntu [15:53] fwereade, certainly a valid point. being clever can surprise [15:53] SpamapS: that would mean everybody had to change their environments.yaml, though, which is maybe too much to expect [15:55] SpamapS, jimbaker: if that would be acceptable, though, it feels like the Right Thing to me [15:56] I guess the big problem we need to resolve is broken existing charms...and getting them fixed asap [15:56] the change is in...and newer charms will be written accordingly [15:57] for example...our much talked about cloudfoundry charm is now broken :/ [15:57] we need that working by release [15:57] and so on [15:57] robbiew, SpamapS: are we saying that *charms* are broken, or that *repositories* are broken? [15:57] hazmat: ping? [15:57] fwereade, but as i understand it, the charms are not themselves broken by this change, it's how we refer to them in terms of their repository structure and when deployed? [15:58] jimbaker: that's exactly what I'm fretting about [15:58] fwereade, exactly [15:58] :) [15:58] fwereade, i looked at the change in trunk. the sole change to the example charms, which should be reasonable for any other charms, is moving the files around one level [15:59] (reasonable, as in talking about other charms, that is) [15:59] jimbaker: exactly, I don't believe that any charms are themselves broken [15:59] right....sorry...you are correct [15:59] jimbaker: every repository outside the source tree is, though [15:59] now there is certainly broken code out there that manages this process [16:00] so pretty much everyone has their own script to deploy a stack of apps. no one is typing it in again and again [16:00] that's broken now [16:00] exactly...nothing we can do about that though...sed/awk to the rescue there [16:00] but a trivial fix to add in the right locator info [16:01] the only challenge is that it totally sucks when they are deployed [16:01] jimbaker: we discussed defaulting to "local:" when --repository is given, but that causes us more problems down the line [16:01] fwereade: ftr, I'm happy this change has gone in...as we need it for the Charm Collection/store thingy ;) [16:01] errors are nontransparent, and show up in debug logs [16:02] jimbaker: bad-repo errors, right? [16:03] fwereade, i forget specifics, i made a paste on this last night [16:03] jimbaker: hopefully "cs:blah/blah not found in repo https://store.juju.ubuntu.com" is reasonably clear? [16:03] let me see if i can dig it up [16:03] jimbaker: but I suspect it's not so nice if the repo has the wrog structure [16:03] fwereade, depends on where it is. if from the command line, cool [16:04] if it is in the debug-log, not so cool [16:04] way too buried. yes, i will go there. but even for me it's an extra step to ssh in to find what's happening, and i know what i'm looking for [16:05] hm, yes :( [16:05] there may be some gnashing and wailing and rending and tearing at the cheeks [16:06] jimbaker ...but wait, when are we hitting repositories except from the command line? [16:07] fwereade, need to dig up this error for you... [16:07] jimbaker: thanks [16:09] fwereade, lost it. i will have to recreate. hopefully not some dream from last night... [16:11] jimbaker: np, although from my perspective I kinda hope it *is* a dream [16:11] ;) [16:11] robbiew: the cloudfoundry charms should work w/ the PPA [16:12] SpamapS: cool, thx [16:17] jimbaker: you have reminded me of one possibility, can I get a +1 trivial on http://pastebin.ubuntu.com/699194/ please? [16:20] fwereade, looking at it now [16:20] Hey didn't we introduce a schema version or something into ZK so that clients would detect when they are trying to twiddle an incompatible ZK? [16:21] Seems like this latest formula change woudl be a good time to bump that. [16:21] fwereade, so basically this covers a bad path [16:21] jimbaker: yep, that's it [16:21] jimbaker: it should just make the error clearer when people try to deploy from an un-upgraded local repo [16:21] fwereade, well +1, i assume this will not let it get into the bad state i discussed [16:22] SpamapS, yeah, we have that bit, it would be nice to use in this case. we have the power... [16:22] jimbaker: it won't start or stop anything working, it'll just complain differently [16:22] fwereade, and i believe more importantly, complain earlier [16:22] and closer [16:22] SpamapS, jimbaker: oh, blast, I thought that was discussed but not implemented [16:23] jimbaker: indeed [16:23] fwereade, https://code.launchpad.net/~jimbaker/juju/verify-version/+merge/71559 [16:24] fwereade, don't worry, i thought i knew what you were working on too [16:24] lol [16:24] haha [16:24] mostly right, but a few missing, possibly critical bits ;) [16:27] fwereade, so if you want to make a change to VERSION = 1 in ensemble.state.topology, that sounds like a trivial we might all approve [16:27] jimbaker: was just about to suggest it :) [16:28] it complains early and close. almost all stuff goes through the topology [16:28] jimbaker: for form's sake: http://pastebin.ubuntu.com/699200/ [16:29] sounds good, the minimum requirements specified in that comment have been satisfied, so +1 ! [16:30] jimbaker: cheers :) [16:39] right, i'm off. it's an unseasonably warm and beautiful evening here. the garden calls. see you tomorrow. [16:41] rog, enjoy! [16:52] <_mup_> Bug #862415 was filed: Juju bootstrap node disappearance < https://launchpad.net/bugs/862415 > [16:53] b/win 2 [17:00] hello. [17:00] will niemeyer be here later? [17:01] Hallo! [17:02] hi! [17:03] Aram: Hey Aram [17:03] bcsaller: ping [17:03] niemeyer: hey [17:03] bcsaller: Hey! [17:04] bcsaller: I see the problem not only isn't fixed, but it's getting worse: http://wtf.labix.org/ [17:04] bcsaller: Can you please revert the change, if you can't make the tests work again? [17:04] I didn't get the final +1, my branch is ready to merge [17:05] should be in your email and I pinged kapil about it as well [17:05] bcsaller: It already has my +1 I think [17:05] bcsaller: Or is it another branch? [17:05] you said it needed one more sign off at the end and I made changes for the review and no one ok'd them [17:06] bcsaller: Yeah, from Kapil specifically [17:06] yeah [17:08] bcsaller: Did you talk to him about this already? [17:08] niemeyer: I pinged him about it this morning but haven't seen him [17:08] he's at a conference today [17:09] all the tests are passing, I can go and merge it if your ok with that niemeyer [17:09] bcsaller: Yeah, I think that's the best thing to do [17:10] bcsaller: Let's invite him for a post-review [17:11] niemeyer, the env-origin branch is ready for review [17:12] jimbaker: Cool, I'll check it out [17:12] niemeyer, thanks [17:27] <_mup_> Bug #862595 was filed: Provisioning agent and destroy-environment show NoneType not iterable on machine shutdown with Openstack < https://launchpad.net/bugs/862595 > [17:27] is there anything in place to test charms with Jenkins etc. [17:30] HarryPanda: jamespage has some preliminary work on that. [17:32] SpamapS, looks like more txaws issues there with 862595 [17:33] jimbaker: yeah.. I think that may actually be causing big problems on the provisioning agent.. it doesn't seem to want to provision new instances after that [17:34] niemeyer: http://wtf.labix.org/ is happy again [17:34] niemeyer: well, the non-ftests part anyway [17:34] SpamapS, the provisioning agent certainly doesn't expect errors. i'm not certain what it should be, but just barfing is not one of them [17:35] bcsaller, those are because of the respository changes, so that's independent [17:36] SpamapS, ok, that may be overstating it, but it is vulnerable [17:37] jimbaker: seems like whats happening here is that while the provider has shutdown the machine and changed ZK to remove it, the error has somehow caused the provider to not thing the machine is gone [17:37] jimbaker: leading to bug 861928 [17:37] <_mup_> Bug #861928: provisioning agent gets confused when machines are terminated < https://launchpad.net/bugs/861928 > [17:38] SpamapS, the periodic rescan is supposed to sync it with reality for cases like this, as i understand it, but the changes in aws api impl is presumably making it confused [17:39] jimbaker: probably because the group is still there [17:42] SpamapS, you mean the security group per machine? [17:43] jimbaker: hrm, no its not there [17:44] seems like there's some order of ops that gets confused by that NoneType iterable error. [17:46] SpamapS, as a general rule, we expect specific errors from txaws - it looks like it's not catching this TypeError, so it bubbles all the way up to the reactor loop [17:51] <_mup_> juju/env-origin r378 committed by jim.baker@canonical.com [17:51] <_mup_> Merged trunk [17:57] just had an opportunity to see the incompatible juju protocol version in action [17:58] jimbaker: hah :) [18:00] it was expected, fortunately... i think the error message could be more helpful on what to do in this case [18:03] jimbaker: so this does look like nova-api doesn't return the same expected XML after TerminateInstances [18:04] SpamapS, at the python meetup last night, i think someone mentioned that txaws is using an older version of the aws api. don't know about the truth of this [18:05] SpamapS, it may have nothing to do here, but supporting multiple apis is tough [18:06] as usual, we might want to look at boto [18:06] well in this case, comparing to boto .. boto just returns whatever list was responded with [18:06] txaws asserts that it has to be id=instancesSet [18:21] jimbaker: ping [18:21] niemeyer, hi [18:21] jimbaker: Hi [18:22] jimbaker: Please re-read points 3, 4 and 5 [18:22] jimbaker: and compare to the implementation [18:22] niemeyer, ok [18:23] jimbaker: Is there anything missing there? [18:25] niemeyer, #3 - python-txzookeeper dependency is no longer relevant; #4, it uses the original implementation; #5, there is no attempt to test deb repositories, since they are no longer supported [18:25] jimbaker: Maybe I'm just missing.. where's that: 3) Otherwise, store the version in a variable, and keep parsing [18:25] jimbaker: 4) Find the version table, and find the installed version [18:25] ? [18:26] niemeyer, ok, i'm referring to the review points. you are referring to a list from irc [18:26] jimbaker: yeah [18:26] looking at that now [18:28] niemeyer, ok, i believe what you are saying here is that 6) refers to the installed version, which was stored earlier in 3), is that correct? [18:29] 1) Grab the installed version from the "Installed:" line [18:30] 2) If this is "(none)" return "branch" [18:30] 3) Otherwise, store the version in a variable, and keep parsing [18:30] 4) Find the version table, and find the installed version [18:30] jimbaker: Is there any ambiguity here? [18:31] niemeyer, correct, there is no ambiguity. the version table has more information than i have assumed, and this parse needs to take it in account [18:31] jimbaker: Thanks. [18:35] biab [18:49] wow.. nova-api's response to TerminateInstances is *completely* different from ec2 [18:56] i'm feeling sick right now, i will be back later [18:57] http://pastebin.com/jFDQLrcQ [18:57] thats ec2's response [18:57] http://pastebin.com/ZMXwA4MY [18:57] And that is openstack [19:31] <_mup_> juju/ftests r5 committed by gustavo@niemeyer.net [19:31] <_mup_> Removing unused imports. [19:40] note that bug 862595 is actually pretty serious.. really confuses the provisioning agent. [19:40] <_mup_> Bug #862595: terminate_instances raises NoneType not iterable on machine shutdown with Openstack < https://launchpad.net/bugs/862595 > [19:41] hazmat: when you're around, if you can ack the merge proposal against txaws .. I will patch it into the Ubuntu txaws [19:50] bcsaller: free for a catch up call? [19:54] robbiew: I was just sitting down to lunch, can we push it a little bit? [19:55] bcsaller: absolutely not! [19:55] lol [19:55] sure [19:55] thanks [20:15] robbiew: free when you are [20:15] <_mup_> juju/ftests r6 committed by gustavo@niemeyer.net [20:15] <_mup_> Reverse the order of revisions and link them to Launchpad. [20:23] bcsaller: cool...need 5min [20:27] bcsaller: g+, phone, skype, mumble...pick yer poison :) [20:28] robbiew: sent g+ invite [20:28] bcsaller: cool...one sec [21:05] <_mup_> juju/ftests r7 committed by gustavo@niemeyer.net [21:05] <_mup_> Move environments.yaml creation into the ec2 suite, and [21:05] <_mup_> make it use trunk rather than packages, so that the code [21:05] <_mup_> has better chances of being in sync. Hopefully this fix [21:05] <_mup_> the current breakage. [21:12] <_mup_> juju/trunk r370 committed by gustavo@niemeyer.net [21:12] <_mup_> Rename readme.txt to README since we already have one of those. [trivial] [21:12] <_mup_> But really, this is just bumping the revno for an ftest cycle. :-) [21:16] * hazmat catches up [21:19] Hah.. missed the URLs [21:19] hazmat: YO! [21:20] niemeyer, greetings hows your conference? [21:20]