Swift middleware subordinate charms?

[Andrew Wilkins]

On Wed, Sep 24, 2014 at 6:59 PM, Michael Nelson <
michael.nelson at canonical.com> wrote:

> 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.
>

That makes sense. I was coming from the angle of how to do this without
touching any existing charms, which is wrong.

I think to do this right I'd need to modify the swift-proxy and
swift-storage charms, and have them modify their configuration files rather
than having the subordinate do it. The subordinate would effectively just
provide configuration parameters and install the middleware dependencies.
I'll hack around for now, and maybe I'll propose something later if
anything becomes of my charm.

Thanks for the advice!

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140924/87bdd5e2/attachment.html>