Note that if it fails to spin a host, it will stop. I think this is better
than continuing to the next, because there might be a reason to spin hosts
in some specific order (ie, update dns first and then use it).
When propellor is deployed by uploading the binary, there's no git repo, so
each spin needs to re-upload it to get any config changes. This should be
rare since this is only intended to be used when taking over a host and
getting it properly set up from source, but it still needs to be supported.
Since the containers are no longer on the host list, they were not found
while provisioning, oops.
To fix, had to add to a host's info a map of the containers docked to it.
Unfortunately, that required Propellor.Types.Info be glommed into
Propellor.Types, since it needed to refer to Host.
It was fetching from the central repo, then building that, and then running
the client-to-client git update, and the building after that.
Remove the first build, as all that linking does take time.
Lock a lock file while provisioning inside, otherwise propellor could be
running to init the container when the system has just booted, or the
container was just started from being stopped, and at the same time,
propellor run outside the container chains into it to provision.
Previously, simplesh prevented this in a different way.
While old propellor's can emit Ready, they won't if they've managed to
updateFirst. If updateFirst fails due to eg, inaccessiable central repo,
those old propellor's are not able to receive inline git pushes anyway,
so are not going to update no matter what, so no point in making --spin
work in that case.
Joey Hess