[12:29] <nfoata> Hi everyone, does someone knows if it's possible to set the unit status from start to another one (eg: ready, pending, stopped etc.), if I want to remove just for a moment a unit of a service. Thanks
[12:30] <nfoata> or more information about unit status and its modifications (events on them)
[13:20] <marcoceppi> nfoata: you can't manually move a unit to a status without taking action agianst it (ie: actually remove the unit, etc)
[13:45] <_mup_> Bug #1187392 was filed: local provider does not support peer relations <juju:New> <https://launchpad.net/bugs/1187392>
[15:12] <AskUbuntu> This site http://uistage.jujucharms.com:8080/ doesn't work | http://askubuntu.com/q/303995
[17:38] <AskUbuntu> agent-state: pending for over 20 minutes | http://askubuntu.com/q/304040
[19:01] <avoine> do you think "apps-servers" should be the right category for the django charm?
[19:01] <avoine> or just "applications"
[19:02] <avoine> or maybe ['databases', 'app-servers'] since it needs a database
[19:27] <jcastro> I am going to propose "platform" as one
[19:27] <jcastro> since it's like something you would build your app on top of
[22:01] <adam_g_> wedgwood, got a min re: charm-helpers organization?
[22:01] <wedgwood> adam_g_: sure
[22:02] <adam_g_> wedgwood, so i've started porting one of our bash charms to python and have been leaning on the new charm-helpers while i do
[22:03] <adam_g_> i've got a bunch of new storage related stuff that i'll be needing in some of the openstack charms, but they are generic enough to go into core.host
[22:03] <adam_g_> thoughts on moving core/host.py to core/host/__init__.py, and adding core/host/storage/{__init__.py, lvm.py, loopback.py} etc?
[22:04] <adam_g_> possible doing similar things elsewhere?
[22:04] <wedgwood> that sort of stuff sounds very Linux-y. I'd actually recommend putting it outside core
[22:05] <wedgwood> I think core should be as portable as possible (although it needs work to get there)
[22:05] <adam_g_> sounds reasonable. contrib/storage/linux/ ?
[22:05] <adam_g_> of course i can just keep it within contrib/openstack/ until someone else wants to use it
[22:06] <wedgwood> I think either of those are suitable if you're ok with it.
[22:07] <wedgwood> I think it should come out of contrib, but we'll need to think about how we want to organize platform-specific stuff.
[22:07] <wedgwood> I think it's OK to make a charmhelpers.storage that has some non-portable code.
[22:09] <adam_g_> keeping it in contrib/ for now is okay. just trying to organize imports and tests atm
[22:14] <adam_g_> wedgwood, also any chance this can merge? https://code.launchpad.net/~gandelman-a/charm-helpers/openstack_tests/+merge/166612
[22:17] <wedgwood> adam_g_: wow, that diff is wacky. lemme grab a copy and take a look
[22:18] <adam_g_> wedgwood, heh, its mostly just splitting openstack stuff  from contrib.hahelpers  into contrib.openstack
[22:18] <adam_g_> plus some crappy tests
[22:25] <wedgwood> adam_g_: I think I see now. You must have done lots of moving, but not with 'bzr mv' eh?
[22:26] <adam_g_> wedgwood, exactly :P
[22:27] <wedgwood> adam_g_: I'm afraid there's one change that you didn't pull. if you'll merge that and re-push I'll merge it to trunk
[22:28] <wedgwood> adam_g_: it's a couple of lines in charmhelpers/core/hookenv.py
[22:31] <adam_g_> wedgwood, hmm? i see no diff between hookenv.py in my branch and that in trunk?
[22:31] <wedgwood> yeah? when I merge I get a regression
[22:32] <wedgwood> adam_g_: bah, never mind that
[22:34] <wedgwood> adam_g_: merged
[22:35] <adam_g_> wedgwood, thanks