[Spike] Investigate solutions for kairos-init alternatives

[jimmykarily]

Before we jump into implementing our own solution, let's first do some research for tools that could satisfy our needs.

We are looking for tools that:

• can install software on different distributions
• leave not traces behind after they are done
• Don't bring a lot of dependencies (ideally should be just one binary + recipe)
• have a "good" licence (so we can use)
• have a good community (so they don't go out of business soon)
• Can run in a container build step
• Can bundle binary/static files in a single binary, and be self-extracting

[mauromorales]

Here are some tools to check:

• https://www.pulumi.com/docs/
• https://cuelang.org/docs/
• https://github.com/purpleidea/mgmt
• a plugin in terraform? https://developer.hashicorp.com/terraform/plugin

[Itxaka]

Here are some tools to check:
* purpleidea/mgmt

this looks good 👀
EDIT: but doesnt fit :(

Want to add as well chef-solo, which is chef-infra but without any remote servers or anything.

Pros:

• deps are minimal
• most flavours have packages for chef so its easy to remove and cleanup afterwards
• should cover our use case properly
• Lots of community cookbooks, so not much to invent

Cons:

• ruby
• Cookbooks are a bit of a mess
• Databags, yikeeeees, I hate them
• It requires some config, not sure how to bundle it/handle it (ruby frontend wiht config incrusted that calls chef-solo internally?)

Also Ansible on the same way
Pros:

• Covers everything we want and more
• Lots of community recipes/roles, so not much to invent
• Some distros may have packages available

Cons:

• I dont think deps are minimal, its python so it may be a mess if we dont have the same install process for all.
• We have to install ansible and run it with a config, which can be messy.
• Probably need to download the recipes on the fly?

[Itxaka]

I wonder if we can just leverage yip to do this with just simple plugin for package installs.

will have a quick look and maybe poc

[tbrasser]

not sure if these fit the bill/are worth considering, if not please ignore me 😅

• https://porter.sh/
• https://zarf.dev/

[Itxaka]

I had a look at yip and indeed is doable:

Would looks like this, quick and dirty example:
https://gist.github.com/Itxaka/350ea3a28363761907f13f40e5e4b21d

This shows:

• yip running packages install, systemctl services, files being clean and validation
• shows how we can use the stages to declare the system state in code directly
• how we can create custom stages and custom plugins easily

this:

• does not use the DAG, as I wanted to show custom plugins and stages 😛
• shows also that the IfConditional available is not good enough for us
• shows that we should be able to create our own and easily change it so we can do ifs based on whatever we want (IfOS, IfArch, IfVersion, etc...)
• any plugins only needed for the init stuff could be in the init repo, we used to do something similar in the agent for the partitioner: https://github.com/kairos-io/kairos-agent/blob/main/pkg/cloudinit/cloudinit.go
• and I think the main issue is that we may need to change yip to add a new method to accept and generate the dag via bytes directly or stages, instead of via files as its pretty hardcoded currently to read files in the system always

[jimmykarily]

not sure if these fit the bill/are worth considering, if not please ignore me 😅

* https://porter.sh/

* https://zarf.dev/

Looking at porter, it would be a good choice if we had more than one "application" to install. Porter will need to call something that knows how to install the kairos bits. If that tool exists, we don't need porter to call it.

Zarf itself, seems to handle the lifecycle of an application (through onCreate, onDeploy, onRemove actions) but in our case, installing the Kairos bits on an image is always gonna be an one-off thing. We will never want to de-Kairosify an image.

I think these are nice tools but were created for a different purpose. Please correct me if I missed something.