Comment 3 for bug 1007419

Hey, thanks for the input fellas. I am under the weather as of now,
but am looking forward to
parsing through your input. Man I hope I get some good rest tonight.

On Mon, Jun 11, 2012 at 8:53 PM, Adam Gandelman
<email address hidden> wrote:
> 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)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1007419
>
> Title:
>  Django-ranbow charm needs review
>
> Status in Juju Charms:
>  New
>
> Bug description:
>  Very basic but a good start to a Django project charm. Needs review
>  for public offering.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/charms/+bug/1007419/+subscriptions

--
Bust0ut, Surgemcgee: Systems Engineer ---
PBDefence.com
BudTVNetwork.com
RadioWeedShow.com
"Bringing entertainment to Unix"