Comment 4 for bug 1229377

Thank you for this. I'd like to see this land in the story sooner than later but to my mind there is one central issue that is a blocker still.

It is laudable to try to configure the database based on the presence of the database relation, however the way this is done now it seems to represent a way to lose data (start with sqlite, blog for a while, add a mysql relation later). There is no mirgation. I'd suggest rather than do it this way make it a config setting and then make the service start depend on having a relation to the mysql database and all the valid keys before starting. If the config setting is mutated after the service is started you can throw a warning or an error indicating that the operation would result in data lose and isn't supported. start would be a noop and you'd check conditions in both config-changed and relation-changed to decide to start.

For config.url some ideas, if there is nothing on the balance interface the url can safely be defaulted to the unit-get public-address, it is only if something binds to that interface that you need to use/set url. In those cases one option, if the config.url isn't set, is to default it to the <public-ip>.xip.io of the remote balancer endpoint as that should resolve to a working deployment.

Knitpics

Is there a reason not to default to port 80? Even if you put a proxy in front of this that should be fine. Anyone experimenting with this is likely to want the default to be to serve traffic on the defautl port.

What is the use-case for not using host: 0.0.0.0 as the bind address, shouldn't that be fine? Can you drop the option?

Thanks for sticking with this, if any of these suggestions seem out of place I'm happy to talk them over, here or online.