[A JuJu Adventure] Splitting my charm out

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:

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:

4 Responses to [A JuJu Adventure] Splitting my charm out

Looking good man, Looking good. Your off to a rockin start with not a ton a time invested either yet.

I’m sure it wont be long at all if not already that your pushing fixes and/or publishing new charms in the charm store yourself :)

Is there anything major that has jumped out at you yet that just seems like a glaring omission or wrong ? Sometimes its hard to see these things after you’ve been working with something for a while so I think its good to ask those that would still have it fresh in their minds.