Re: Swift middleware subordinate charms?
On Fri, Sep 26, 2014 at 12:54 AM, James Page wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 24/09/14 12:09, Andrew Wilkins wrote: > > > > 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. > > That sounds like the best approach - we did something similar for > cinder backends - see the cinder and cinder-ceph or cinder-vmware charms. > Perfect, just what I was after. Thanks James. -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Swift middleware subordinate charms?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/09/14 12:09, Andrew Wilkins wrote: > > 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. That sounds like the best approach - we did something similar for cinder backends - see the cinder and cinder-ceph or cinder-vmware charms. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUJEjVAAoJEL/srsug59jDJjsQAJt5XXwvMeCUAl0N5lBHYKQs d/SAz0Wxsi5EoLZkIYl2woJlvwO8/vfeIcBJ3+f6OOG1Xa52An+OHgxi3tSqJfNT dhxOU5aFkiawNrakDofnxxmTxDIZln3IcdCrh3SypB4s6t4yGkeRSzcnXo2AnINH Xt/sTsYtCtZG6aeKjtUp331ITtjtbyz0+WMlSnGRaXUbpmrr5kVcf4R4PMvqAk+Q OjqMle5dSHStT7EkdWSepOXsfxIu7Hb6F9gEuzzNUKi8IhGiuuiprB5uoZ/we31c FXFy8ArL+Q3MG+kuV8SJqD79cxWjPaL0hLKelLo3GWUJN1E+VvaKnREzSqCIgRvW aenbp/cj7Q3WwnS0Cvm2quWSknFc9BvTORk9ITtHWHrcyJ8/snDFlgDZ1whqDS+V ZMkefHMerxpl9tcWayyyq+rHfkiDj9RTzAnmumOp1uM8e8epN4PRm6scQfT8Q7t+ Ywl1MojloYDTaWQFCiNeEIjHY6WEFI5E7Agym/iKwCtnGqFJaWV3LaxSJIHnrBCQ eRDNezVG/gz6wNl/Mv4W1hXRrFHh1Vb1FnkA7lQDBodzeWZdc1otz+vLelsSg8p6 uguxu6193khXYoJQgp33KMK+QvU5tAZq1MWoWVWzzuzPd9aYgdNv1YCS8Lq3+BDb plWkSAOmnCWs/fUTJG/x =gLEx -END PGP SIGNATURE- -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Swift middleware subordinate charms?
On Wed, Sep 24, 2014 at 6:59 PM, Michael Nelson <
michael.nel...@canonical.com> wrote:
> On Wed, Sep 24, 2014 at 7:52 PM, Andrew Wilkins
> 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@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Re: Swift middleware subordinate charms?
On Wed, Sep 24, 2014 at 7:52 PM, Andrew Wilkins
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@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
Swift middleware subordinate charms?
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?
Cheers,
Andrew
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
