I would actually just use MaaS + LXC or KVM virtualization. You should be able to bring up a MaaS environment, and then do:
juju deploy NEWSERVICE --to lxc:10 And Juju will create a new LXC container on machine 10 and deploy the NEWSERVICE into it. That gives you all the "give me baremetal" when I want it, and it gives you container separation as well. (You should also be able to do "juju deploy foo --to kvm:12" for times when you have a Charm that needs direct device access.) John =:-> On Thu, Mar 20, 2014 at 8:32 PM, Brian Wawok <[email protected]> wrote: > I was chatting with some awesome people in #juju, but having trouble > deciding what to do. I was hoping that people with more juju experience > could tell me the right way to go for what I want to do, or if juju is just > a horrible idea in general and I should do something else. > > I have spent a few days playing Juju charms. They seem cool. I think I can > use some of the existing juju charms in the store, and convert the rest of > my custom apps to juju charms without a lot of work. The question is, how do > I want to structure things in terms of manual vs openstack vs ???? > > Here is what I have: > > Currently own all servers apps run on. Nothing in the cloud, basically want > a virtual private cloud. Say 100 servers I want to deploy 300 apps to. > Random facts about the setup: > * 10 of these servers I want to run bare metal, i.e. 1 juju charm right on > the server. > * 90 of the servers I want to run a bunch of juju charms on them. > * I am leaning towards LXC as a way to separate charms because it seems to > work well, but it is also possible to just shove the apps right on the > server. LXC would just make it a little cleaner by providing some > environment separation, but it would not bury me under having to preallocate > memory and such as I would with OpenVZ or such. > * I always know exactly what I want to host where. So with the --to command, > i will say where an app should run. I don't need any magic in that way. > * I do not need any of the spin up more VMs when busy, spin down when slow > type magic. Happy to just run the VMs I need for peak load. > * I would like to buy a new server, plug it in, and have it available to > deploy apps to with no manual work. > > So any ideas on ways to go? It seems like MAAS is good, it gets servers > installed. Works well for my 10 apps that go right on metal. What about my > other 290 apps? I could > * Deploy multiple charms right to the server, forcing it with --to (seems > easiest, but then I lose the nice separation LXC gives) > * Deploy an openstack charm to the 90 VM hosts, and then use juju to deploy > to it. That means I need 2 juju envionments (MAAS and openstack), and > openstack seems way too complicated for what I need. Do not need 90 GUIs to > manage, with 20 charm bundles. > * Do manual provisioning, and set up the LXC myself. Which may not be too > bad, but I have never done LXC by hand. And is there a downside to doing a > manual provisioning environment on top of a MAAS server? > > Really, I just like how juju local works a lot. i want to expand that magic > to both new hardware from scratch, and to installing to many VMs. > > Thoughts? > > > > > > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
