The purpose of this plugin is to use the backup file from bug 1254572 and a provisioned machine from bug 1254574 and bring up the juju database and agents to be internally consistent.
The ordering of things to be done is very specific.
The restored files can be brought back onto the vanilla system.
The juju-db service then needs to be started, and the address and instance id of the machine need to be updated:
* in the “machines” collection in the “juju” database, change the “instanceid” field of the document whose _id is “0” to the new server’s instance id, in the “instanceData” collection, do exactly the same
* the address stored for machine-0 needs to be updated as well to the new addresses for the machine
Next the following steps:
1. update the provider-state file in the provider storage with the new
address
2. update the addresses in the local juju agent configuration files to
refer to the new machine. I'm pretty sure that the machine agent
configuration file points to localhost, but any unit agents would have
the hostname (I'm fairly sure).
3. Somehow munge the status of units that may have been installed on machine 0, or containers on machine 0 to say they are non-existent.
4. start the juju-machine-0 upstart service, this brings up the API server (in a hopefully consistent state)
By this stage, we should have a working bootstrap node that is internally consistent (with the caveats around units that may have been deployed on the bootstrap node).
The address propagation is handled by a different plugin described in bug 1254579.
The current thinking is that this needs to be documented, and tested with manual procedures before we start writing a plugin -- which will be editing quite a few critical data bits, and therefore would be a mess.