[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] <dylanvee> 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] <dylanvee> i.e. use the local provider feature but expose the services to the world instead of for development.
[08:00] <hazmat> dylanvee, its not the intended usage, but sure you could, you'd have to bridge the networking by hand though
[08:01] <dylanvee> 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] <hazmat> dylanvee, cool, some people use it as  a nice layer on top of ec2 ;-)
[08:02] <dylanvee> hazmat: You could do juju within juju, use it to provision ec2 instances which contain many lxc instances :)
[08:02] <dylanvee> hazmat: fantastic project though, glad I came across it!
[08:02] <hazmat> dylanvee, indeed some of the charm testing does just that
[08:03] <hazmat> er. automated testing that is
[08:03] <dylanvee> kind of like https://github.com/Atalanta/cucumber-chef
[08:38] <_mup_> juju/increase-session-timeout r449 committed by kapil.thangavelu@canonical.com
[08:38] <_mup_> merge trunk
[15:53] <jcastro> SpamapS: you going to this? http://charmschoolsv.eventbrite.com/
[15:53] <jcastro> SAY YES.
[16:19] <negronjl> jcastro: can you give me the details of the webinar to see if I can check it out as well ?
[16:19] <SpamapS> jcastro: I am if we can get the travel approved
[16:19] <negronjl> 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
[19:03] <_mup_> Bug #949292 was filed: Redeploying a charm with symbolic links fails  <juju:New> < 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] <marcoceppi> Sweet, booleans!
[22:03] <SpamapS> marcoceppi: blimey, NERD ALERT
[23:38] <dylanvee> How is the stability of juju on 11.10? Ready for production use?
[23:39] <dylanvee> I noticed in the docs that it might not be, but I wanted to see if that's since changed.
[23:39] <SpamapS> 11.10? No
[23:39] <SpamapS> 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] <dylanvee> SpamapS: What about older releases?
[23:39] <SpamapS> dylanvee: the version in precise is much better.. though I still recommend that people use the PPA version for the best results.
[23:39] <SpamapS> dylanvee: juju did not exist prior to 11.10
[23:40] <dylanvee> SpamapS: Ah yes, ok.
[23:40] <SpamapS> well, it existed when 11.04 was released, but not in a very useful form. :)
[23:40] <SpamapS> dylanvee: only recently the PPA version has gained some nice features, like being able to restart the agents. :)
[23:40] <dylanvee> SpamapS: I see, thanks :)
[23:41] <dylanvee> 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] <dylanvee> Previously I had thought that lxc was only for the local mode
[23:41] <dylanvee> But now I'm interested because I'd like to enforce lxc resource usage limits on my charms
[23:45] <SpamapS> dylanvee: no thats not done
[23:45] <SpamapS> 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] <SpamapS> dylanvee: lxc works inside LXC (In theory) sor you should be able to use LXC freely.
[23:46] <dylanvee> SpamapS: you mean for the local provider mode?
[23:46] <SpamapS> dylanvee: though.. with it being the cloud and all.. perhaps just choosing the right instance size is a better option?
[23:46] <SpamapS> dylanvee: you could use lxc containers in a charm. it shouldn't be a problem.
[23:47] <dylanvee> 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] <SpamapS> dylanvee: lxc is no better than chroot for containing untrusted code
[23:48] <dylanvee> SpamapS: it adds a lot more isolation, no? http://en.wikipedia.org/wiki/Operating_system-level_virtualization#Implementations
[23:48] <SpamapS> 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] <SpamapS> dylanvee: a little bit more isolation, yes. But ultimately, its still vulnerable to most of the same jail breaks as chroot.
[23:49] <dylanvee> SpamapS: Oh, that's disappointing…I know lxc + chroot are the basis for what Heroku is doing
[23:51] <SpamapS> 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] <SpamapS> http://www.suse.com/documentation/sles11/singlehtml/lxc_quickstart/lxc_quickstart.html
[23:52] <SpamapS> "LXC is not secure"
[23:52] <SpamapS> http://berrange.com/posts/2011/09/27/getting-started-with-lxc-using-libvirt/
[23:52] <SpamapS> "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] <dylanvee> 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] <SpamapS> dylanvee: give them all a t1.micro then.
[23:53] <SpamapS> dylanvee: if you don't trust the user.. you can't trust containers to keep them from abusing the system.
[23:53] <SpamapS> dylanvee: note that nested KVM is coming. :)
[23:54] <dylanvee> SpacemapS: I'm definitely considering that, hopefully Amazon is pretty liberal with requests to have more than 20 ec2 instances
[23:54] <dylanvee> SpacemapS: ooh, i'll have to look into that :)
[23:54] <SpamapS> 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] <SpamapS> dylanvee: SpamapS, not SpacemepS
[23:54] <dylanvee> SpamapS: Sorry haha. Well thank you, I must go but I appreciate your help! :)