Incorporate readme instructions into setuphost target about automation HOT 2 OPEN

@jdsn @bmwiedemann any feedback on this?

from automation.

docs/mkcloud.md has a number of one-time setup tasks that really make sense to incorporate into the setuphost target. This includes:

installing and enabling libvirt if necessary

already implemented:
https://github.com/SUSE-Cloud/automation/blob/master/scripts/lib/mkcloud-driver-libvirt.sh#L116

installing and enabling virtlogd if necessary

https://github.com/SUSE-Cloud/automation/blob/master/scripts/lib/mkcloud-driver-libvirt.sh#L144

Both services are only started - not insserv'ed, so this could be added easily.

creating a suitable local disk file and performing losetup, if necessary

That is only a workaround for the rare cases.
The usual choice should either be to use a dedicated disk (then set cloudpv=/dev/<diskname>) or to use an existing LVM (then set cloudvg=<yourLVMname>)

The size of the sparse file depends on what you want to deploy and where you put it and how much space you want to reserve for it. Thats impossible to know. So rather create the sparse file manually, because you know your requirements.

Please note: setuphost is preparing a host for mkcloud deployments in general - not for a specific deployment or cloud configuration. So there is no configuration to derive anything from.

setuphost should be idempotent, of course, so that it can be re-run without harm.

Where is it not idempotent?

As a further exercise, it would be nice if setuphost were included in the default list of those targets that expand to lots of steps. e.g. all, plain, etc.

We extracted it intentionally from these expanding steps. Because it is only needed to run once per host. Rerunning it would be a waste of time.
Furthermore it would be impossible for intended use case that mkcloud is run as normal user. The single setuphost run has to be run once as root however. But all mkcloud deployments can be run as normal user.
So the intrusive changes need to be run as root. All actions that are run via sudo for a normal deployment must be non-intrusive (must not destroy anything).

So, my take away is, to add the "insserv"

from automation.