[00:50] <xnox> marcoceppi: right, i see how postgresql charm does it, i'll mimick that. i need to kill instances but store results only, and later access them.
[00:50] <xnox> thanx.
[17:12] <lazypower> Would this be a proper application of subordinate charms?  Given the scenario of deploying Gunicorn / HAProxy, making client sites a subordinate unit that are deployed into the GUnicorn instance, to deploy their custom NGINX virtual host, and doing any app setup required like installation of PHP Modules, Ruby frameworks, etc.?
[17:13] <lazypower> Mind you these client sites are small and not expected to scale anytime soon, but with it being a subordinate it would be fairly trivial to scale gunicorn, and by virtue of juju hooks, it would scale the client sites automagically with the parent unit's scale.
[17:31] <rick_h__> lazypower: I think so. I believe this is how the rails charm works. You give it info to pull the source and it builds/runs the application
[17:32] <rick_h__> lazypower: I'm not personally up on how/where the gunicorn charm is for this use
[17:32] <lazypower> I've looked at the rails charm, and I have some questions overall about chef's role
[17:33] <lazypower> Mostly about cookbooks, and if there are going to be community reviewed/maintained cookbooks. They have the potential to really aid the scale out of juju's provisioner, but bloat the review material. I am looking at this from a community maintainability and portability standpoint
[17:36] <lazypower> rick_h__: and thank you for responding :)
[17:38] <rick_h__> lazypower: looking at the gunicorn charm I could completely see a subordinate getting the source, which provides the wsgi file and then setting up the config on the gunicorn charm to point there to serve it out
[17:39] <lazypower> I thought that would be a good way to move forward.
[17:39] <lazypower> I'm thinking I'll whip up a quick charm to show this level of coordination to my boss and make our network maps obsolete with the juju-gui