[09:19] hi all === rogpeppe is now known as rog [09:56] koolhead17: hi [09:56] hi rog [13:16] Good morning charmers and jujuers [13:17] hi niemeyer === med_out is now known as medberry [13:29] hey gustavo! [13:32] koolhead17, rog: Yo [13:33] niemeyer: the gozk server-starting code is working, BTW. i'm just making the test code use it. [13:43] rog: Woohay! === niemeyer changed the topic of #juju to: http://j.mp/juju-eureka | http://juju.ubuntu.com/docs | http://afgen.com/juju.html | http://j.mp/irclog === niemeyer changed the topic of #juju to: http://j.mp/juju-eureka http://j.mp/juju-docs http://afgen.com/juju.html http://j.mp/irclog [13:46] things are always easier when you're adapting some other code. for the difficult bits you do the same and blame the other code; for the rest you can simplify according to taste. [13:46] rog: :-) [13:49] niemeyer: BTW in gocheck, is it ok if C.Log is called concurrently? [13:51] rog: It is [13:51] rog: I actually intend to support parallel tests as well [13:52] rog: Well.. hmm.. I'm not entirely sure about that right now [13:52] rog: It can be called concurrently across multiple tests, but I don't recall if it's atomic, which is likely your actual question [13:53] i'd just come to the opposite conclusion, yeah [13:53] i wanted to use it for the logging output of the server. [13:53] rather than sending to the rather obscure stdout.txt [13:54] rog: I've used it that way often.. there's already a trivial logger wrapper in the suite [13:54] rog: Hmm.. maybe not in that one [13:54] rog: Hold on [13:56] rog: http://paste.ubuntu.com/695648/ [13:56] rog: I use this in a few suites already [13:56] rog: E.g. mgo.SetLogger((*cLogger)(c)) [13:57] erm, that doesn't help the atomicity requirement [13:57] AFAICS [13:57] rog: Sure.. this should be done within gocheck [13:58] rog: But that's a red herring right now [13:58] rog: Nothing will explode if lines are logged concurrently [13:58] it might, because bytes.Buffer won't like it [13:58] rog: Heh [13:59] rog: Just move on.. I'll address this in gocheck later [13:59] ok, i'll put a lock outside [13:59] rog: Man.. ignore the problem until you have it.. :) [14:00] rog: gocheck can easily be fixed [14:00] * rog prefers to fix concurrency issues before they heisenbug [14:01] but actually we should be ok with GOMAXPROCS=1 [14:01] rog: I'm telling you I'll fix the problem in gocheck. You don't have a problem. [14:02] ok, cool [14:22] hazmat: Just +1d machine-with-type, with a couple of trivial suggestions.. let me know what you think please [14:25] jimbaker: ping [14:28] * rog has some failing tests now, hurray! [14:34] rog: Hah :-) [14:34] rog: Good stuff [14:44] niemeyer: the test in TestRetryChangeFailsSetting is failing because RetryChange is returning a nil error. why should RetryChange be failing here? [14:44] (not yet familiar with zk retry semantics i'm afraid [14:44] rog: Have you changed it? [14:45] rog: The documentation for the function is pretty good,b tw [14:50] no, i haven't changed it AFAIK. and i just noticed the read-only thing going on above. hmm. [14:51] (that's one of only two tests that are failing now) [14:52] rog: Yeah, but I suspect this is related to your changes in the error handling [14:52] rog: Have you introduce those already? [14:52] rog: How is the test failing? [14:55] i think you're right. RetryChanges is succeeding inappropriately [14:57] the only other test that fails is TestExists, where Exists of "/zookeeper" is returning 0 children, not 1 as expected. [14:57] niemeyer, hi [14:57] hello [14:59] avoine, jimbaker: Heys! [14:59] rog: That could mean a distinction in the zk versions.. perhaps [15:00] rog: /zookeeper is a default node, so it's not a great assertion [15:00] jimbaker: Hey! [15:00] jimbaker: How're things going there? [15:00] correct about /zookeeper, it's a very modest ping [15:01] niemeyer, my daughter just turned 11, which is very cool [15:01] ok [15:02] rog, if you are looking for a node that says something about juju, /topology or /initialized is probably what you want [15:03] jimbaker: That's very cool indeed [15:03] jimbaker: No, ECONTEXT :) [15:03] jimbaker: He's working on gozk [15:03] ah, one level down [15:07] ah, i did change RetryChange quite a bit, must have got my code transformation wrong... [15:09] rog: Hmm.. [15:10] rog: I hope you're planning to provide several independent merge proposals.. [15:10] niemeyer: gotcha! [15:11] niemeyer: i'm hoping that it's fairly obvious [15:11] rog: Yeah, but several obvious things make up for a gigantic branch and several bugs [15:11] yeah, i should probably separate out the server stuff [15:12] but i couldn't test the other stuff until i'd put it in... [15:12] rog: I wasn't expecting the things we talked about to break RetryChange, for instance [15:12] the error stuff changed things quite a bit [15:12] for instance, error comparison became simpler [15:12] rog: Still, it sounds relatively trivial.. [15:12] which allowed RetryChanges to become simpler [15:13] rog: Cool.. simpler is great [15:14] 6 lines shorter [15:14] (and easier to understand, i'd contend, but YMMV :-]) [15:15] anyway, i've found the bug [15:15] (i think!) [15:17] and broken! [15:17] * niemeyer hides [15:18] jimbaker: So, what have you been working on? [15:18] return nil -> return err [15:18] that was the bug [15:18] rog: Was joking :) [15:18] anyway, the only failing test now is the number of nodes under /zookeeper [15:18] :-) [15:18] have you got an alternative suggestion for a test? [15:19] rog: I'm pretty certain this is bad expectation from the test [15:19] rog: Let's set up a node of our own [15:19] yeah [15:19] i was gonna suggest that [15:19] rog: Create /node and /node/subnode [15:19] rog: and check that instead [15:19] niemeyer, i've been looking at the lxc work and trying to get that to work for me so i can review some of the branches in queue. i've also been finalizing env-origin. i really need to get the unittests fix in as well [15:20] jimbaker: Ok, great.. we don't have a lot of time as you know, so please leave the lxc stuff for hazmat and bcsaller and focus on the things on your plate at the moment [15:20] niemeyer, ok [15:20] niemeyer: to be honest, NumChildren is checked elsewhere. we could just remove that assert from the TestExists test and all would be ok. [15:21] rog: Works too [15:24] passes all tests. woo. time for lunch. [15:25] * hazmat wakes up and grabs a coffee and finishes review on fwereade series branch [15:25] hazmat: Morning! [15:25] jimbaker, if you could the fix help output for set config to be a onliner when listing commands that would be helpful [15:26] its currently the only one that spews on juju --help.. if you switch it to a the other help value it only shows on juju set --help [15:26] hazmat, ok [15:27] jimbaker, i'm curious what issues you had with the lxc stuff though, did you get a traceback? [15:27] cheers hazmat :) [15:27] the tests for it should run if you have libvirt-bin and lxc running [15:27] s/running/installed [15:29] hazmat, sure, one moment [15:30] Lunch here.. biab [15:36] hazmat, here's the result from running one test - http://pastebin.ubuntu.com/695695/ [15:37] hazmat, originally i was trying this against bcsaller's branch for using apt-cacher-ng, but i then decided to step back and verify against trunk. i am running oneiric, beta 2 [15:38] to my eye, this sort of spew is basically a simple setup problem [15:38] hazmat: re [3], good point [15:39] hazmat: I guess it's not too much work to add a new series codename to the list every 6 months :) [15:39] hazmat: I remember that from the first review now, sorry I missed it before [15:39] hazmat, also are there any docs on working w/ lxc? [15:45] hazmat: it does seem to me that the right point to validate the series is at environment load time, though, given that it's an environment property [15:47] hazmat: ...and I've suddenly changed my mind, mainly because I like using made-up series names in tests [15:49] hazmat: I think it's a matter of ensuring we wrap the errors nicely, to make it clear what the problem is, rather than restricting the acceptable strings and having to change them ourselves (even if it is only every 6 months) [15:51] niemeyer: i've sent the branch to you for review... i think. still getting to grips with the bzr/lp stuff. [15:51] jimbaker: it looks like its trying to install the distro package of juju. I don't think its in the distro yet, right? That should be set to ppa for now I expect [15:53] bcsaller, what do we need to do to config then for this? i'm just running the test against trunk [15:54] jimbaker: juju/lib/lxc/tests/test_lxc.py s/distro/ppa should only come up one place [15:56] fwereade, that sounds good, but its not clear how for example orchestra could validate that value [15:57] fwereade, for lxc the error from incorrect value is coming from a script that's also setting up the container, and is pretty hard to distinguish apriori from other installation errors [15:57] hazmat: well, I think it comes down to whether or not cobbler has images with the appropriate codename available [15:57] hazmat: and that's something we can check [15:57] hazmat: (er, in theory, we don't do anything like that yet: it's oneiric or nothing) [15:58] fwereade, i guess the question can we unambigously report such an error, or do we need to provide a list [15:59] bcsaller, does this mean that lxc testing currently has a dependency on juju being installed as a ppa? ie what is tested in the container is something outside of the branch and thus similar to what we see when executing on say ec2? [15:59] hazmat: I think we can, if nothing else because the supported-series list is a property of the cobbler setup [16:00] jimbaker: there is an origin policy like what is being worked on elsewhere. distro, ppa and branch, where does the container gets its version of juju? it defaults to distro on trunk but the package isn't in the distro (though it should be after today?) [16:01] that was the only failure there though [16:01] hazmat: us having a list including (say) puissant doesn't help if the adminstrator hasn't made images available [16:01] honestly the lxc-library branch does a bit more in the container and is more worth checking out than whats in trunk wrt lxc [16:01] hazmat: so I actually think we have to go by what we can get from the environment [16:02] bcsaller, ok, i just wanted to follow up on what i was seeing. it now makes perfect sense and is even related to what i'm trying to finish up in terms of juju-origin [16:02] (env-origin branch) [16:03] jimbaker: yeah, the lxc stuff supports that in a very similar way to whats happening elsewhere. Honestly I hope we can just have cloudinit run the juju-create script as root in the container [16:03] bcsaller, seems like the right place to do it [16:04] jimbaker: its written in such a way that it sources its config from /etc/juju/juju.conf which can be written by any of the providers [16:04] and then we'd have common image building code [16:15] fwereade, good point, sounds good [16:16] hazmat: somewhat academic until we can select series in orchestra at all, ofc :) [16:40] hazmat, bcsaller - take a look at this lp:~jimbaker/juju/set-help-trivial - i tried to preserve the original text + some copy editing. but i think it could still stand some improvements. for example, we probably want concrete examples (or none at all) [16:41] hazmat, bcsaller, in particular, it distinguishes between the longer help message for doing juju set --help, vs the summary help with juju --help [16:43] jimbaker: agree that we need a better pattern for this [16:43] also the spacing is currently inconsistent. probably best to use textwrap to control, but manually. this is only necessary if we want a list of examples, otherwise we don't need RawDescriptionHelpFormatter, which is all-or-nothing for the subparser [16:44] bcsaller, agreed on that! [16:53] Gooooood morning juju team [16:53] Done yet? ;) [16:56] hazmat: is bug 829880 still open? I thought we'd worked around it somehow. [16:56] <_mup_> Bug #829880: object store doesn't like key with '/' < https://launchpad.net/bugs/829880 > [17:12] SpamapS, that should be closed [17:13] SpamapS, its not a bug against ensemble anymore, its still valid for openstack afaik [17:13] hazmat: right so Fix Released or Invalid ? [17:14] SpamapS, just marked fixed release against juju, for the ensemble package... [17:15] ./ [17:19] rog: ping [17:21] rog: Review for gozk delivered [17:21] biab [17:22] SpamapS: hello [17:24] niemeyer: where do i find your review? [17:24] hazmat, niemeyer - i would like to verify that we want the user to be able to specify an arbitrary PPA? just wanted to understand comments re the logic being preferred in the trunk version of cloudinit [17:26] niemeyer: ah, slow mail fetch [17:26] thanks [17:34] koolhead17: hey [17:35] koolhead17: I noticed you applied for charmers.. but you haven't submitted any charms. [17:36] SpamapS: i did one dotproject [17:37] but i don`t think its of much use as its not getting done from the oneiric repo [17:37] koolhead17: You need to submit a 'new-charm' bug with it so we can review it. :) [17:38] SpamapS: yes sir!! :D [17:38] SpamapS: https://bugs.launchpad.net/debian/+source/dbconfig-common/+bug/807038 [17:39] <_mup_> Bug #807038: dbconfig-common fails to preseed phpmyadmin on natty/lucid

