Swift middleware subordinate charms?

Michael Nelson michael.nelson at canonical.com
Wed Sep 24 10:59:00 UTC 2014


On Wed, Sep 24, 2014 at 7:52 PM, Andrew Wilkins
<andrew.wilkins at canonical.com> wrote:
> Hi folks,
>
> I've just started looking into writing a charm (possibly two charms?) to
> deploy some middleware to Swift; both the proxy and storage will have
> middleware added. Today was the first time I've deployed any OpenStack
> component, so my terminology could be off.
>
> I imagine a middleware charm would make most sense as a subordinate to
> swift-{proxy,storage}. Are there any existing examples of such a thing? Is
> there a friendly way for the subordinate to tell the swift services to
> restart, or is it just a matter of "sudo restart swift-object-server" or
> whatever?

Hi Andrew. If you're writing a subordinate charm, it'll be relating to
the primary charm via some relation (say middleware-changed) right?
Which I assume you'll need to add to the swift-proxy charm (ie. to
support middleware subordinates generally? Not sure.)

Anyway, normally I think you'd want the primary charm's
(swift-proxy's) relevant relation-changed hook to do the restart
itself when the middleware changes (ie. when middleware-changed is
triggered). This just makes sure that the responsibility and knowledge
of restarts stays within the charm responsible for the service.

Sometimes your subordinate might need to cause a restart even though
nothing else about the relation has changed, which you can do with a
relation-set with an additional timestamp to ensure that the
relation-changed will still be triggered in the related charm which in
turn ensures the restart.

You could of course just have your subordinate restarting the service
itself, but it may bite later on (I think this issue in reverse hit
the gunicorn subordinate charm, which changed the service name and
hence the way restarts happen, but some charms using the gunicorn
charm had done the restarts themselves rather than via the
relationship, causing compatibility issues).

-Michael

>
> Cheers,
> Andrew
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>



More information about the Juju mailing list