We currently have a backup plugin and a restore script that are entirely divorced from the rest of the codebase, and are therefore prone to breaking if core changes.
Moonstone has been tasked with recreating backup and restore as first class citizens of juju. One of the complaints about the current backup is that it requires you to stop your mongo database while we copy the data out of it. This means you can't modify your juju environment until backup is complete (note that it would not actually interrupt the deployed services). There had been some talk about various ways we can avoid the disruption via different methods. Here's my proposal: Let's leave it as-is. Here's why I think it's ok: For small environments, the amount of data to backup is going to be small, and therefore the interruption will be short. In addition, small environments aren't likely to be adversely affected by a short outage, since it only affects the juju state server, not any of the deployed services. And small environments should need less interaction with juju in general. For large environments which may take a long time to back up, they will likely be in HA mode, which means they have 2 or more replica servers in addition to the main server. In this case, you can just stop one of the replica servers, and back up that, with no actual interruption to juju at all. Then the only case that is really a problem is large environments which are not using HA, which should be something we discourage, and uninterrupted backup can be a way to show the benefits of HA. Thoughts? -Nate
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
