[00:05] <_mup_> juju/trunk r385 committed by kapil.thangavelu@canonical.com [00:05] <_mup_> merge unit-info-cli [r=fwereade,niemeyer][f=863816] [00:05] <_mup_> Allow units to obtain their public and private addresses in a provider [00:05] <_mup_> independent fashion [00:09] <_mup_> Bug #867991 was filed: local provider needs documentation < https://launchpad.net/bugs/867991 > [00:12] <_mup_> Bug #867993 was filed: Code/module docs seem to use "j" instead of juju < https://launchpad.net/bugs/867993 > [00:17] hazmat, here is the master-customize.log: http://pastebin.ubuntu.com/702511/ [00:18] i tried going against the latest in unit-info-cli, no changes i could see [00:18] interesting [00:18] in terms of the log or juju status' [00:19] jimbaker, what's the output of > host archive.ubuntu.com192.168.122.1 [00:19] whoops space between those [00:19] jimbaker, it looks like a network connectivity problem [00:20] hazmat, here's the output: http://pastebin.ubuntu.com/702516/ [00:21] jimbaker, one more.. what's the output of sudo cat /var/lib/lxc/yourusername-yourenvname-0-template/rootfs/etc/resolvconf/run/resolv.conf [00:22] hazmat, nameserver 192.168.122.1 [00:23] jimbaker, odd [00:23] everything sounds like its correct [00:23] jimbaker, aha [00:23] hazmat, ? [00:24] (if you want i can give you a login to this box) [00:24] jimbaker, so oneiric is still in beta so old packages aren't per se kept around [00:24] jimbaker, you'll need to update manually your lxc cache [00:24] hazmat, ok [00:24] so it has the latest oneiric packages [00:25] jimbaker, $ sudo chroot /var/cache/lxc/oneiric/rootfs-i386/ [00:25] jimbaker, $ apt-get update && apt-get upgrade [00:26] that should fix things, else the pkg cache was ref'ing non existant packages upstream i bet [00:26] ok, doing that, but against amd64 :) [00:26] * hazmat heads out for a dog walk [00:26] bbiab [00:26] hazmat, makes sense, this would explained those bad refs in master-customize.log [00:27] jimbaker, also you can update your juju-origin to lp:juju/trunk if you want.. its all committed now [00:28] hazmat, sounds good [00:56] jimbaker, that work for you? [01:14] hazmat: Man! [01:14] hazmat: wtf is happy with unit-get! [01:14] niemeyer, :-) [01:14] * niemeyer dances around the chair [01:14] niemeyer, cool, i'm out going to go enjoy some down time [01:15] hazmat: Enjoy it :) [01:15] niemeyer, sent out some mails to the list inviting additional local provider testing [01:15] I'm going down too [01:15] hazmat: Superbsome [01:17] * niemeyer => poweroff [01:51] hazmat, hmmm, the upgrade was successful of the lxc cache. looks like i have a networking issue, the agent logs (which i finally have) just report zk errors about network is unreachable [01:51] (agent logs for mysql/0, wordpress/0) [01:52] the other detail is that the master-customize.log was not touched. is that only used in the event of an error? [02:10] hazmat: oh nice, I'll try local/LXC as soon as the build is finished [02:10] hazmat: I've been looking forward to this. [02:49] anyone try the local provider? I'm having some problems getting the environment right [02:52] jcastro, i have tried the local provider several times, but yet to get it running [02:52] I'm not even getting past the environments.yaml bits [02:54] jcastro, this is my environments.yaml for lxc: http://pastebin.ubuntu.com/702557/ [02:55] jcastro, for me it's failing in the network at this point [02:56] "error: internal error Network is already in use by interface virbr0" [02:56] look familiar? [02:56] jcastro, i have seen that. one thing to try (hate to tell you it) is to reboot your computer [02:56] hah, awesome. [02:57] the initial lxc networking for whatever reason didn't come up properly until i did this [02:57] jcastro, before doing that, might as well make sure you upgrade the pkg cache [02:57] see above, approx 2.5 hours ago [02:59] ah [03:00] jimbaker: woo! status works [03:01] jcastro, cool, but the provisioning agent runs on your machine, so it's not indicative of the lxc bits [03:01] (other than using local of course) [03:02] ah [03:02] i just got past that just now, the fragility was in the package cache [03:02] they show up in status, but their state is still null [03:04] jcastro, do something like $ ps -ef | grep juju - verify you see unit agents for mysql/0 and wordpress/0 (or whatever stack you are attempting) [03:05] doesn't look like it, just one for zookeeper itself, which I assume is the provisioning one [03:07] jcastro, yes, you will have one zookeeper instance as part of the provisioning setup [03:08] jcastro, so check for the existence of master-customize.log - this will be in the data dir, owned by root [03:09] jcastro, ideally you will have logs for each of service units there too, a container log (for lxc debugging) and the unit.log itself [03:09] all the log dirs are empty [03:10] jcastro, ok, so you are seeing something else wrong (and i assume you did the reboot) [03:10] yeah [03:10] the bootstrap runs, completes, no errors [03:12] jimbaker: ok heading to bed, openstack conf tomorrow, I will certainly try on the plane. :) [03:12] bootstrap really means nothing unfortunately - and status is less useful here [03:13] well, of node 0 [03:13] yeah it looks like it thinks it's firing off things, but they're not happening [03:13] at first I was like "wow, this is fast." [03:13] but it doesn't appear to be actually doing anything, heh [03:13] i think it might actually be fast, but yeah, still waiting to get it to work [03:13] ok, enjoy the conf! [03:13] i feel like we're close! [03:14] i think so too, there are some basic setup doc issues, possibly ones that can be scripted, to make it work, i suspect i just have one more to go through [03:20] /me catches up [03:20] surprised rebooting is needed [03:21] jcastro, its all async same as other providers so its fast to execute commands [03:21] but takes a few moments for reality [03:22] jcastro, planes are probably a problem, network connectivity is needed for non cached package installs [03:24] jimbaker, so the lxc cache update didn't solve the issue for you? [03:25] <_mup_> juju/remove-sec-grp-do-not-ignore-exception r383 committed by jim.baker@canonical.com [03:25] <_mup_> Merged trunk [03:28] jimbaker, the master customize log is updated only after the complete run, u should use ps | grep lxc to verify that [03:28] ps uax [03:28] oh... no.. gluster acquired [03:38] <_mup_> juju/trunk r386 committed by jim.baker@canonical.com [03:38] <_mup_> merge remove-sec-grp-do-not-ignore-exception [r=niemeyer][f=863510] [03:38] <_mup_> Simplified logic for removing security groups to ensure any exceptions [03:38] <_mup_> are not ignored by being consumed by the Twisted reactor. [04:10] hazmat, i got further with the lxc cache update [04:10] but now i'm seeing this networking issue [04:14] hazmat, so in the unit.log files (in my case mysql/0, wordpress/0), i'm seeing this repeated: Network is unreachable [04:14] so something is wrong w/ the virtual network setup [09:46] Hi all ! [09:46] is juju well suited for my use case: [09:46] I want to launch a complete infrastructure with 1 command, and service knowing one each other address [09:47] and , also , I want to specify a list of packages to install on each nodes , and some sed commands [09:47] is chef-solo better for doing this ? or cloudformation (I'm working on EC2) [09:49] xerxas: from my reading I think juju can do that for you - but keep in mind it is under development. Not sure if you want to base any production sites on it right now [09:52] TeTeT: you mean, if I want to make live my infrastructure ? [09:53] If I'm adding unit afterwards ? [09:53] xerxas: adding units should work nicely, if the charm allows for it. What is your schedule for going productive? [09:54] now ;) [09:55] what's the simplest way de provision ec2 infrastructure (not instances, but infrastructures !) [09:55] cloud-init seems ok for instances, is cloud-formation the cloud-init of infrastructure ? [09:58] xerxas: actually I'd say juju is exactly what you need, and is the simplest way going forward [09:59] xerxas: it's just that it's alpha quality right now [09:59] kim0: why ? [09:59] because it does what you described :) [09:59] kim0: I don't mind if it's alpha or not, if it boots my 3 instances, setup a rabbitmq on one , et create a config file on a second one containing my rabbitmq server ip address [09:59] kim0: ;) [10:00] kim0: this is maybe why I'm asking here ;) [10:00] ahh , also, question , I tested juju ... but [10:00] juju client, needs to be ubuntu , as juju "controller" and , juju booted intances ? [10:00] xerxas: no client can be osx too [10:00] by controller I mean the instance where zookeeper is installed [10:01] or other linux [10:01] kim0: nice, I'm running osx ;) [10:01] cool [10:01] but the rest needs to be ubuntu [10:01] xerxas: I think it's available on some osx repo [10:01] can't remmeber what osx folks use to install cli tools :) [10:01] brew [10:01] yes that's it [10:01] and easy_install ;) [10:01] wasn't there fink back in the day? [10:01] which was a lot like apt [10:02] think brew it is now [10:02] TeTeT: fink is useless know [10:02] been 6 years since I worked with osx ... [10:02] brew is git based, easy formula (which is metadata for building packages) writing , social ... [10:03] been 6 years I had a ubuntu based desktop ;) [10:03] xerxas: here is a rabbitmq charm: https://code.launchpad.net/~charmers/charm/oneiric/rabbitmq-server/trunk [10:03] but never left ubuntu on the server ;) [10:03] xerxas: good choice ;) [10:03] and will never (you're doing good work , guys ! ) [10:03] kim0: thx for the url [10:03] xerxas: so one instance is rabbitmq, what are the other two ? [10:04] some daemon I wrote in python consuming messages [10:04] ah cool! [10:04] one will have some lxc container [10:04] containers [10:04] morning - anyone tried using the LXC local provider yet? [10:04] xerxas: sounds like a cool project! [10:05] anyway, my python daemon have a configuration file and in that configuration file I have an ip address, the one of the rabbitmq server [10:05] (more precisely, one of rabbitmq-s server, because we might have several of them ... ) [10:05] xerxas: I'd love to write an article about that project when you get it running .. keep me in the loop :) [10:09] jamespage: it's on my plate for later this week [10:19] TeTeT: is it already working fine ? [10:33] kim0: I don't know yet, this I why I'd love to test it [10:33] yeah [11:14] * HarryPanda can't get local charm repositories working anymore [11:15] good morning [11:16] `charm create test /root/charms && juju deploy --repository /root/charms/ local:test` = no dice [11:17] HarryPanda, you need to use a series (like 'oneiric') as additional directory in the repository from the base to the charm.. [11:18] HarryPanda, ie.. so looking at the example formulas that come with juju.. its examples/oneiric/wordpress [11:18] aah, I haven't been keeping up with the changelog [11:20] HarryPanda, yeah.. that was recent [11:20] * HarryPanda got confused about store.juju.ubuntu.com etc. [11:20] there was a mail out to the list about the chance [11:20] HarryPanda, its basically a charm repository.. its not active yet [11:20] HarryPanda, yeah.. its a bit confusing on the error message [11:20] fwereade, ^ [11:21] jamespage, haven't gotten any new feedback yet [11:22] hazmat, hey - I had a go based on your posting to juju@l.u.c [11:22] jamespage, cool, how'd it go? [11:23] hit a few errors - the environments.yaml entry wanted a type and admin-secret entry as well ( so I had a guess) [11:23] jamespage, doh.. yeah [11:24] jamespage, late night emails.. bad [11:24] jamespage, and then? [11:24] jamespage, fwiw admin-secret is anything you want it to be [11:25] I appear to have a running environment! [11:25] I've not deployed anything yet - you caught me as I was typing juju bootstrap --environment.... [11:25] * HarryPanda is slowly getting our full stack running on a mix of vmware+orchestra, ec2 and lxc :) [11:26] jamespage, cool.. the real work happens when you first deploy a charm.. and it starts creating lxc containers.. [11:26] HarryPanda, fun [11:27] hazmat, OK about to try that [11:27] jamespage, its async to the cli, so giving progress on it is a little hard, you can ps aux | grep lxc to watch it happen, or tail the log file in data-dir/machine-agent.log [11:36] hazmat: hmm - not sure the machine agent started [11:38] http://paste.ubuntu.com/702702/ [11:39] jamespage, hmm.. haven't seen that one [11:39] jamespage, can you try bootstrapping with the verbose flag? ie. juju -v bootstrap [11:40] jamespage, that should give the traceback [11:40] jamespage: I'm getting the same [11:40] local/agent.py:59, changed JUJU_ORIGIN=%s to JUJU_ORIGIN=ppa [11:41] hazmat: http://paste.ubuntu.com/702706/ [11:41] dah [11:41] foobar [11:41] jamespage, thanks [11:41] np - want me to raise a bug? [11:42] jamespage, i think its a trivial, i can commit it to trunk, just double checking [11:42] i was verifying this with a juju-origin defined in my environments.yaml.. but i didn't test without one [11:43] yeah.. niemeyer mentioned he'd changed the interface on this function, but i forget [11:46] hazmat: hmm - might also be better to depend on zookeeper rather than zookeeperd as the local provider starts its own instance [11:46] saves a running java process which is always a good thing [11:47] jamespage, good point.. libzookeeper-java should have what we need [11:47] yep [11:49] keen to test this as I have seen panics running Java stuff under lxc with openstack [11:49] might disappear as a result tho :-) [11:54] jamespage, we don't require any java under lxc.. but noted [11:54] fwereade, http://paste.ubuntu.com/702712/ [11:54] could i get a +1 on that trivial [11:54] hazmat, well juju does not - but charms might... [11:55] jamespage, yup [11:55] no cassandra might hurt [11:55] * hazmat sheds a tear over gluster's acquisition [11:56] redhat? 0.o [11:59] hazmat: sorry, I'm not quite following the paste [12:01] hazmat: well, just the first bit [12:01] hazmat: I guess, the packages need to change, so... you change the packages [12:01] hazmat: consider my confusion withdrawn [12:02] hazmat: +1 [12:03] fwereade, yeah.. let me repaste.. the origin handling changed, but i made it to a branch copy by accident [12:06] hazmat: getting there - I now have a running lxc container - however its not showing up as started yet [12:08] I can log into it using SSH [12:08] fwereade, updated diff.. http://paste.ubuntu.com/702715/ [12:09] fwereade, does a couple of things, logs juju origin when starting machine agent, fixes the handling for juju origin to reflect new return signature from get_default_origin, changes the package dep from zookeeperd to libzookeeper-java [12:11] hazmat: cool; have a much-happier +1 :) [12:12] jamespage: what's the 'state' for the service unit? [12:13] HarryPanda: null [12:13] I can see the failsafe upstart configuration waiting for network interfaces to come up within the lxc instance [12:14] http://paste.ubuntu.com/702719/ [12:14] <_mup_> juju/trunk r388 committed by kapil.thangavelu@canonical.com [12:14] <_mup_> [trivial] require libzookeeper-java not zookeeperd, update handling of get_default_origin, log origin used [r=fwereade] [12:17] jamespage, interesting i never noticed that b4 re waiting for network within the container [12:18] jamespage, sadly it happens on my laptop.. sort of destroys any value to making boot faster [12:19] jamespage, the unit agent gets started via upstart.. it should have a symlink to its log at $data-dir/units/$unit-name/unit.log [12:22] the link will be broken if the unit agent never started [12:24] HarryPanda, where you get to with the origin=ppa change? [12:25] hazmat: enough to get it working so I could deploy stuff [12:25] I will re-checkout after lunch [12:25] HarryPanda, cool, and you see the units with state: started in juju status? [12:25] HarryPanda, cheers [12:26] lxc-ls shows the containers, the output is a bit odd, it will list it twice if its running, once if its defined but not running [12:27] * hazmat regen's the ppa [12:29] * HarryPanda still has a lot of catching up to do in the meantime, like puppet integration [12:31] jamespage, can you pastebin your $data-dir/units/master-customize.log [12:36] hazmat: http://paste.ubuntu.com/702724/ [12:37] jamespage, nice.. looks good [12:37] jamespage, but your unit agents aren't starting? [12:38] not within the instance [12:39] jamespage, do you have any output in $data-dir/units/$unit-name/unit.log or is it a broken link? [12:40] hazmat, broken link ATM [12:40] this instance is stalled waiting for the network interface to start [12:40] so I don't the right run-level has been initiated yet [12:41] jamespage, if your able to ssh into the unit, you can try manually starting the agent using its upstart file as a guideline /etc/init/$unit-name-unit-agent.conf [12:41] jamespage, hmm.. i haven't seen that one before re network start wait in the container, except on the host [12:42] * hazmat doesn't understand why oneiric is waiting on network config [12:42] hazmat: so I did a sudo start xxx on the unit agent [12:42] now showing as started [12:43] jamespage, cool [12:43] hazmat; adding another unit has resulted in another stalled lxc instance - bah! [12:45] humbug [12:46] jamespage, had you used lxc before today?.. i'm just wondering if destroying the env, and clearing out the lxc cache would help /var/cache/lxc/oneiric/* [12:46] its been at least week since i did that myself [12:46] hazmat, hmm - I can try that [12:47] jamespage, alternatively you can try manually chroot into the cache and upgrade it.. but if i remember the bug correctly its pretty temperamental wrt to package install/upgrade/removal [12:58] * hazmat will bbiab [13:01] Morning all! [13:05] niemeyer: hiya [13:12] hazmat, looks like /etc/rcS.d/S07resolvconf is blocking - which is stopping the rest of the lxc instance from coming up OK [13:15] rog: Yo [13:15] jamespage: Hey James [13:15] jamespage: Very interesting ideas in your testing charms post [13:15] niemeyer, morning [13:15] thanks [13:15] jamespage: Still digesting them [13:16] niemeyer, I did a bit of refactoring yesterday based of sabdfl's comments [13:16] jamespage: We have a test suite continuously running at wtf.labix.org ATM, and it made me ponder if we could do more there [13:16] the charm-tester is now a bit more clever and less implicit [13:16] niemeyer, that might be good [13:22] niemeyer, whats driving the testing ATM? [13:22] jamespage: A few trivial scripts.. the whole thing is in lp:juju/ftests if you'd like to check it out [13:26] fwereade: ping [13:26] niemeyer: pong [13:26] niemeyer: it's turned out *much* easier than I expected [13:26] fwereade: Oh, that's so great to hear [13:27] fwereade: I went to sleep a bit concerned yesterday imagining if we'd have to go back [13:27] niemeyer: didn't stop me trying to do it wrong earlier, ofc, but you should have a fresh MP in a short while [13:27] fwereade: Woohay! [13:27] niemeyer: yeah, it's a great relief :) [13:27] niemeyer: and then the auto-update on top of that should be almost trivial [13:28] niemeyer: EOD or before [13:28] * fwereade crosses fingers [13:28] fwereade: Superb.. I'm hopeful we can close down the client side for fixes only today still [13:28] SpamapS: ^ [13:32] hazmat: so it looks like plymount --ping is hanging forever; hence why the failsafe config is kicking in [13:33] * jamespage scratches his head [13:52] niemeyer: if you guys can give me the revision to upload I will start some builds and tests [13:53] SpamapS: Sounds great.. we just need the stuff fwereade is punching on right now [13:54] niemeyer: here is r381's build failures btw https://launchpadlibrarian.net/81962870/buildlog_ubuntu-oneiric-i386.juju_0.5%2Bbzr381-1juju1~oneiric1_FAILEDTOBUILD.txt.gz [13:56] haven't seen those [13:57] jamespage, lame.. dhcp should just work [13:57] hazmat, I think it kinda is - however plymouth --ping is hanging when it tries to configure its logging [13:57] jamespage, we can prepopulate resolvconf/resolv.conf.d/base like we did before but for the container startup, straight dhcp should just work [13:58] * hazmat does a man plymouth [13:58] hmm.. undocumented [13:59] jamespage, so plymouth --ping sounds like it just pings upstart [13:59] from its help [13:59] its the thing that multiplexes all of the output from init scripts and upstart [13:59] * hazmat is out of his element [13:59] ah [14:00] I've pinged hallyn_ - he might have some ideas esp. with regards to why its borked in a lxc container [14:01] jamespage, great, just sent some updated instructions to the list and noted the plymouth hangs [14:02] * hazmat resets his lxc cache [14:03] * hazmat really needs to find a 7mm ssd [14:20] niemeyer: about "breaking" changes [14:21] niemeyer: it's ok to just commit something that will not work with existing agents deployed from an older branch... or is it? [14:21] fwereade: *TODAY* it is.. tomorrow, it's not. :-) [14:21] heh, good :) [14:22] hey guys, you should get the juju mailing list added here: https://lists.ubuntu.com/ [14:22] it's kind of hard to find if you don't know what it's called [14:26] mdeslaur, good point [14:27] <_mup_> Bug #868391 was filed: Juju mailing list should be listed on lists.ubuntu.com < https://launchpad.net/bugs/868391 > [14:27] mdeslaur, at the moment the easiest way to find the ml is from the section at the bottom of juju.ubuntu.com [14:28] hazmat: yes, thanks [14:33] rog: Great stuff indeed in update-server-interface man, thanks! [14:33] rog: I've sent a few comments/suggestions, but pretty superficial stuff [14:33] niemeyer: good, i'm, erm, relieved you like it :-) [14:37] don't you hate it when you know you've made some changes somewhere, but you can't find them anywhere? makes me wonder what else i'm also missing :-) [14:40] niemeyer: how would you like really-isolate-formula-revisions? stacked branch on isolate-formula-revisions, both set to needs review? [14:40] jamespage, works for me ootb with a clean lxc cache [14:40] fwiw [14:40] jcastro, ping [14:41] niemeyer: ah, i've just realised that update-server-interface is several revisions ago. [14:41] rog: Well, please do the suggested changes in the version that is up for review, and let's merge it as is [14:41] rog: Then you can push a separate branch with the new content [14:41] niemeyer: i thought you were reviewing factor-out-service ... [14:41] rog: Nope.. reviewing this now [14:42] rog: Please do the changes in the specific revision that was actually reviewed so we can merge it [14:42] niemeyer: will do. [14:42] fwereade: Hmmm [14:42] fwereade: Not sure I understand your question [14:43] fwereade: You have a review on the previous branch.. what is happening with it? [14:43] niemeyer: the trivials are fixed in that branch; the big one is fixed in the stacked branch [14:43] niemeyer: the actual changes are trivial but widespread [14:44] niemeyer: I'm just as happy to merge back into the original branch, or to add a new MP [14:44] niemeyer: whatever's easiest for you to review [14:44] fwereade: Please just push it all on that single branch.. I'll have to review it jointly either way since the prior one has blockers without the follow up [14:44] niemeyer: ok, cool [14:48] rog: Just added a [10] comment now that I've figured a detail in the follow up branch [14:49] niemeyer: one thing that concerns me about doing kill(pid, 0) is that it's system-specific. but i guess we're tied to linux anyway. [14:50] rog: Yeah.. I'm not very concerned about WIndows to be honest :) [14:50] rog: The way to fix that would be to add something in the Process interface itself [14:50] rog: IsRunning or whatever [14:50] rog: server side linux is a good bet. clients may be OS X or something else. [14:51] rog: But that's not something I worry about myself.. I'll let the Windows folks worry about it [14:51] this is client-side too, right? i'm also slightly concerned that some users may get EPERM even though the process is actually running. [14:52] i'm not too au fait with modern unixy capability stuff [14:59] rog: If they get EPERM, that's great.. it's not their process and they shouldn't be fiddling with it [15:00] * rog nods. [15:04] hazmat: I have something to try - I have plymouth in debug mode on my laptop for another issue - might be causing problems [15:10] cd [15:15] niemeyer: hmm, there's a problem with checking if server process is actually running: what do you do if the pid.txt file exists, but there's no running server? you'll have to remove or rewrite the pid.txt file, but then you no longer get the nice race-free create semantics that you've got currently, so two concurrent callers could start two servers at once. [15:17] niemeyer: btw, https://code.launchpad.net/~fwereade/juju/isolate-formula-revisions/+merge/78164 is ready for another look [15:21] hazmat: that fixed it - for some reason having plymouth:debug as a kernel boot options breaks the in-instance plymouth [15:33] fwereade: Ok, let me see how's lunch looking like here [15:33] fwereade: I'll review it either right now or right after lunch [15:34] rog: I don't get the problem.. if the pid file exists and there's no server running, there's simply no server running? [15:34] niemeyer: yes, but there's a problem if two processes are both trying to start a server at the same time in the same directory [15:34] niemeyer: currently that situation is dealt with fine [15:35] rog: One of them will fail because the port number won't be available [15:35] niemeyer: but the wrong pid might end up in the pid file [15:36] jamespage, awesome! [15:36] * niemeyer thinks [15:36] niemeyer: my current thought is that we should still return an error, but that the error should reflect our knowledge of whether the server is or isn't currently running [15:37] kill(pid,0) should work on osx i would think [15:37] hazmat: yeah, it should. [15:38] hazmat: i was more thinking of windows. [15:38] ah, i don't think anyone cares about that in practice for juju ;-) [15:38] rog: Please ignore the concurrency issues for now and just proceed as we discussed [15:38] e.g. "server is currently running" vs "server was terminated abnormally. Remove /.../pid.txt to force a start" [15:39] rog: We can use actual file locking to sort the problem out, but that's really not for this branch [15:39] niemeyer: oh yeah, another thought: does anyone use shared filesystems these days? [15:39] niemeyer: 'cos that'll break it too. [15:40] rog: I don't know, but that's not a problem to worry about now either [15:41] niemeyer, latest tip should work with the go branches in review? [15:44] hazmat: It should [15:44] * hazmat compiles tip and dives in for a review [15:52] fwereade: Ok, I'll have lunch before finishing your review.. will be back ASAP and dive into it directly [15:52] niemeyer: cool, the auto-upgrade itself is simple, and works AFAICT, but testing it is a bit tedious [15:53] fwereade, should be much faster with local provider ;-) [15:53] hazmat: it's just *writing* the tests that's bugging me :) [15:54] fwereade, ah [15:55] hazmat, i tried the latest (trunk r388), still seeing the same networking issues [15:55] i'm going to just reboot this box and see if that helps [15:55] jimbaker, yeah.. bcsaller is as well [15:55] jimbaker, rebooting won't do anything for this [15:56] hazmat: last I heard that was about virbr0 errors for jimbaker, thats not what I'm getting [15:56] hazmat, ok, it was the ultimate solution for the first time, but definitely welcome any ideas [15:56] i'm clearing out my apt-cacher-ng cache, and trying again, already cleared out the lxc cache and it worked fine.. so afaics i shouldn't have anything cached localy [15:56] jimbaker, your not getting virbr0 errors anymore are you? [15:56] hazmat, no [15:57] bcsaller, so i cleared out lxc cache, apt-cacher-ng cache, and it works for me.. [15:57] i'm just getting network connectivity issues between the lxc instances (mysql/0, wordpress/0) and zk [15:57] hazmat: we may want to add a juju-local-dev metapackage with all those extra deps [15:57] SpamapS, perhaps.. bootstrap will fail and tell you whats missing though [15:57] hazmat: yeah, thats expected, right. Its stale cached data that makes the issue [15:58] hazmat: think upgrades [15:59] hazmat: if we add more of those, or don't need more of those, we can help users add/remove them automatically :) [15:59] SpamapS, yeah.. but that puts the extra dep everywhere [15:59] SpamapS, including machines deploying units [15:59] SpamapS, ie require java ;-) [16:00] i'd rather avoid that [16:00] hazmat: which is why we put it as juju-local-dev, which is only a Suggests of juju [16:01] SpamapS, ah. true that, yeah.. that sounds fine to me.. i think niemeyer objected last time around on that, but if your up for doing it.. sounds good [16:01] hazmat: its a distro choice really. :) [16:02] SpamapS, well then i leave it to some anonymous distro person ;-) [16:12] slightly frustratingly my local lxc instances are not picking up any dns resolvers... [16:12] weird [16:12] hazmat: ^^ [16:17] bcsaller, why would dnsmasq need to be specified explicitly in the container if its dhcp based [16:18] hazmat: maybe if the resolvconf package isn't installed, I don't know the details, it might be a matter of competing systems there [16:18] bcsaller, so what do you have in resolv.conf of the master template? [16:21] SpamapS: hey [16:24] hazmat, finally the lxc containers came up after cleaning the caches (i assume /var/cache/lxc, /var/cache/apt-cacher-ng), but i'm still getting Network is unreachable in the unit logs: http://pastebin.ubuntu.com/702840/ [16:25] fwereade: Diving in again [16:27] jimbaker, do you have zookeeper running in the host? [16:28]