Hacker News new | past | comments | ask | show | jobs | submit login

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: