Charm Needed: Gunicorn (WSGI subordinate)

Hi Patrick. Encapsulation demands that you communicate with the other charms via relationships only. This is relatively simple. If, in your config-changed, you want to inform the other side of your wsgi relationships that something is changed, you can do something like this:

for relid in `relation-ids wsgi-file` ; do
  relation-set -r $relid config-md5=`md5sum /etc/gunicorn/myconfig.conf`
done

This works in all hook contexts, not just *-relation-* hooks.

This will cause the other side's "changed" hook to execute. You don't have to use the 'config-md5' value.. you could use a timestamp, someting. Just change some variable. Then the other side will be able to react.

Nice!

I added the "reload trigger" feature by adding a config-changed hook and a wsgi_timestamp configuration variable.

Hi Patrick! This looks like another great charm, thanks so much for submitting it.

First, I love the way relation variables override config variables in a nice cascading way. This will make writing WSGI apps that make use of this charm so much easier.

Issues
--------

* website-relation-joined says port=80, but you go through quite a bit of trouble to find an open port to listen on above 8080 in the wsgi-file-relation-joined. Need to communicate that port, not 80.

* website-relation-joined uses hostname -f, but that is usually incorrect. Use unit-get private-address.

Correct those two issues and this is ready for promulgation.

Minors
---------
* service gunicorn start, then restart in relation hook doesn't make much sense to me, perhaps a comment explaining why
* stop hook does not handle the case where the service is already stopped.
* echo $VAR | sed -e 's,/,,' in bash can also be expressed as ${VAR//\//-} without forking out for the shell/echo/sed.

Oh and please set back to "Fix Committed" when the issue is fixed.

I've moved the website relation back to the applications charms because I didn't found a
way to query the application-port associtation in the website relation of this charm (the subordinate).
It's working the way it is now but I makes the charm less flexible. I'll continue to investigate on a better way
to do it.

Thanks Patrick. It actually usually makes more sense for a primary to provide website anyway since it will have more knowledge of the details of the website.

Promulgated!