Hacker News Reader

Comment by jcastro | Hacker News Reader

I fear you didn't read the article, does pacman autoprovision the OS on the cloud for you and deploy it so the service is ready to use?

We're not talking about installing packages on your computer, we're talking about deploying services on a cloud.

View on HN

I didn't get that till you mentioned it. Article talks about deploying to a cloud, but no details. I think the packaging of apt is great, but I don't understand how the cloud deployment fits in.

So pretend it's like apt, but for the cloud.

Instead of deploying a lamp server onto one machine you deploy the service you want to your datacenter. This can either be EC2, your openstack cloud, or local machines.

Let's say you want to deploy a scaleable mediawiki at work:

    juju deploy haproxy 
    juju deploy mediawiki
    juju deploy mysql
    juju add-relation haproxy mediawiki
    juju add-relation mysql mediawiki

And then you have a load balancer, a mediawiki instance, and a mysql instance. You point your DNS to the haproxy instance, and you're ready to go.

2 months later your wiki becomes way popular. Since you're on the cloud you're totally elastic, so you can go "juju add-unit mediawiki" and you've got another mediawiki node load balancing. Or do "juju add-unit n=10 mediawiki" and have 10 nodes ready to go.

If you're on AWS, each of those deploys fires up an instance. Same on OpenStack. If you're on bare metal the Ubuntu orchestra server on your network will turn on machines and install/provision them to do the equivalent.

What does "add-relation" do, in terms of what happens on the machine? Do different charms need to be coded with explicit relation types?

Like could I simply switch postgres for mysql in your example and have it work, or does mediawiki specifically need a relation to a mysql?

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.

your comment here should have been the blog post, or at least the condensed version of it that better explains the actual technical benefits.

that is cool.

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/

Reply on news.ycombinator.com