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