[03:26] <_mup_> txzookeeper/session-and-conn-fail r44 committed by kapil.foss@gmail.com [03:26] <_mup_> watch delivery tests and some additional session expire tests [11:27] hi [11:27] I've got some problems with juju and the local provider [11:28] I can't deploy more than a single service [11:28] is this a bug ? [12:08] hi beber, sorry I missed you, I was having lunch [12:08] it may be a bug; would you describe what you're trying to do please? [12:08] hi [12:09] ok, I'm just trying to use juju with the local provider [12:09] I'm using VirtualBox as a test machine (with Oneiric) [12:09] Once juju is installed, I bootstrap the environment [12:09] and deploy the mysql charm [12:10] everything goes well, the mysql unit is started [12:10] but then, when I want to deploy another charm or add a mysql unit, nothing happens [12:11] nothing at all? [12:11] (despite juju tells me "INFO 'deploy' command finished successfully" [12:11] I use watch -n1 "ps afx | tail -n 45" [12:11] ah ok, so when you "juju deploy wordpress" it claims to deploy but nothing happens [12:11] exactly [12:11] and similarly for "juju add-unit mysql"? [12:12] yes [12:13] beber, there are a couple of logfiles that might be helpful [12:13] there should be a data-dir defined in your environments.yaml [12:13] could you tell me which one to look at ? [12:13] yes [12:14] ah, hmm, just a sec, I have an alternatve "what's-going-on" command [12:14] pgrep lxc| head -1| xargs watch pstree -alU [12:15] but the interesting logfiles would be [12:15] data-dir/units/master-customize.log [12:15] data-dir/machine-agent.log [12:15] ...and the output of: [12:15] /usr/lib/juju/juju/misc/devel-tools/juju-inspect-local-provider [12:15] would also be helpful [12:16] beber, if you pastebin those over I will gladly take a look [12:17] sorry, wifi problem... [12:17] beber_, np, I'll repaste it privately to avoid spam ;) [13:34] good mroning [13:34] morning [14:19] FYI, today I am going to switch the build recipe to use the packaging from Ubuntu (for natty -> precise) ... Maverick and Lucid had to have changes applied [15:58] fwereade, what if we used mixin instead of colo? to me, colocation sounds much more like placement as an equal on the same machine. which is important, just the other story :) [15:59] jimbaker, that's quite nice [15:59] in any event, programming has a whole set of words we can choose from with these sorts of ideas [16:00] jimbaker, I spent the afternoon writing an email trying to define a minimal set of changes to get this story up, and I started using the word "buff", which I've grown quite fond of [16:00] buff ;) ? [16:00] it sounds magicy and geeky and has about the right meaning ;p [16:00] as in waxing something? [16:00] nah, as in games [16:01] casting a spell on something to give it more strength or speed or whatever [16:02] i see, this is very jargony however (never heard of that usage before), but it's there on http://www.urbandictionary.com/define.php?term=buff [16:02] I have a theory that it's an immediately comprehensible name to a good proportion of our target demographic, but, er, I'm 0 for 1 so fr :/ [16:03] fwereade, what if we used something like blend? [16:03] or maybe we can find words from potion making [16:04] jimbaker, my quibble with that is that mixin/blend implies a two-way relationship, which is not necessarily applicable [16:04] I also considered "aura" as a semi-appropriate magicy word, but it didn't seem to work so well [16:04] fwereade, actually that's the good thing about mixin, it's not 2 way at all [16:05] jimbaker, in theory :) [16:05] but I do take your point [16:05] well, again from its usage in programming, that's the case. but i may be the less target. i have never played a MMORPG [16:06] jimbaker, you're not missing all that much (says the man who played WoW for 4 years ;)) [16:07] fwereade, reality consumes enough of my time it seems [16:08] jimbaker: yeah, RL is OK, but the surrounding of most major cities are totally overrun with farmers [16:08] * fwereade shamelessly steals a joke from somewhere he can't remember [16:09] :) [16:10] fwereade, so mixin sounds good, and if we can find a good charm-oriented synonym that connotes that little extra special (pixie dust, unicorn hair, powdered dragon bone), that would be nice [16:13] jimbaker, sounds good :) [17:02] <_mup_> txzookeeper/session-and-conn-fail r45 committed by kapil.foss@gmail.com [17:02] <_mup_> make the proxy easier to use as for blackholing communications, and verify session expiration with event and exception [17:50] * hazmat ponders failure [17:53] hazmat, sometimes we must fail before we can succeed ;) [17:53] i believe there are successories to consider too [17:56] failure is the only teacher really [17:57] indeed its hard to model/test failure without the experiencing it [17:57] i guess the team meeting got scrapped [17:57] speaking of failure.. I have been failing at reading email the last 3 days [17:57] * SpamapS implements more auto-labelling for sup [17:57] I thought the meeting was punted to next week? [17:57] SpamapS: filters...filters...filters [17:58] that's my understanding too [17:58] re meeting [17:58] cool [17:58] add-buff ;-) [17:58] robbiew: yeah, I'm finally giving in and implementing some [18:02] in my mind, 'juju add-mixin mysql logging' is not as obscure as 'juju add-buff mysql logging', but maybe i'll learn to like the obscurity [18:03] ** huge rocks fall from the sky and kill everyone. [18:03] fwereade: thank you for the LOLs [18:18] <_mup_> txzookeeper/session-and-conn-fail r46 committed by kapil.foss@gmail.com [18:18] <_mup_> extant watches recieve errors on session expiration [18:22] uh oh... exceptions.SystemError: error return without exception set [18:23] bindings bug [18:38] <_mup_> txzookeeper/session-and-conn-fail r47 committed by kapil.foss@gmail.com [18:38] <_mup_> capture a test case that exposes a bug in the libzk python bindings [18:39] gl [18:43] wrong window, sorry [18:47] no worries [18:47] * hazmat debates the value of meta programming error handling [18:48] generally not a good idea, but for a retry facade it seems appropriate [19:44] hazmat: I ran into a guy at ODS who said he had a lot of problems with libzk [19:45] hazmat: said he had developed a pure python ZK library because of it [19:45] SpamapS, yeah.. the error handling is delciate, and without the twisted bindings, using libzk is painful imo, but in general its been pretty solid as of 3.3.3.. i contributed a few patches/bug reports upstream when we were first getting started [19:47] SpamapS, most of it the issue is actually not the python zk binding, though there are some, but just understanding libzk itself.. i'd be curious to look at an alternative py lib though [19:48] SpamapS, a few weeks ago i started another one zk python wrapper ( still built on py libzk) using a coroutine greenlet approach.. still its infancy though.. [19:48] ^in [19:52] * SpamapS imagines hazmat surrounded by bubbling flasks of liquid over bunsen burners and tubes [19:53] SpamapS, at the moment its hp touchpads and hard drives for a nas ;-) [19:57] I need to bite the bullet and buy an SSD [19:57] Keep debating with myself about what size and whether to get two or one SSD and one honking big rotational drive. :-P [20:02] SpamapS, i'm planning on waiting for the new ocz onyx and samsung 830s, should be out at the start of nov. [20:02] I don't really do the "wait for the best" thing [20:02] I do the "whatever costs me the least amount of time" thing :) [20:03] Right now 5400rpm is costing me time.. so I need an SSD now. :) [20:49] SpamapS, talk about breaking backwards compatiblity ;-) [20:53] hazmat: which thing? [20:53] SpamapS, the commit diff stuff [20:53] oh, well we can turn autocommit on for the first release. ;) [20:54] And its selective backward incompatible.. you can turn on the "old mode" if thats what your scripts expect. ;) [20:56] hazmat: we can also just punt that off to a wrapper if we have import/export [20:56] SpamapS, why is this more repeatable? [20:57] vs. just import/export [20:57] hazmat: because you get a single thing, in VCS, that is the exact way to repeat what you have [20:57] If you've had an env for 2 years, and youw ant to repeat, you don't want to repeat *every* deploy, add-relation, add-unit, remove-unit .. ;) [20:57] so more of an oplog [20:57] the thing in vcs is the exported env [20:57] vs. just load this graph [20:57] I think we're agreeing [20:58] give me exports and imports and I can implement this w/o juju's help [20:58] oplog would be a disaster. I want a snapshot. :) [21:00] yeah.. if your building it on the graph, its not clear to me what the extra value is.. but i think my perspective is long, given the 2 year running env, with import/export, you just load up the export and your done. the distinction here is being able to verify the evolution of the system, [21:00] so effectively a snapshot audit log [21:00] It could be done simply with user discipline [21:01] but I like the idea of being able to edit the local copy with the same commands you would use to edit the live copy [21:01] hmm but all of the ops are effectively standalone transactions, ie. its not atomic [21:01] Yeah if one of them fails I understand, you can't back them out [21:01] --dry-run to the rescue? ;) [21:02] yeah.. probably not, dry-run is effectively print the dump ;-) [21:02] with the import.. [21:02] you'd need a way to tell the user what you're going to do to the env [21:03] but actually understanding what its doing to the units is non starter unfortunately.. hooks are binaries [21:03] like, I'm going to destroy service X, and create a new service called Xasdf... etc [21:03] you can see what its doing to the env, but what its doing to the machines is a different matter [21:03] yeah thats more of an operational issue [21:03] if stuff fails.. you're going to have to resolve that yourself [21:04] But what the user needs to see is the *diff* [21:04] what is this import going to do to my environment? [21:04] With single commands.. you know.. because you're running them. ;) [21:06] Puppet goes through the same problem. --dry-run tells you its going to edit file X and put value Y in it.. but that may still fail for some reason [21:06] hazmat: anyway, export/import seems the key to repeatability [21:07] Ok well I've muddied the waters enough for today. Back to syncs and merges. :-p [21:10] <_mup_> txzookeeper/session-and-conn-fail r48 committed by kapil.foss@gmail.com [21:10] <_mup_> a zookeeper client facade that transparently retries on various non fatal connection errors [21:11] SpamapS, but the import itself is the diff [21:12] i'd rather it just bail before attempting to modify anything existing in the env [21:12] and just add a prefix op [21:12] for importing it back into a running env that may have those existing services [21:13] perhaps the delta application is useful and we can grow that, and a diff op against that [21:16] * hazmat goes back to pondering failures [21:27] argh.. this is tricky [21:36] <_mup_> txzookeeper/session-and-conn-fail r49 committed by kapil.foss@gmail.com [21:36] <_mup_> retry wrapper for watch methods, run the full client test suite against the retry facade via test subclass, disable white box tests [21:41] bcsaller, sorry i'm just re-reviewing statusd. would it be possible to address my review points? it does look like you have fixed things, but obviously a doublecheck would be nice [21:42] the more important thing: watch_status does not sufficiently watch the changes in the environment with respect to expose services and opened ports [21:42] jimbaker: I'll iterate in the proposal, thanks [21:42] these are not in the topology node [21:44] bcsaller, you probably should take advantage of the provisioning agent here. you don't want to redo the watch structure for expose. trust me on this ;) [21:49] bcsaller, this is actually a good requirement for the refactoring in bug 873108; you should be able to use the observer capabilities to register an interest in these changes. right now, they are just there to support testing, and support just one observer. multiple observers might be the right solution here [21:49] <_mup_> Bug #873108: Move firewall mgmt support in provisioning agent into a separate class < https://launchpad.net/bugs/873108 > [21:50] jimbaker: thanks, looking into it [22:56] bcsaller, the other thing to consider is the impact of https://code.launchpad.net/~fwereade/juju/dynamic-unit-state/+merge/79560, this will add more ways for the status to change [22:57] jimbaker: I'm thinking about the idea of us to chase these down, vs these somehow triggering a status change (touching /status to trigger the watch) [22:58] bcsaller, agent status is an ephemeral node, but its structure is not one easy to watch without recursive watches [22:59] bcsaller, but definitely the expose refactoring can do this triggering, via the observer mechanism [23:01] bcsaller, so agent status will definitely require more thought. this might be a good thing to point on its review, my first impression was that fwereade's branch was too big in scope [23:17] woot it works [23:18] <_mup_> txzookeeper/session-and-conn-fail r50 committed by kapil.foss@gmail.com [23:18] <_mup_> get_children_and_watch test with transparent retry on connection lost [23:18] hah.. wow.. I've been running my blog on 11.04 and now 11.10 for 8 months.. just now realized there's a massive incompatibility between wordpress 3.0.5 and the jquery version that natty and oneiric have [23:19] Just figured my drizzle mods were causing the problems [23:33] <_mup_> txzookeeper/session-and-conn-fail r51 committed by kapil.foss@gmail.com [23:33] <_mup_> additional transparent retry tests with watchers, remove bad session test based on erroneous upstream faq entry. [23:42] <_mup_> txzookeeper/session-and-conn-fail r52 committed by kapil.foss@gmail.com [23:42] <_mup_> remove management of the connected attribute on clients from error handler, libzk is going to be transparently reconnecting under the hood, also supports retry much better