Juju Charms Collection

Bug #1007419
Comment #2

Comment 2 for bug 1007419

Revision history for this message

Adam Gandelman (gandelman-a) wrote on 2012-06-12:

So, I'm a little bit worried about the use of an essentially no-op service that only exists to pass relation data to another unit that will be doing all the work. It seems a bit wasteful, as we'll need to spin up 2x the resources (read: $$$) for a single application, and half of that will be doing *nothing* after its been related. I'd love to see the functionality of this charm merged into the main django-rainbow charm in some way. I understand that's a bit difficult to do and still support many applications on the same rainbow server. Without Juju support for passing in arbitrary and variable-length config, it certainly gets tricky.

One idea that comes to mind would (AFAICS) support the current functionality of the pair, but with a single django-rainbow charm:

- Move all of the config options of the stripe charm into the config.yaml of django-rainbow, all defaulting to null.
- The current 'rainbow-relation-changed' hook becomes part of the config-changed hook of django-rainbow. Instead of calling 'relation-get', call 'config-get' instead.

Users can then deploy django-rainbow with or without the config options set. After its been deployed, they can set the corresponding application config settings and update the services config. This will trigger a config-changed event and setup the corresponding application. At any point, config-get will show the last installed application. I can picture a user maintaining a repository of config snippets for each application they might want to install. This would make it easier to manage config changes for installed applications later on. As it is, you'd have to trigger relation events from config-changed on the stripe side if a user wanted to (say) change something in the vhost config for an app.

My two cents, at least. Leaving in queue to get some input from others.

A side note, I believe its unnecessary to have users copy the charm, and update the metadata with custom name. Instead, you can 'juju deploy --repository=. local:stripe stripe-mycoolapp' and have the charm look to its enviromment for its unique name ($JUJU_UNIT_NAME)

So, I'm a little bit worried about the use of an essentially no-op service that only exists to pass relation data to another unit that will be doing all the work.  It seems a bit wasteful, as we'll need to spin up 2x the resources (read: $$$) for a single application, and half of that will be doing *nothing* after its been related.   I'd love to see the functionality of this charm merged into the main django-rainbow charm in some way.   I understand that's a bit difficult to do and still support many applications on the same rainbow server.   Without Juju support for passing in arbitrary and variable-length config, it certainly gets tricky.

One idea that comes to mind would (AFAICS) support the current functionality of the pair, but with a single django-rainbow charm:

- Move all of the config options of the stripe charm into the config.yaml of django-rainbow,  all defaulting to null.  
- The current 'rainbow-relation-changed' hook becomes part of the config-changed hook of django-rainbow.  Instead of calling 'relation-get', call 'config-get' instead.

Users can then deploy django-rainbow with or without the config options set.  After its been deployed, they can set the corresponding application config settings and update the services config.  This will trigger a config-changed event and setup the corresponding application.  At any point,  config-get will show the last installed application.  I can picture a user maintaining a repository of config snippets for each application they might want to install.   This would make it easier to manage config changes for installed applications later on.  As it is, you'd have to trigger relation events from config-changed on the stripe side if a user wanted to (say) change something in the vhost config for an app.

My two cents, at least.  Leaving in queue to get some input from others.

A side note, I believe its unnecessary to have users copy the charm, and update the metadata with custom name.   Instead, you can 'juju deploy --repository=. local:stripe stripe-mycoolapp' and have the charm look to its enviromment for its unique name ($JUJU_UNIT_NAME)