In my previous post, Jorge Castro commented that a new super wordpress charm is in the works, and I want to keep working on my blog site configuration (theme and plug-ins) without missing out on any updates. This means that I needed to stop forking the wordpress plugin and find a way to just use the one in the charm store and then ,onto the same instance, roll-out my configuration.
I mentioned that I might try splitting my configuration out into a Subordinate service, and that is what I done It was actually pretty easy.
I created a new charm called wordpress-conf. I set the metadata.yaml file to contain:
name: wordpress-conf summary: "WordPress configuration" subordinate: true description: | Provides configuration for wordpress blogs - Plugin: - WordPress importers - super cache plug-in requires: logging: interface: logging-directory scope: container juju-info: interface: juju-info scope: container
As you can see it has a line calling out that this charm is a subordinate, and has two requirement. The two requirements are for testing purposes really. The “logging” requirement is an explicit requirement that the charm that you are “subordinating” to must have defined, while “juju-info” is an implicit requirement that is define for all charms. What this mean is that using “juju-info”, I can deploy my charm against any service. The key is to define the scope as container.
The magic happens not when you deploy a subordinate charm, but when you add a relationship to another service. For example the following commands result on a wordpress instance setup following the WP charm in the charm store, but with my plugin and theme set up:
juju bootstrap juju deploy wordpress juju deploy mysql juju add-relation wordpress mysql juju expose wordpress juju deploy --repository=~/mycharm local:precise/wordpress-conf juju add-relation wordpress-conf wordpress
Pretty cool, eh!? I should be able to upgrade the two charms now independently