Comment 0 for bug 1254577

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).