Rebuilding services from backups.

[Stuart Bishop]

We have been migrating some environments from one cloud to another,
which includes PostgreSQL services.

Objects in the database end up owned by users named after relations.
Client charms could fix this ownership when they create the objects,
but in practice they generally won't bother.

Restoring the database into the new environment is non-trivial, as the
relation ids will not be the same and the usernames will not be the
same, and thus the ownership of the objects incorrect.

This isn't really a problem for the PostgreSQL charm. Features are in
place to handle this, so I just need to document the burden placed on
clients to a) use the 'roles' feature to manage permissions and b) set
the ownership of the database and objects to a role that matches your
security model.

It would be nice to reduce this burden.

Do you think a charm should backup relevant charm state along with
application data? It seems suboptimal, as each charm would need to
implement this.

Is there something juju could do to help with this? Perhaps allowing
an environment to be exported and imported, so it gets recreated with
its current state? I'm not sure if that is really possible, as the
charm state (eg. relation setup and settings) may be tied to
application state (data in the PostgreSQL database) and restoring the
charm state without application state would be just as broken as
restoring the application state without the charm state. Perhaps we
need 'export' and 'import' hooks, so 'juju export' and 'juju import'
commands could snapshot and rebuild a service. This would be useful
for migrations, as well as duplicating a running environment for
running tests against. One spanner in the works is the application
state could be a multi-terrabyte database dump, making it difficult to
deal with.

I imagine the MySQL and MongoDB charms would have similar issues,
pretty much anything where ownership is tracked or passwords are
stored encrypted but need to be provided in plaintext to client
charms.

-- 
Stuart Bishop <stuart.bishop at canonical.com>