Cloud-init

[a3s7p]

If inithooks does not recognize the usual shebang (#!), it passes the data to cloud-init. This allows us to parse all the other formats. If the userdata is the usual format with a shebang, cloud-init never gets called.

This has not been tested for cloud providers other than EC2.

[vondrt4]

I'd like to point out that I have already submitted a version of buildtasks that integrates cloud-init for the Openstack build #23. It's already at version 3 and quite well tested in our cloud. Interaction between cloud-init and inithooks is managed by
a) turning off cloud-init modules that duplicate inithooks work
b) strictly managing precedence of the two within systemd (cloud-init has three phases)
To compare the two approaches:

Comparison:

Start mode	Function	vondrt4	qrntz
no user-data	login name	debian w/key, root warns	root w/key
no user-data	runs turnkey-init	yes	yes
inithooks preseed	login name	debian w/key, root w/pass	root w/both
inithooks preseed	runs turnkey-init	no	no
cloud-config	login name	any set by c-i, may enable root	any set by c-i, root
cloud-config	runs turnkey-init	all users	root only
cloud-config	can also do inithooks preseed with write_files	yes	yes
any	sets hostname	to name of instance	to name of appliance
any	resizes root device	yes	no

Any other characteristics that I've forgotten to test?

Bugs:

On OpenStack, I've got to wait for a timeout until it goes to the right datasource.

Sudo is not installed, so the users created by cloud-init cannot do much.

Opinion:

I like the cloud-init first approach, because IMHO it works as users would expect. From our OpenStack catalog, you can run it as any other image, log in with a key and get the customization menus.
With our VPS service, inithooks preseeding is used and you get an appliance all ready to go with passwords in an e-mail.
The small detail that every VPS has its hostname set is also important for us. As soon as we get the Designate component of Openstack implemented, it will also get a DNS name.

[a3s7p]

Thank you for the swift response and detailed comparison @vondrt4.

Actually, the login name is admin and the root device is resized with my changes. This is done by inithooks though, as usual; if your table only relates to cloud-init then that's all correct.

Re datasource delay, you can specify datasources per build to avoid querying ones that won't be present.

[lirazsiri]

Sorry for stepping in so late into the discussion but I finally noticed the email Jeremy sent me to take a look and compare the pull requests, which I missed earlier.

As far as I can tell it looks like Tomas's pull request is:

1. significantly larger and more complex
2. makes TurnKey openstack builds more compatible with Debian conventions (e.g., debian username)

On the other hand, Anton changes the minimum needed to add support to cloud-init with a minimal amount of extra complexity. Unless I'm missing something that sounds like what we want.

[lirazsiri]

OK, I should really read my mail in the opposite order. I see now that we already settled on a hybrid approach for moving forward.