marcoceppi

MAAS can already manage virtual machines to an extent (through libvirt) but adding storage support would be awesome.

Sorry, they're releasing images in two days. Seriously, though! Not everything has to be instant. They're putting themselves out to gauge interest and probably lure OEM vendors to their booth at MWC.

Sorry another contender is providing you with a choice. Good thing you know how to exercise it.

They're releasing images for this and the phone in a week.

Sure, you can use dpkg to orchestrate connections between services on the same machine, but last I checked dpkg isn't aware of other machines running other services and orchestrating the connections between those. Service orchestration between machines is something Juju excels at. It's really server and service orchestration abstracted so that you don't have to worry about what machine is where and connected to who. Juju maintains those relations for you, so it's really more like apt for the cloud.

There are several blog posts about deploying with Juju, I think this was just an announcement about the Charm Store going live. There are some posts on http://cloud.ubuntu.com/tag/juju/ and examples at http://juju.ubuntu.com/

Charms require different interfaces, so it depends on the charm. In this case mediawiki has two interfaces, a db (via MySQL) and a db-slave (for MySQL Slave configuration). When you add relations hooks fire on both charms, MySQL creates a username, password, database, and all other basic tasks to make a database work for an application, then passes that information to the mediawiki installation. From there Mediawiki charm db-relation hook fires to make sure Media wiki has all of this information in the right configuration files, install the basic MySQL structure for mediawiki, and several other tasks needed to make sure Mediawiki is installed.

On the flip side, adding a relation to haproxy, additional hooks fire in each charm. Mediawiki tells haproxy the address and port it's running on and haproxy hooks take care to ensure it's in the loadbalancer configuration.

What's excellent about these relationships is as you scale mediawiki to meet demand (juju add-unit mediawiki) all of this relation data stays in tact. So each additional unit will automatically fire the proper db hooks and loadbalancer hooks making sure every unit is setup exactly like the previous (in the case of MySQL, they'll be sharing the same MySQL database but it will skip re-installing the db for every unit) and HAProxy will loadbalance between each unit.

Same happens when you juju remote-unit mediawiki all the relavent hooks fire and each unit is removed from HAProxy.

Containers spun up depend on the provider, so if you deploy to Amazon it's going to spin up an AWS instance. However, if you're deploying to an Open Stack provider it all depends on the Open Stack configuration. Juju doesn't quite care what the provider does with regards to virtualization software.

However, for development you can setup a "local" provider (http://askubuntu.com/questions/65359/how-do-i-configure-juju...) and deploy to your own machine using LXC. This makes development quick and affordable and makes it easy to test drive Juju without needing to use a cloud provider.

It's more service orchestration. So it's a collection of charms to deploy services in to the cloud. Heroku and Google App Engine are more PaaS Platform as a Service, Juju more designed to deploy to Cloud providers like Amazon, Open Stack, and bare metal.

As for different distros Ubuntu is the only distro that Juju has been tested on, though Juju is all Python so it likely wouldn't take much to port and maintain Juju to other Linux distributions. As for the charms most all are reliant on apt-get so Charms for different distributions that used other package management software, then charms would need to be updated to use those instead.

This does more than just package installation, it operates at a higher level. A service may require several packages that need to be installed, configured, then configured to work with each other. All of that is captured in a charm giving you a way to easily deploy a service. So capture your start to finish setup for any service you use in a charm and you can no deploy, and scale that service, using Juju.