Consider adding support for CoreOS's Ignition

[bryteise]

Is your feature request related to a problem? Please describe.
I have requests for better cloud-init support in Clear Linux along the lines of CoreOS's Ignition.

Describe the solution you'd like
Evaluate the trade-offs for enabling Ignition as a cloud-init use case option in Clear Linux.

Describe alternatives you've considered
Keep using ucd for all use cases.

Additional context
Ignition seems to require an initrd and is written in go so integration may require making some trade-offs or patching for Clear specific usage.

[ahkok]

from a quick glance at the 2.2.0 specification, I see very little, if not no significant feature disparity with ucd. Stuffing a go binary into an initrd will come at a significant storage cost (10mb+ expected). What is actually needed? IOW what specifically isn't possible with ucd right now that the user requires?

[bryteise]

I'll ping @AntonioMeireles for more feedback here.

[AntonioMeireles]

@ahkok

(IMHO, and only in IMHO) there are several angles here at play ...

• a) learning curve ... ignition has a well know feature set, that is known to work in a wide range of use cases, and - for the common case - is well tested over the most common ones. So, resorting to it, would drop yet another pain point from moving to CL.

• b) TCO (not my call at all, i know)... ucd is yet another thing that CL has to maintain. Does it add enough value to be worth the effort ?

• c) now, let's look here

  • UCD should impose an order on the modules of the user-data file micro-config-drive#30
  • The users module does not support uid and gid micro-config-drive#27
  • Wait for active network micro-config-drive#25
  • Incorporate rudimentary network setup micro-config-drive#22

  and that's without mentioning storage setup which is out of scope in ucd

OTOH, ucd doesn't exists in a vacuum... is part of a deployment pipeline ... whatever gets done in the feature would need to consider what is being re-done/re-factored in that pipeline. So, and given that the installer is being rewritten from the ground (https://github.com/clearlinux/clr-installer) it may make sense to (re)consider its own feature set together with the ucd/ignition one, if not only to drop time to market, lower development costs, etc... And ence, it could also make some sense to simplify/dumbify the installer to basically just handle (deployment) media creation and let also to everything else by something along ignition...

just my humble 0.000000002 € (&& once again thanks and congrats for your all great work!)

António

[ahkok]

ucd implements, in 70kb of ELF, the most important things of cloud-init, which needs a full python stack (80mb) to do the same. This is the entire reason it exists - so we can have truly minimal cloud images.

ucd also implements a standard format. So the learning curve argument is false - it is larger for ignition since even coreos made a cloud-init version themselves that adheres to the #cloud-init standard format. BTW, that's the default openstack format, not something we just made up. AWS also uses this format, and even VMware does.

maintenance: ucd has been a few hours per year of maintenance in the last year, well worth it... I'm absolutely ignoring some bug reports that are not worth the time, like e.g. 30 (just likely isn't going to ever happen, besides, even JSON suffers from this problem!). Some of the bugs are things we can likely implement in little time, though, but it isn't a huge time sink.

Any regression in size needs to be thoroughly discussed. I love seeing new technologies appear that likely can do better, but in this case we're talking 10mb+ off the bat to cover mostly the same feature set, and that's really expensive. Remember our cloud images are under 40mb compressed...