sysprep: Remove could-init

[dominikholler]

This change improves the usage of cloud images in lago.
If we think the usage of generic cloud images in OST would be a good idea, this change would prepare this.

[mykaul]

I'd mask it instead, as it's faster.

[dominikholler]

I'd mask it instead, as it's faster.

I am not sure what means 'mask', but I disabled cloud-init in a simple and probably distribution independent way.

[mykaul]

delete /etc/systemd/system/multi-user.target.wants/kdump.service delete /etc/systemd/system/multi-user.target.wants/postfix.service Are two examples of masking. It is using systemd, but I assume all our images do (?!) Y.

…

On Sat, Dec 9, 2017 at 10:57 PM, Dominik Holler ***@***.***> wrote: I'd mask it instead, as it's faster. I am not sure what means 'mask', but I disabled cloud-init in a simple and probably distribution independent way. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#682 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEcJ6dKrxEXtKpK7JBSgw1qwgjD0oOG8ks5s-vQkgaJpZM4Q8OFw> .

[dominikholler]

delete /etc/systemd/system/multi-user.target.wants/kdump.service delete /etc/systemd/system/multi-user.target.wants/postfix.service Are two examples of masking.

This way of disabling are used for specif el or fc versions. The change proposed here would affect all linux distributions.

It is using systemd, but I assume all our images do (?!)

I see no reason here to have a dependency to systemd, even it would not hurt. Additional there are 4 *.service links for cloud-init in /etc/systemd/system/multi-user.target.wants and I have no idea if they depend on cloud-init version. Because the [cloud-init documentation](http://cloudinit.readthedocs.io/en/latest/topics/boot.html#generator) suggest to disable cloud-init by the /etc/cloud/cloud-init.disabled or kernel command line, I think we should disable cloud-init like this.

[ifireball]

I'd really rather someone goes ahead and implements full cloud-init support for Lago rather then workarounds. I think various pieces of this work had already been done in the past.

[gbenhaim]

1. There is a WIP of adding cloud-init support to lago: [WIP] clod-init: Adding cloud init support #651
   (actually its almost ready, just need to add some unit and functional tests).

2. I don't think that disabling cloud-init should be hard coded.

3. We can use the build section in lago's init file in order to disable cloud-init. http://lago.readthedocs.io/en/latest/BUILD.html

4. The following list of symlinks can be used in order to disable cloud-init:

link /dev/null:/etc/systemd/system/cloud-init.service
link /dev/null:/etc/systemd/system/cloud-init-local.service
link /dev/null:/etc/systemd/system/cloud-config.service
link /dev/null:/etc/systemd/system/cloud-final.service

[dominikholler]

3. We can use the build section in lago's init file in order to disable cloud-init.
   http://lago.readthedocs.io/en/latest/BUILD.html

This is great! This way we can disable could-init per image and this makes this change obsolete.

Thanks for the discussion, I will go on in https://gerrit.ovirt.org/#/c/85170/, because no change to lago seems required.