Arch: Enable systemd service cloud-init-main

[vdloo]

so that cloud-init can use cidata labeled filesystems again as a NoCloud datasource if provided during boot. see #515 (comment)

[hartwork]

@vdloo I'm happy to apply a related fix, but I need to be more sure this is the right fix. Can you help me understand how you came to conclude that this substitution is the best fix? E.g. in contrast to adding cloud-init-main to the chain? Thank!

[vdloo]

@hartwork I think you might be on to something here, I simply assumed because in this old issue you referred to cloud-init-network as the minimal fix that this cloud-init-main would be a 'more complete fix', but actually I don't know if cloud-init-main should substitute cloud-init-network or if it should just be added to the list. Perhaps the safer option would be to just add cloud-init-main and not remove cloud-init-network?

I did build an image with this branch like this:

cd /home/user/image-bootstrap
. venv/bin/activate
export PYTHONPATH=.
truncate --size 8g /tmp/disk8g
LOOP_DEVICE="$(losetup --show -f /tmp/disk8g)"
python -m image_bootstrap arch "$LOOP_DEVICE" --openstack
qemu-img convert -p -f raw -O qcow2 "$LOOP_DEVICE" /var/lib/libvirt/images/arch-openstack-LATEST-image-bootstrap.qcow2
losetup -d "$LOOP_DEVICE"
rm /tmp/disk8g

and that solved my issue with my cloud-init iso not being used. But by removing cloud-init-network I am not sure if some other functionality would be impacted.

[hartwork]

@vdloo sounds like it needs more research. Can you do that research?

[vdloo]

I looked at the systemd service files for cloud-init and it seems that the currently enabled cloud-init-local, cloud-init-network, cloud-config and cloud-final are all shims for preserving systemd ordering and they just send a message over unix socket to the cloud-init process so it sounds like there would be no harm in keeping cloud-init-network enabled. Reading this commit message here doesn't make it entirely clear to me if cloud-init-main should be enabled, as it reads as if the original cloud-init.service was just renamed to cloud-init-network.service. The changelog here also mentions just a rename and nothing about cloud-init-main. But so the behavior I see is that when I do enable it, it makes a difference in whether that NoCloud configuration works. So as far as I'm concerned I'm happy because I can just build my own images with this change which will work for my use-case. In case you prefer not to risk changing the behavior because it is not completely clear what the right thing to do is, I'm OK to close this pull request.