[13:18] <hazmat> g'morning
[13:39]  * niemeyer waves
[13:44] <hazmat> niemeyer, g'morning
[14:04] <niemeyer> hazmat: Heya
=== _mup__ is now known as _mup_
[14:40] <pindonga> morning... so I am trying to use juju for managing lxc containers for development (I know this is not the primary use case for it)
[14:40] <pindonga> the problem I'm facing is that containers do not survive a reboot (I have to destroy the whole env and rebootstrap)
[14:40] <pindonga> I know this is a known issue, but I was wondering if there is a workaround for it
[14:42]  * noodles775 is interested too. I thought by putting my juju-dir somewhere other than /tmp I could avoid that.
[14:42] <hazmat> hmm
[14:42] <pindonga> noodles775, no, I have my data-dir in /home and this is still the case
[14:43] <pindonga> btw I'm running a freshly installed oneiric
[14:43] <hazmat> so there are two issues here, one for hibernation (which is problematic in a different way) and one for reboot, the first one is a work in progress, the second one doesn't have a workaround, it can be done by hand though, albeit its a pretty tedious process
[14:44] <pindonga> another issue I have is that I don't get lxc containers to start (for some reason cgroup is not mounted automatically by juju)
[14:44] <hazmat> it requires starting zookeeper by hand, and the machine agent, and then starting all the containers
[14:44] <pindonga> hazmat, is this written down somewhere?
[14:45] <hazmat> juju will need to write out an upstart job per environment to make this a bit cleaner
[14:45] <hazmat> and automatic
[14:47] <hazmat> pindonga, its not written down, i'm finishing up an email atm, i'll see if i can put together a workaround after
[14:47] <pindonga> hazmat, awesome
[14:47] <pindonga> hazmat, another thing: can you think of a reason why the cgroup is not mounted automatically by juju?
[14:48] <pindonga> may it be that I bootstrapped using distro-series: lucid? (I'm running on oneiric though)
[14:49] <hazmat> pindonga, only the host distro matters regarding the cgroup mount, and juju doesn't handle mounting it, it should be automatic though
[14:50] <pindonga> hazmat, automatic as in? if juju doesn't handle it, does lxc handle it? do I need a cgroup entry in /etc/fstab?
[14:57] <hazmat> pindonga, automatic as its handled by the cgroup-bin package's upstart job
[14:57] <hazmat> pindonga, see /etc/init/cgconfig
[14:57] <hazmat> pindonga, it does not need to be in fstab
[14:57] <pindonga> hazmat, don't have that file., but I have /etc/init/cgoup-lite
[14:57] <pindonga> I run cgroups-mount manually and it's now mounted I think
[14:57] <hazmat> pindonga, yeah.. i think the other one might have been an old natty file.. cgroup-lite looks correct
[14:57]  * hazmat pokes at the packages
[14:58] <hazmat> ah.. ic. cgroup-lite is a minimal set which can support lxc, cgroup-bin also suffices for lxc but has additional cgroup tools
[15:03] <pindonga> ok, got one container up \o/
[15:03] <pindonga> however, the sources file still reads oneiric as the distro
[15:03] <pindonga> :(
[15:04] <pindonga> even though I had lucid in environemtns.yaml
[15:04]  * niemeyer => lunch
[15:04] <hazmat> pindonga, yeah.. there was a bug filed about that
[15:04] <hazmat> bug 886364
[15:04] <pindonga> ah, ok
[15:04] <_mup_> Bug #886364: default-series ignored in environments.yaml <juju:New> < https://launchpad.net/bugs/886364 >
[15:04] <pindonga> tx
[15:15] <brtsz> hi guys
[15:17] <hazmat> brtsz, greetings
[15:56] <hazmat> pindonga, i'm looking at what a workaround would take, doesn't seem like its something that's doable cleanly as a manual script it would need some patching of libraries to record port information, better to just implement per desired direction of using upstart
[15:57] <pindonga> hazmat, yeah... I think I found a workaround for the time being
[15:57] <pindonga> just use plain lxc without juju for my dev lxc containers :)
[15:57] <pindonga> as I don't need juju really for that
[15:57] <pindonga> it was just nice to have it manage my lxc containers too
[15:57] <pindonga> thanks for the help though, it's been really useful so far
[16:08] <hazmat> pindonga, np
[16:13]  * hazmat lunches
[16:30] <noodles775> Is this a known bug? (specifying a config.yaml results in charm not being found, move it out of the way and it deploys): http://paste.ubuntu.com/731083/
[16:30]  * noodles775 can't see any bugs on bugs.launchpad.net/juju for config.yaml
[16:54] <_mup_> Bug #887194 was filed: charm not found on config.yaml parse error <juju:New> < https://launchpad.net/bugs/887194 >
[17:02] <hazmat> noodles775, it was reported with a fix in bug 885515
[17:02] <_mup_> Bug #885515: More verbose error when issue occurs in config.yaml <juju:In Progress by hazmat> < https://launchpad.net/bugs/885515 >
[17:03] <noodles775> hazmat: ah, nice (LP's bug search didn't turn it up, but great that the fix is there already :) ).
[17:03] <hazmat> noodles775, not merged yet, but yeah.. should be in soon
[17:04]  * noodles775 marks his new bug as a dupe.
[19:06] <hazmat> jimbaker, ping
[19:09] <hazmat> hmm.. riak didn't make the hot and hairy list
[20:50] <nolan_d> I'm trying to understand Juju. I'm in a situation where we have a bunch of servers we'll wish to deploy various services on, and I'm wondering if I should recommend it.
[20:50] <nolan_d> Is it still limited to one service per machine as a FAQ I read seems to state?
[20:51] <nolan_d> Feel free to tell me to RTFM, I just need to find a FM to read. :) The one on the Ubuntu wiki seems a bit fragmentary and doesn't really address my questions.
[20:52] <nolan_d> Also, how does it handle the situation where I might want to, say, host a bunch of services at various domains on a cloud? "expose" is nice, but does it give me any way to say "expose this service at this domain/port/service type?"
[21:07] <nolan_d> Back later.
[21:13] <jcastro> https://plus.google.com/b/103184405956510785630/103184405956510785630/posts
[21:13] <jcastro> juju G+ page is up!
[21:37] <hazmat> jcastro, nice
[21:38] <jcastro> adding videos
[21:38] <jcastro> as soon as I figure out how to make it a team manageable page I'll let you know. :)
=== negronjl_ is now known as negronjl