< https://launchpad.net/bugs/807038 > [17:39] i want some one to shpw little love to this :D [17:39] *show [17:40] koolhead17: yeah, dbconfig-common is a little bit weird.. :-/ [17:40] SpamapS: that is one reason am skipping our repository :D [17:41] i want some bugs which does not require dbconfig-common [17:41] *charms in wishlist [17:46] koolhead17: huh? you can just write your own config file, you don't have to use dbconfig-common's values [17:47] SpamapS: ooh!! i was dumb all this while then. will dig up on it later once am home. thanks for that. :) [17:48] koolhead17: your dotproject charm looks cool tho [17:49] * koolhead17 pats himself for few sec :D [17:49] jimbaker: That's not critical right now [17:49] koolhead17: https://launchpad.net/charm/+filebug .. create a 'new-charm' bug and I'll take a look. I usually don't grant membership in charmers until somebody has contributed something significant.. that charm would count. :) [17:50] SpamapS: so can i call myself a charmer now!! :D [17:54] SpamapS: thanks. i will add few more in the list !! :D [17:54] koolhead17: you can call yourself sally if you want. We'll call you a charmer when you have a charm in the collection. :) [17:55] koolhead17: and btw, thanks for the participation and enthusiasm [17:55] * koolhead17 bows to SpamapS [17:55] ok catch you guys from home [17:55] niemeyer, you mean, we only need to support the standard juju ppa at this time, correct? [17:58] jimbaker: Right.. that's the problem we have to solve right now. distro/ppa/branch [17:58] niemeyer, sounds good [17:59] rog: The numbering of reviews is a convention we follow for a while so that we can exchange ideas about points [17:59] rog: "Ah, what about [3] on bar" [18:00] ah ok. [18:00] i do miss rietveldt. i was toying with the idea of using the bzr plugin to that. [18:01] then i thought, no, get used to it! [18:02] rog: Yeah, .. well, kind of.. [18:02] rog: There's a third option: helping to convince the LP folks to improve it :) [18:03] niemeyer: from what you were saying, it sounds like they've got something in the works [18:03] rog: Yeah, there's significant UI changes coming [18:03] rog: Not sure about reviews, specifically [18:03] rog: But once these changes land, we'll be in a better position to request some improvements on the area [18:04] the reviews are really important. i think the Go community would not be nearly so involved without the codereview site [18:04] rog: LP is developed within LP as well, so it's not like they'll resist the idea of making it better :) [18:04] rog: Agreed [18:10] niemeyer: they might not be into the whole code review thing though [18:10] is rietveldt a review tool? [18:10] never heard of it [18:11] rog: Every branch in Canonical going into Launchpad, Landscape, U1, juju, etc.. is reviewed before merging, and it's been like that since the beginning of times :) [18:12] rog: Well before rietveldt even existed [18:12] btw, whats the word on the 'ensemble:formula' in charms? if its not there, will anything break? [18:13] SpamapS: No [18:13] SpamapS: see codereview.appspot.com [18:13] SpamapS: juju removes the need for headers [18:13] niemeyer: cool.. going to do a mass update on charm once juju is uploaded. [18:14] niemeyer: what about $ENSEMBLE_REMOTE_UNIT ? [18:14] SpamapS: JUJU_* [18:14] SpamapS: Please see the email I sent to the list.. it details all the compatible and incompatible changes [18:14] SpamapS: and it's a nice guide for the mass update [18:15] Oh I must have missed the full details [18:15] Been a few long days since then :p [18:16] niemeyer: just addressed the code review points [18:16] (and replied) [18:17] (i'm presuming that replying to the sender address also sends an email to you) [18:17] rog: Yeah [18:17] rog: Thanks, will check it out [18:17] i'm done for the day. see ya monday. [18:24] <_mup_> juju/machine-with-type r366 committed by kapil.thangavelu@canonical.com [18:24] <_mup_> address review comments, use hypens for settings key values [18:24] rog: Have a good weekend! [18:24] niemeyer: will do. mmm curry. [18:27] <_mup_> juju/trunk r358 committed by kapil.thangavelu@canonical.com [18:27] <_mup_> merge machine-with-type [r=niemeyer][f=854230] [18:27] <_mup_> An environment now stores the machine provider-type as a settings property. [18:38] ugh.. i broke a test on trunk [18:40] thats the developer equivilent of a cheerleader dropping the spirit stick [18:43] LOL [18:48] niemeyer, we still need the lxc-library-clone to get reviewed and merged for the local dev stuff to work fully [18:48] bcsaller, any updates on it? [18:48] hazmat: Cool, that's at the top of my review pipeline right now actually [18:49] hazmat: I think its working where it is, wasn't sure from the conversation here if you were ok with the changes to __init__ and clone yet though [18:51] bcsaller, oh i didn't see your followup.. having a look now [19:13] hi all [19:14] hello AlanBell [19:15] so if I set up an application like the wordpress example using juju over several instances, say one database server and 3 web servers doing the PHP stuff, the example ends up with a plain unthemed wordpress. What happens when I want to install a theme? [19:15] do I have to do that on all the web servers manually and manage the sync of that myself? [19:15] AlanBell: nope [19:15] AlanBell: you should relate to a shared storage service (such as NFS) [19:15] which will handle that for you [19:16] assuming the wordpress formula is written to use that [19:16] there are other shared storage services .. ceph, gluster ...etc which I hope someone will charm soon :) [19:17] ok [19:17] and wordpress is about the least appropriate example I can think of to run on juju, but it serves as a technical example! [19:18] yeah! it's actually not that bad :) [19:18] when you get slashdotted .. you'll want to scale it up :) [19:18] kim0: we had drupal one somewhere [19:18] as well [19:18] meh, been slashdotted with wordpress running on a smallish vps [19:19] install supercache, slashdot away at will [19:19] woot .. slashdot must be loosing in popularity :) [19:19] I have also been knocked over by slashdot in the past :) [19:19] but it only lasts a day anyway [19:22] mediawiki is a slightly more realistic example, but things don't start out needing a multi-server architecture [19:23] you would have a single server mediawiki that has grown over time and now has thousands of users and the server is beginning to creak a bit [19:23] then you want to split out the database and add multiple web servers etc [19:24] AlanBell: yeah .. the idea is about the management model of services and how they relate to each other [19:24] how they all collaborate towards an end state [19:24] that's the beauty [19:24] having one service tied to being one ec2 node, is only a current limitation [19:25] once we have LXC working (super soon) .. my understanding is that we'll be able to run multiple services on one box [19:25] so you could do a scaleable architecture starting on a single node? [19:25] which could even be your laptop [19:25] yep [19:25] that would make sense [19:26] otherwise include a migration story [19:26] hazmat: any idea when the local dev (lxc) story is landing please [19:29] kim0, as soon as possible, but no sooner ;-) .. more seriously we've got a few branches in flight that should land hopefully today.. that will setup the basics, but there's some additional work to make things work across all the ensemble commands (ssh, debug-hooks) which won't land till next week realistically [19:30] hazmat: you said the e word [19:30] mostly it relates to the lxc containers (service units) will have distinct ip addresses that need to be reported back to the end user [19:30] kim0, i like the e word ;-) [19:30] haha :) thanks a lot [19:30] * hazmat wonders if he can script an auto replace for that into his irc client [19:31] juju [19:31] :) [19:31] kim0: charms :P [19:31] hazmat: hey [19:32] koolhead17, hi [19:38] hazmat: how have you been? [19:57] hazmat, bcsaller: Review delivered for https://code.launchpad.net/~bcsaller/juju/lxc-library-clone/+merge/75833 [19:57] koolhead17, busy [19:57] koolhead17, looking forward to going home this weekend, its been a long travel the last few weeks [19:58] niemeyer: thanks [19:58] bcsaller: Please let me know if you'd like to talk online about any of the points there [19:58] <_mup_> juju/config-juju-origin r357 committed by jim.baker@canonical.com [19:58] <_mup_> Initial commit [19:58] bcsaller: Will be happy to help getting this in faster in any way possible [19:59] hazmat: awesome. :D [20:32] <_mup_> juju/local-unit-deploy r387 committed by kapil.thangavelu@canonical.com [20:32] <_mup_> address review comments, switch to explicit passing of unit namespace to the unit container deployment [20:33] hazmat: ping [20:33] niemeyer, pong.. almost done getting local-unit-deploy ready for another look [20:34] what's up jujuers [20:34] question! [20:35] hazmat: Just answering your points on the merge proposal instead, for refernece [20:35] niemeyer, cool, thanks [20:36] what's the current thinking re dynamic scaling with juju? [20:37] hazmat: Please see if it makes sense: https://code.launchpad.net/~niemeyer/juju/go-formula-bundle/+merge/75247 [20:37] cole: juju add-unit FTW [20:37] cole: The whole system architecture was designed with that kind of use case in mind [20:38] cole: So it's pretty natural to do it, and we'll be adding more features as we go [20:39] niemeyer: cool, one thing we are thinking of is extending m-collective to be able to talk to ensemble. [20:39] cole: Nice! [20:39] but if there are plans to introduce that functionality…we won't bother. [20:40] niemeyer: if that does sound interesting to you I'd be happy to set something up with Teyo. [20:40] niemeyer, re the comment, so its not clear to me why we need a method to read the whole bundle into memory, if we just expose the file path.. the consumer of the bundle can do whatever is appropriate to its usage [20:41] cole: It depends on what's the functionality you're really looking for [20:41] hazmat: What file path? If I have a bundle in memory I have no file path [20:42] niemeyer, why would you have a bundle only in memory? [20:42] hazmat: Also, what you say is not entirely accurate [20:42] niemeyer: basically let m-collective gather stats on a host and determine threshold and then (since m-collective has no knowledge of relationships) ask ensemble to go scale appropriately. [20:42] hazmat: This is not a method to read the whole bundle into memory [20:42] hazmat: This is a method that takes a sequence of bytes that _are_ in memory, and interprets them as a bundle [20:42] cole: I thought mcollective was just a message bus + some agents [20:43] hazmat: Because, e.g., it was read from a database [20:43] SpamapS: it has the concept of gathering load / performance data. [20:43] cole: Yeah, I'd say don't bother [20:43] cole, we'll need to expose an api endpoint on juju to make that sort of use case easier [20:43] cole: We'll eventually have that internally [20:44] niemeyer:that's the answer I was hoping for! [20:44] cole: Unless you're desperate, of course [20:44] :) [20:45] niemeyer: auto-scaling is a HUGE customer requirement and our default answer is always juju without telling them the auto part of scaling doesn't exist yet ;) [20:45] the auto part is impossible to define for any one workload [20:45] cole: Well, you're not saying something entirely off actually, even with the current state [20:46] What you need is an intelligent rules engine. [20:46] cole: The way that the system works right now actually does quite a lot of "auto" things that other systems can't do [20:46] good point.. [20:46] cole: E.g. "juju add-unit appserver" [20:46] cole: That's really all it takes.. [20:46] its the responsiveness thats missing, but the setting up and configuring things, that it already does. [20:48] cole: right now you could simply use regular graphing/monitoring and when appserver load is too high add-unit .. and when its too low, remove-unit .. [20:49] niemeyer, the local-unit-deployment is ready for another look [20:49] hazmat: WOot [20:52] niemeyer, back to formula-bundle-dir.. ah.. i understand the ReadAt method now.. that is kinda of cool.. re the ReadBundleBytes, ic re the use case [20:53] hazmat: Yeah, that's the orthogonality between types and methods that feels so nicely done there [20:54] hazmat: Thanks for the review.. the bits stuff was great catch there [20:54] hazmat: Will have a look at this over the weekend [20:54] niemeyer, cool [20:59] <_mup_> juju/machine-with-type-merge r378 committed by kapil.thangavelu@canonical.com [20:59] <_mup_> merge machine with type [21:00] <_mup_> juju/provider-determines-placement r390 committed by kapil.thangavelu@canonical.com [21:00] <_mup_> merge machine-with-type and resolve conflict [21:01] <_mup_> juju/unit-with-private-ip r391 committed by kapil.thangavelu@canonical.com [21:01] <_mup_> merge pipeline and resolve conflicts [21:03] <_mup_> juju/local-unit-deploy r389 committed by kapil.thangavelu@canonical.com [21:03] <_mup_> update initialization test to note that settings are now present [21:09] hazmat: So, units are under the namespace.. but what about everything else? [21:09] hazmat, re juju-origin, i have a rewritten version (in lp:~jimbaker/juju/config-juju-origin). however, one question i have is whether we should have the default origin be _DISTRO yet (using the names in juju.providers.common.cloudinit). right now, that wouldn't work [21:09] hazmat: e.g. zookeeper, log files, ... [21:10] jimbaker: Yes, it should be distro.. we have to release this code into Ubuntu. [21:10] niemeyer, each env has its own zookeeper running on the host on a random port, the user can configure the storage for log, pids, via a config option data-dir in the environments.yaml [21:11] hazmat: Yeah, what I don't get is why are we namespacing a particular aspect, rather than having a root that contains everything [21:11] jimbaker, yeah.. the distro installation should be sorted out shortly as soon as we have a s/ensemble/juju packakage downstream [21:11] niemeyer, ok, as is, we have an impasse until the release. it means between the point of merging this branch, assuming it is good, and the release, environments.yaml would need to point to the ppa with juju-origin to retain the current behavior [21:12] and have anything work at all [21:12] niemeyer, effectively the data-dir is that root, but lxc itself wants a flat storage of containers into /var/lib/lxc [21:12] hence the namespace value [21:12] s/value/prefix [21:12] hazmat: I see.. but it looks like we're using a JUJU_HOME like: [21:12] juju_directory="/var/lib/juju" [21:13] niemeyer, that's in the container for the unit agent.. for the machine agent juju home is the data dir configured in environments.yaml [21:13] Or maybe not.. /me looks [21:14] hazmat: I see.. hmmm [21:15] hazmat: It just feels like we're adding yet another concept there, which doesn't map to something concrete (a unit namespace) [21:15] niemeyer, should i submit this as a diff merge proposal and pull the one for env-origin? it's taking a different approach, much closer to trunk, given the simpler usage of ppa (and no deb repository), and the removal of juju-version [21:15] hazmat: Ok, question: [21:16] hazmat: Would it work if we had JUJU_CONTAINER= instead, explicitly? [21:16] hazmat: Or is there any other reason to have the UNIT_NS information? [21:16] jimbaker: Hmm [21:18] niemeyer, we're passing namespace to the machine agent which is creating multiple containers [21:19] moin. [21:25] hazmat: Ok [21:25] hazmat: Still feel a bit strange about it.. feels like if two users try to use it there are clashing resources [21:26] niemeyer, the namespace includes the user name.. where's the clash? [21:27] hazmat: Maybe it's just my impression.. let me see [21:27] + def get_upstart_unit_job(self, machine_id, zookeeper_hosts): [21:27] + """Return a string containing the upstart job to start the unit agent. [21:27] + """ [21:27] + environ = self.get_environment(machine_id, zookeeper_hosts) [21:27] + # Keep qualified locations within the container for colo support [21:27] + environ["JUJU_HOME"] = "/var/lib/juju" [21:28] Sorry.. longer than expected [21:28] hazmat: /var/lib/juju? [21:28] niemeyer, that's for the unit agent in the container [21:29] hazmat: Will this path be used in any way? [21:29] niemeyer, it will be used in the same manner its used for non local dev [21:29] hazmat: Right, but if there are two different environments for two different users, will they conflict given that the setting is the same, or is it ok? [21:29] ie.. the unit agent will store pid, log files there [21:30] niemeyer, those paths are inside the unit container [21:30] hazmat: Ah, inside, ok [21:31] actually i switched the unit agent in the container to log to /var/log/juju so its mostly just workflow state that's in juju home.. [21:31] hazmat: Cool [21:32]