=== andrewsmedina_ is now known as andrewsmedina [05:13] <_mup_> juju/enhanced-relation-spec r20 committed by jim.baker@canonical.com [05:13] <_mup_> Address review points [05:29] <_mup_> juju/enhanced-relation-spec r21 committed by jim.baker@canonical.com [05:29] <_mup_> Remove enhance, important, and flexible word usage [05:41] <_mup_> juju/enhanced-relation-spec r22 committed by jim.baker@canonical.com [05:41] <_mup_> Clarify relation-info command [05:59] <_mup_> juju/force-upgrade r461 committed by kapil.thangavelu@canonical.com [05:59] <_mup_> unit agent forced upgrade support [06:20] <_mup_> juju/force-upgrade r462 committed by kapil.thangavelu@canonical.com [06:20] <_mup_> dont execute upgrade hooks on a forced upgrade [07:58] Hi all, just discovered juju and I think it's really cool. Out of curiosity, could you run juju with a local provider (lxc containers) in production? [07:59] i.e. use the local provider feature but expose the services to the world instead of for development. [08:00] dylanvee, its not the intended usage, but sure you could, you'd have to bridge the networking by hand though [08:01] hazmat: Cool. In that sense it seems like a really nice layer on top of lxc, which is what I was looking for [08:01] dylanvee, cool, some people use it as a nice layer on top of ec2 ;-) [08:02] hazmat: You could do juju within juju, use it to provision ec2 instances which contain many lxc instances :) [08:02] hazmat: fantastic project though, glad I came across it! [08:02] dylanvee, indeed some of the charm testing does just that [08:03] er. automated testing that is [08:03] kind of like https://github.com/Atalanta/cucumber-chef === almaisan-away is now known as al-maisan [08:38] <_mup_> juju/increase-session-timeout r449 committed by kapil.thangavelu@canonical.com [08:38] <_mup_> merge trunk === al-maisan is now known as almaisan-away === Leseb_ is now known as Leseb === almaisan-away is now known as al-maisan === marrusl_ is now known as marrusl [15:53] SpamapS: you going to this? http://charmschoolsv.eventbrite.com/ [15:53] SAY YES. [16:19] jcastro: can you give me the details of the webinar to see if I can check it out as well ? [16:19] jcastro: I am if we can get the travel approved [16:19] jcastro: it would be a good idea so i can learn how the masters do the charm school :) [17:10] <_mup_> juju/refactor-machine-agent r460 committed by jim.baker@canonical.com [17:10] <_mup_> Merged trunk [17:12] <_mup_> juju/robust-test-removed-service-unit r460 committed by jim.baker@canonical.com [17:12] <_mup_> Merged upstream === al-maisan is now known as almaisan-away [19:03] <_mup_> Bug #949292 was filed: Redeploying a charm with symbolic links fails < https://launchpad.net/bugs/949292 > [21:12] <_mup_> juju/trunk r471 committed by kapil.thangavelu@canonical.com [21:12] <_mup_> merge add-maas-provider. New juju machine provider for MaaS [a=allenap,julian-edwards][r=jimbaker,hazmat][f=939552] [21:15] <_mup_> juju/upgrade-sym-link r469 committed by kapil.thangavelu@canonical.com [21:15] <_mup_> use unqualified relative as well [21:17] <_mup_> juju/trunk r472 committed by kapil.thangavelu@canonical.com [21:17] <_mup_> merge upgrade-sym-link, remove previous symlink targets before extracting new ones [r=bcsaller][f=941873] [21:19] <_mup_> juju/trunk r473 committed by kapil.thangavelu@canonical.com [21:19] <_mup_> merge bool-and-validate-defaults. New boolean service config option, service defaults are validated during charm parse [r=bcsaller,jimbaker][f=885551] [21:26] <_mup_> juju/deploy-upgrade r459 committed by kapil.thangavelu@canonical.com [21:26] <_mup_> remove some debug cruft [21:34] Sweet, booleans! [22:03] marcoceppi: blimey, NERD ALERT [23:38] How is the stability of juju on 11.10? Ready for production use? [23:39] I noticed in the docs that it might not be, but I wanted to see if that's since changed. [23:39] 11.10? No [23:39] dylanvee: the version in 11.10 has a lot of problems. We haven't been able to update it because there is no way to test proposed updates. [23:39] SpamapS: What about older releases? [23:39] dylanvee: the version in precise is much better.. though I still recommend that people use the PPA version for the best results. [23:39] dylanvee: juju did not exist prior to 11.10 [23:40] SpamapS: Ah yes, ok. [23:40] well, it existed when 11.04 was released, but not in a very useful form. :) [23:40] dylanvee: only recently the PPA version has gained some nice features, like being able to restart the agents. :) [23:40] SpamapS: I see, thanks :) [23:41] Also, from reading the docs it looks like when an ec2 instance is provisioned lxc containers are used within that to start units, is that correct? [23:41] Previously I had thought that lxc was only for the local mode [23:41] But now I'm interested because I'd like to enforce lxc resource usage limits on my charms [23:45] dylanvee: no thats not done [23:45] dylanvee: there's a thought that we might do that in the future, but right now the complexity of the network configuration would be rather high. [23:46] dylanvee: lxc works inside LXC (In theory) sor you should be able to use LXC freely. [23:46] SpamapS: you mean for the local provider mode? [23:46] dylanvee: though.. with it being the cloud and all.. perhaps just choosing the right instance size is a better option? [23:46] dylanvee: you could use lxc containers in a charm. it shouldn't be a problem. [23:47] SpamapS: My goal is to have kind of an elastic fleet of lxc containers that can run untrusted user code. Juju seems like a possible fit for that [23:48] dylanvee: lxc is no better than chroot for containing untrusted code [23:48] SpamapS: it adds a lot more isolation, no? http://en.wikipedia.org/wiki/Operating_system-level_virtualization#Implementations [23:48] dylanvee: there's a goal to get it better than chroot using a combination of better namespace restrictions on some things, and apparmor. But its not there yet. [23:49] dylanvee: a little bit more isolation, yes. But ultimately, its still vulnerable to most of the same jail breaks as chroot. [23:49] SpamapS: Oh, that's disappointing…I know lxc + chroot are the basis for what Heroku is doing [23:51] dylanvee: they also don't allow the flexibility that juju does.. because they can't if they're going to keep using LXC [23:52] http://www.suse.com/documentation/sles11/singlehtml/lxc_quickstart/lxc_quickstart.html [23:52] "LXC is not secure" [23:52] http://berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/ [23:52] "What you’re gaining here is not security, but a rather way to manage resource utilization of everything spawned from that initial process." [23:52] SpacemapS: Well, to put a finer point on it I wanna host a bunch of ssh accounts that won't stomp all over the machine [23:53] dylanvee: give them all a t1.micro then. [23:53] dylanvee: if you don't trust the user.. you can't trust containers to keep them from abusing the system. [23:53] dylanvee: note that nested KVM is coming. :) [23:54] SpacemapS: I'm definitely considering that, hopefully Amazon is pretty liberal with requests to have more than 20 ec2 instances [23:54] SpacemapS: ooh, i'll have to look into that :) [23:54] So as soon as there is an openstack cloud provider using KVM on precise.. you'll be able to run nested KVM vms inside their instances. [23:54] dylanvee: SpamapS, not SpacemepS [23:54] SpamapS: Sorry haha. Well thank you, I must go but I appreciate your help! :)