=== elmo_ is now known as Guest53104 [07:09] <_mup_> Bug #920312 was filed: open-tunnel leaves juju unable to connect to an environment if local IP changes < https://launchpad.net/bugs/920312 > [07:49] heh.. juju status | ccze -A [07:49] looks quite nice actually [07:49] * SpamapS opens a feature request to have ccze colorize ec2 instance ids. [07:50] oh hah.. 2007 was the last release [08:01] hey SpamapS [08:02] SpamapS: did you guys manage to try juju on euca? [08:08] shaon: the trouble is the leading path recommended/required on walrus [08:09] shaon: should be possible to bypass with a reverse proxy that hosts walrus on / [08:09] SpamapS: hmm [08:10] shaon: I'd be surprised if we were the only ones running into this.. seeing as Euca themselves had to patch s3cmd/boto to work this way [08:15] SpamapS: so what do you suggest in this case? [08:18] shaon: try setting up a mod_proxy server with ProxyPass / http://your.walrus.server/with/its/path:9999 [08:18] shaon: you could even run it on the same box, but with a different port [08:19] SpamapS: okay, will inform you the update [08:19] SpamapS: thanks :) [08:23] shaon: no, thank you for testing. :) [12:57] Good morning! [13:14] hello [14:04] <_mup_> Bug #920454 was filed: juju bootstrap hangs for local environment under precise on vmware < https://launchpad.net/bugs/920454 > === Guest53104 is now known as elmo [16:19] Why is it so silent in here today? Everybody in their hacking hats? :) [16:19] niemeyer, i suppose so [16:20] it's a monday after a big conference [16:40] m_3: Hello. can you explain the client and server interface of mediawiki to an ignorant like me? [16:41] nijaba: hey man... lemme take a look [16:41] m_3: hey, I thought it was your charm. [16:41] m_3: guess not [16:42] nijaba: I've worked on it since it was written... but most of my changes are in a separate branch waiting for colocation to land [16:42] k [16:42] (things like monitoring and a shared image-store to use when spreading to multiple wiki instances) [16:42] m_3: was it SpamapS originally? [16:43] heck dunno... lemme look at the history [16:43] * nijaba looks too [16:43] I think kapil orig... then clint... then me [16:43] what're you wondering about? I've worked with it a bunch [16:44] m_3: why the db has 2 interfaces, client and server [16:44] oh... db and slave? [16:45] lemme refresh to make sure I'm looking at the most recent version of the charm [16:45] m_3: thanks :) [16:46] the wiki is set up to use a replicated mysql setup... that's prob what's going on [16:49] nijaba: look in hooks/combine-dbservers [16:49] m_3: k [16:53] m_3: thanks, got it. Cheers [16:54] I've got a working stack script for mediawiki using a replicated mysql setup... it's around here somewhere [16:55] * m_3 digging [16:55] it might be named ensemble tho :) [16:55] so s/working/was-working/ :) [16:57] nijaba: http://paste.ubuntu.com/814448/ [16:57] m_3: neat [16:58] looks _great_ in gource too btw [17:39] adam_g: btw, don't know if you noticed, but the precise PPA is finally up to date [17:39] I think its about time we updated the precise distro version actually [17:39] reminder to devs: feature freeze is Feb 16! [17:40] SpamapS: ah, cool [17:41] hazmat: thanks, btw, for the twisted fix! [17:57] http://wtf.labix.org/447/ec2-wordpress.out.FAILED [17:57] how do we retry these? [17:57] just looks like maybe connectivity was compromised [17:59] SpamapS, looks like the instance just took a while to startup up, and the test fell out of its retry loop (120 times) [17:59] http://bazaar.launchpad.net/~juju/juju/ftests/view/head:/tests/ec2-wordpress/run.sh [18:00] Yeah I know it works.. I've been using 447 for a while now its fine [18:00] Just wondering if we can tell wtf to try again or we have to wait for the next commit [18:02] not sure afaik its a wait for new change, its setup as a cron trigger polling for new revs, alternatively perhaps niemeyer could run it again from the that machine [18:02] * SpamapS longs for jenkins in all its monstrous glory [18:03] :( [18:03] SpamapS: Be my guest :) [18:04] * SpamapS presses enter on his juju deploy of it into canonistack [18:06] Meanwhile, wtf.labix.org is running 447 again. [18:06] cool ty! [18:07] SpamapS: np [18:07] * SpamapS really just wants jenkins for the IRC bot and pretty graphs. ;) [18:08] SpamapS: It's marking 447 as FAILED, but if you click on the FAILED, you'll see it redirects back because it doesn't exist [18:09] SpamapS: By the time it ends, it should have ok/FAILED, and the output will be there again [18:09] sweet.. just wanted to make sure it passes before uploading that to Ubuntu [18:11] whoa.. bug listings just got like.. rainbowized [18:11] https://bugs.launchpad.net/ubuntu/+source/juju [18:13] :-) [18:39] SpamapS: You got a green [18:40] niemeyer: w00t [18:40] local build test passed too [18:40] * SpamapS uploads [18:40] Build needed 00:05:27, 16640k disc space [18:40] I love eatmydata ... :) takes 16 minutes on the buildds [18:41] eatmydata? [18:41] SpamapS: Is that something that wraps a process to monitor it or something? [18:44] niemeyer: http://www.flamingspork.com/projects/libeatmydata/ [18:44] libeatmydata is a small LD_PRELOAD library designed to (transparently) disable fsync (and friends, like open(O_SYNC)). This has two side-effects: making software that writes data safely to disk a lot quicker and making this software no longer crash safe. [18:45] SpamapS: Ah, neat [18:45] Good for iterating over tests [18:45] SpamapS: That's awesome indeed, and the name is awesome too :) [18:45] niemeyer: most of what Stewart does is quite awesome actually [18:45] SpamapS: I guess that could be done with a ramfs int his case, tho [18:46] SpamapS: I can see that being unfeasible for larger values of "data", though :) [18:46] niemeyer: right, but eatmydata requires no privileges. [18:46] SpamapS: Good point [18:46] niemeyer: tmpfs/ramfs will always outperform it.. but eatmydata is a nice way to opportunistically take full advantage of memory [18:46] * niemeyer mumbles something about plan9 [18:47] when you don't care for durability [18:55] Has anyone had problems with openstack returns hostname that juju doest not can resolve? [18:55] jcastro: ping [18:56] andrewsmedina: Hmm.. sounds like a networking issue [18:56] andrewsmedina: Do you recognize the hostnames it can't resolve? [18:57] niemeyer: I think that it's a nova-network problem [18:57] andrewsmedina: Gotcha [19:00] man.. ccze even makes bzr logs more readable. :) [19:01] Though I'm not sure why it highlights Clint, but not Byrum.. hm [19:11] andrewsmedina: yes, this is a common problem... I'm not sure of the best long-term solution [19:12] andrewsmedina: start on a box that can hit the openstack endpoint using euca-tools or equiv [19:13] m_3: eucatools work's fine here, but the vm's create with juju doesn't [19:13] andrewsmedina: then 'juju bootstrap' should come up [19:13] andrewsmedina: then you have to euca-allocate-address and associate that with the bootstrap instance [19:13] m_3: hmm [19:13] thereafter juju works fine [19:14] when you need to "expose" a service, you'll have to attach another public address [19:14] I miss those things in the juju docs [19:14] (I'm working on an openstack installation that only gives me two public IPs... so I have to swap them around sometimes) [19:14] andrewsmedina: yeah, funny that :) [19:15] andrewsmedina: not sure if they're in there atm [19:16] m_3: I'm working in a PaaS project that use juju as engine [19:17] andrewsmedina: cool! [19:17] andrewsmedina: I'd love to discuss details of your setup sometime [19:18] m_3: cool! :D [19:32] andrewsmedina: The docs for working with OpenStack are a bit obtuse because the docs we have are mostly focused on using the EC2 API for.. EC2. :) [19:33] SpamapS: I know [19:33] we should definitely add notes for where openstack might differ [19:33] same for eucalyptus too really [19:33] SpamapS: If I can help [19:33] tell me [19:40] andrewsmedina: please, by all means keep track of what you're doing... even if it's rough notes it's valuable [19:41] andrewsmedina: there're _lots_ of different ways to run an openstack or eucalyptus setup... [19:41] m_3: I now [19:42] OpenStack is very flexible [19:43] it's a good thing fundamentally.. but it makes it pretty tough to target [19:43] we are wrote some charms too [19:48] whoohoo! [19:51] One of the openstack core devs was at SCALE and wanted to work on an OSAPI provider [19:58] jcastro: ping [20:02] niemeyer: he may be swapping today, since we all worked the weekend at SCALE [20:04] SpamapS: Thanks, I imagined that could be the case.. was just hoping to catch him passing by to ask about the docs stuff [20:05] still waiting on the IS ticket to build from lp:juju/docs ? [20:16] SpamapS: It's more about how the splitting is going [20:16] * m_3 lunch [20:16] SpamapS: I want to push the charm store spec to the server [20:17] SpamapS: and it's not clear to me where things currently live [20:18] niemeyer: seems like you still have to commit it to lp:juju and then merge to lp:juju/docs until the specs are generated from the right place [20:19] This is a bit weird.. it sounds like juju/docs not only offers no advantage, but is an additional burden only [20:22] I think the eventual goal is to have the possibility of another team owning it [20:22] so ~juju-docs can work on the documentation [20:23] (a hypothetical team I made up to support my hypothesis) [20:23] niemeyer: once the docs are generated from lp:juju/docs directly, the double-maintenance wouldn't be necessary [20:24] SpamapS: Yeah, I understand the end goal, it just sounds like we've made a detour that isn't necessary for it [20:25] SpamapS: We can just take the actual doc files, put in a new branch without the code, and maintain it there from now on [20:27] thats exactly what we did.. [20:27] but the step of generating the online displayed version has not completed [20:28] SpamapS: Ok, maybe I misunderstand then.. you seemed to indicate that docs were still being merged in lp:juju, and that this was merged onto lp:juju/docs afterwards? [20:29] Well they will need to be if you want them to be displayed on juju.ubuntu.com [20:29] (which is why they haven't been rm'd from lp:juju just yet) [20:29] * SpamapS checks on status of well known RT ticket [20:30] SpamapS: Understood.. we can publish our own docs elsewhere meanwhile [20:33] hmm.. not so well known.. I think hazmat opened a ticket but I can't seem to find reference to it [20:33] hazmat: whats the ticket to re-direct juju.ubuntu.com/docs to build from lp:juju/docs ? [20:34] SpamapS, https://portal.admin.canonical.com/48456 [20:34] SpamapS, i amended the original request for a cron job from october [20:34] which was still open [20:34] i'm a little confused as to the delay [20:35] OH [20:35] so it is that one [20:35] I thought I was mistaken [20:36] hazmat: since its your ticket, could you bump the vanguard to take a look? [20:36] its lamont.. he'll nail it [20:36] * SpamapS goes to find food [20:38] SpamapS, ok [21:14] hazmat: https://codereview.appspot.com/5570047 [21:14] hazmat: It's the same old formula store specification, but revised and cleaned up to reflect what we implemented and the whole renaming [21:14] niemeyer, cool [21:16] niemeyer, one thing that would be off interest is having a notion of multiple ppas per user [21:16] right now we just have the single namespace/ppa per user [21:16] hazmat: Yeah, that's coming [21:16] hazmat: But that's a follow up [21:16] hazmat: There are several ways in which this spec/feature will have to be expanded [21:17] hazmat: But these only matter right now if they'd change what's there [21:17] (as in, being incompatible) [21:19] hazmat: And this adds .lbox to the repository, for better supporting lbox: https://codereview.appspot.com/5575046 [21:20] nice [21:22] hazmat: So LGTM it there, and I'll lbox submit it :) [21:23] niemeyer, i'll definitely have a look, but probably not till latter today or early tomorrow, i've got a few other reviews i'm trying to catch up on atm [21:23] hazmat: I meant the latter one [21:23] hazmat: It's a one liner [21:23] niemeyer, LGTM ;-) [21:23] niemeyer, the first one mostly looks the same on a casual review , so should be straightforward [21:24] hazmat: There, please [21:24] hazmat: Doesn't matter much for this case, but that's the workflow.. lbox submit picks up your presence in the discussion [21:25] ah [21:27] hazmat: See the message now: https://codereview.appspot.com/5575046 [21:27] hazmat: Same message goes onto the commit [21:31] niemeyer, nice, lbox rocks [22:00] rust and go have some similiar high levels === franciscosouza is now known as fsouza [22:48] hi, I'm trying to use juju with openstack... I get it to start bootstrapping, but it never finishes. All I get is : Environment still initializing. Will wait. [22:48] any ideas on how to debug this? [23:01] pindonga: Have you tried to run in verbose mode? [23:01] pindonga: juju -v bootstrap [23:11] <_mup_> juju/relation-already-exists-error r444 committed by jim.baker@canonical.com [23:11] <_mup_> Better error message [23:12] <_mup_> juju/relation-already-exists-error r445 committed by jim.baker@canonical.com [23:12] <_mup_> Merged trunk [23:17] <_mup_> juju/relation-already-exists-error r446 committed by jim.baker@canonical.com [23:17] <_mup_> Fix add-relation test [23:54] pindonga: do you see your instances starting up?