[00:39] niemeyer: who do we need to poke to get a new release of txaws btw? I'd like to push it into oneiric soon [00:44] niemeyer: I know you've told me before but I keep forgetting [01:37] SpamapS: I know jkakar was one of the core devs [01:37] SpamapS: But looking at the logs today it looks like the Landscape guys have been doing quite some work on it lately [01:37] SpamapS: Probably as a side effect of Cloud Deck [01:39] niemeyer: oh i meant to say [01:40] i was wondering after the demo at UDS, whether ensemble could replace the 'ec2' script in lp:launchpad [01:40] which fires off instances to test lp etc [01:49] poolie: Oh, that sounds interesting for sure [01:50] poolie: We could put each of the services which compose Launchpad in their own formulas [01:51] right [05:26] <_mup_> Bug #788950 was filed: Getting Started Documention is missing dependancies < https://launchpad.net/bugs/788950 > [08:46] <_mup_> Bug #788992 was filed: example formulas refer to providing the hostname in ensemble itself < https://launchpad.net/bugs/788992 > [13:39] Aw.. will have to bump the txaws version to 0.0.2bzr [13:39] otherwise the one in Ubuntu takes precedence [14:46] Hmmm [15:05] <_mup_> ensemble/trunk r36 committed by gustavo@niemeyer.net [15:05] <_mup_> Minor version tweaks preparing for daily build. [trivial] [15:15] I thought txzookeeper would be the easiest and I'm stumbling upon it repeatedly. :-/ [15:20] <_mup_> ensemble/trunk r37 committed by gustavo@niemeyer.net [15:20] <_mup_> Tweaked version extraction from __init__ to avoid build time deps. [trivial] [15:28] Victory, apparently [15:31] niemeyer, cool [15:47] Yay, it worked [15:47] hazmat: Morning [15:48] niemeyer, g'morning [15:49] So is ensemble itself all that is missing? [15:49] * niemeyer checks [15:51] Alright.. one more [16:04] hazmat, SpamapS, jimbaker: Unless there's anyone against it, I'll bump the version number of ensemble to 0.5, as it reflects better the project status than our current version [16:05] niemeyer, sounds good [16:05] We should be more diligent about bumping that next to our milestones [16:05] (at least) [16:08] <_mup_> ensemble/trunk r236 committed by gustavo@niemeyer.net [16:08] <_mup_> Version tweaks preparing for daily builds. [16:15] hazmat: thanks for your comment .. so I understand now changed always gets fired after joined. Does Ensemble wait for ALL joined hooks to finish, to start running changed, or is this order only enforced per node? [16:15] kim0, per node [16:15] got it [16:18] <_mup_> ensemble/trunk r237 committed by gustavo@niemeyer.net [16:18] <_mup_> Merged packaging branch by Clint. [r=niemeyer] [16:18] <_mup_> This improves the packaging further. [16:18] SpamapS: ^ [16:21] <_mup_> ensemble/trunk r238 committed by gustavo@niemeyer.net [16:21] <_mup_> Bump package standards version to 3.9.1. [16:49] SpamapS: Do we still need those packages for Lucid which are in the Ensemble PPA? [16:51] niemeyer: ew [16:51] niemeyer: its almost *never* a good idea to have the debian dir in your trunk [16:51] niemeyer: absolutely you need lucid! [16:51] 99% of all server deployments are LTS [16:51] including cloud. :) [16:52] SpamapS: almost! :) [16:53] SpamapS: We can easily take it out, but for now we (the Ensemble team, including you) are the maintainers, and this will make things simpler. [16:53] niemeyer: it will make things simpler until it goes into Oneiric. After that it complicates things. [16:53] SpamapS: Sounds good.. when it stops being simpler we can change it [16:54] niemeyer: because having debian/ in the orig tarball means either a) having a native package, or b) having to remove it from the orig tarball before upload. :-/ [16:54] SpamapS: I dig that [16:55] SpamapS: No worries really.. we take it out when it stops being convenient [16:55] Yeah sounds good [16:55] did I see auto resolution land? [16:57] SpamapS: Kind of.. it was a spike [16:58] SpamapS: We need to polish the concept further now, while we work on the repository [16:58] yeah I figure its sort of going to be uninteresting until multiple repositories are available [16:58] SpamapS: Right.. and it's tricky business as well.. there are several edge cases and we don't want to get this wrong [16:59] the biggest one I am unsure about is when a requires is already satisfied in your environment. [16:59] SpamapS: Once we have the repo server working, we can start gradually making the feature work, always falling back to manual action rather than uncertain results [16:59] SpamapS: Exactly.. that's an important one for us to figure [17:00] SpamapS: The problem as you say is that both options sound totally reasonable depending on the situation [17:01] As an admin I'd want it to ask me in that case. "You already have a mysql server, do you want to deploy a new one or relate this service to it?" type of question." [17:03] SpamapS: That sounds like a good approach [17:04] The PPA is complete! [17:04] *AND*, auto building [17:04] I don't know if it _works_, though.. but that's a separate problem. ;-) [17:05] https://code.launchpad.net/~ensemble/+archive/ppa [17:09] Guys, I'll be off this afternoon [17:10] and leaving for lunch now [17:10] \o/ [17:10] hoo-ray for daily build PP-A [17:10] meh.. too much caffeine [17:11] SpamapS: Ah, phew.. for a moment I thought you were happy to get rid of me for a while. ;-D [17:11] Lunch! Back in a bit to pack.. :-) [17:47] niemeyer: got a sec? [17:47] bcsaller: Yo [17:47] bcsaller: Good timing [17:47] re point [5] in the last review, it's a keyerror around a zipfile.read call [17:47] bcsaller: Just back.. I'll be off this afternoon to visit a friend's farm, but I have a moment now [17:48] bcsaller: Yeah [17:48] the alternative is to call getinfo(name) first which also raises a keyerror [17:48] is the one really better than the other in this case? [17:48] bcsaller: No, agreed, that'd be the same [17:48] bcsaller: Does it have any hasinfo(name) or similar? [17:48] trapping keyerror is used in the same file for the metadata.yaml as well [17:49] getinfo(name) or namelist() and then check the list [17:49] namelist doesn't raise, but I don't think it makes any more sense [17:50] bcsaller: The problem with KeyError is that tons of things raise KeyError in Python, and by catching it we may very easily be hiding something pretending we know what's going on when we don't [17:51] agreed, but it traps a single line with logical class of error documented and associated with that error condition [17:52] bcsaller: Traps a single line? [17:52] try: [17:52] content = zf.read("config.yaml") [17:52] bcsaller: main() is a single line as well ;-) [17:53] bcsaller: You see what I mean? [17:53] yeah :) [17:53] bcsaller: Go through open and read and see how many dictionary accesses are done there [17:53] how about 'it traps a single call into a stdlib method' [17:54] same issue, but it seems to scope the possible outcomes [17:54] bcsaller: I don't understand what distinction you're making thre [17:54] there [17:54] fair enough, just not sure what to do about it [17:55] bcsaller: Well, most importantly I'd like to get the point across :-) [17:55] bcsaller: So that's already a win :) [17:56] bcsaller: Now, for the solution, it feels like "config.yaml" in zf.namelist(): could be reasonable.. what do you think? [17:57] looks like it does cache that info, so it shouldn't be too expensive to check it that way [18:08] Hmmm.. interesting situation arising.. [18:08] So mediawiki can use master and slave dbs [18:08] But it really has to wait for the master/slave relationship to be established before it can use the slave [18:15] and the slaves start hook would want access to the relationdata of the master to check for a flag but doesn't have a relation context [18:16] well, you can still poll in the relation hook I guess and just fail until the flag is present, but setting that flag in the master might still be an issue [18:18] I think its just the order of operations that I'm using. [18:18] blast.. need more time.. so much to do [18:18] something I think we can all relate to :) [18:22] Going a bit cross eyed getting the mediawiki + mysql master + mysql slave thing working [18:22] I'd swear the mysql formula's modified hook is being executed twice in a row. [18:22] which breaks things because it alters the password for the user [18:27] Alright, I have to head off now.. have a good wekend, and see you on Monday! [18:27] later [18:29] SpamapS, it is being called twice in a row, once after join, once after a remote change.. ie. there is always one spurious change hook execution [18:29] SpamapS, for the master / slave you have a peer relation? [18:29] OOOHHH [18:29] no [18:29] its a requires/provides [18:29] ah.. i setup the mongodb one that way.. a replica set as a peer relation [18:29] since it is one way [18:29] either way works [18:30] peer didn't work for me because it was unclear how to relate to just the writable DB [18:30] Ok the "yes it is executing twice" thing is whats getting me. [18:30] doh [18:30] ok I have to run.. seriously late [18:30] hazmat: thanks for the heads up [18:30] SpamapS, np [18:30] re peer just the fallback, failover to me seems a little logically cleaner with a peer. [18:31] hazmat: the mysql formula in principia trunk right now (I think moved to lp:principia-tools now) has most of what I've done.. a few things haven't been committed yet tho [18:31] SpamapS, i don't get the writable db part, you mean selecting whose the master? [18:31] hazmat: promoting mysql slaves to masters is anything but clean [18:31] you need to set things up for master/master from the beginning [18:32] and then you're talking about rings.. and expanding them.. no, its not simple [18:32] its not undoable [18:32] but master/slave is super simple