Merge the agent into elemental-cli?

[Itxaka]

• elemental-cli has been hard forked and requires a new name
• elemental-cli functionality is going to be splitted into the runtime actions (install, upgrade, reset) and the builder actions will go into osbuiilder (iso, image, etc..)
• Feels weird to have the code for the building pieces and the agent in the same repo

---

• Rename elemental-cli to kairos-agent
• Merge functionality from the agent into the elemental-cli so it only deals with runtime stuff (install, reset, interactive-install, etc..)
• Remove agent from kairos repo
• Push the kairos-agent-ng or whatever the name is as docker images
• Bring those parts into the kairos build like we do with elemental or install it as a package with luet

---

• Separation of concerns, kairos build stuff in one repo, kairos lifecycle management in another
• No longer depend on 2 binaries
• No longer have to sync 2 binaries (bump elemental with new functionality, bump kairos-agent to sync with that)
• Ease of managing, kairos is pinned to version X of the agent, can be bumped anytime explicitely
• No more rebuilding the whole thing on minor changes, explicit triggering of builds for kairos changes
• agent is no longer bound to kairos, so you can build your image with a different one or with your own version easily (just change repositories)
• no more subcalling elemental from the agent, fully integrated binary

---

• Changes to the agent are not automatically end2end tested like currently.
• Testing branch changes is more complicated (immucore-like workaround can be added to avoid this and be able to test branches)

---

The only problem of not auto tested can be fixed easily with triggers or webhooks from one repo to the other. Also minimal end2end testing can be easily set up on the elemental-cli repo by using the framework images and adding the new kairos-agent in there, one flavor, all tests. Speeds up development as well, only when bumping versions of the kairos-agent package itself the full end2end of all flavors would be tested under kairos.

No only that but with the current automation, packages can be made to track the sha of the repo, so they keep being created and repositories auto bumped.

IMO this is the way to go, lets integrate the agent with the pieces that we need in elemental-cli, remove go code from the kaiuros repo and leave the real building pieces only and treat kairos-agent as what it is, another piece in the final kairos system.

Lets goooooo

[mudler]

I'd be tempted to say yes! and it is sounds the way to go to me but we need to pick this up in the dailies/office hours to let the team discuss this as well.

I have been thinking at this time to time, but I always refrained to go into this direction mostly for few reasons:

• 90% of the code changes mostly happens on the agent rather then the installer, that make the development and local iteration veeeeeery quick compared to having a separate binary to handle all the way in
• separation of concerns - can I have the agent with a different version of the binary, without going the hoops of rebuilding the golang binary and pinning? now you can easily as somebody can just replace the installer or the agent binary in the image
• no need to expose the full codebase for the agent portion. there is a clear responsibility cut between the two pieces (configuring a system/installing a system)
• if we bundle the agent to the installer, we would start to be really opinionated and the installer wouldn't be much "derivative generic" but, otoh this can be easily fixed by making the agent a little bit more generic (so this can be ignored I think)

So to say, I do agree with you 100%, but I didn't find a good cut in maintenance/dev iteration that satisfied both needs to motivate joining them together so far

[Itxaka]

In any case, I would also accept the agent going into its own repo AND calling the installer/reset/upgrade FUNCTIONS instead of the binary.

There is nothing to gain calling a binary. You mention substituting the elemental binary in the image to workaround some issues but the same is possible with a single agent binary that doesnt call an external binary but a function. You can rebuild it with your patches or fixes and deploy it just the same, only you need to take care of a single piece and can fix everything in a single place.

if we bundle the agent to the installer, we would start to be really opinionated and the installer wouldn't be much "derivative generic" but, otoh this can be easily fixed by making the agent a little bit more generic (so this can be ignored I think)

I dont see this. Agent can be a subcommand. Can even be a different binary that builds on the same repo using the same libs. There is nothing that prevents us from having it separated from the main elemental-cli althougth I would think that is more maintenance work, but it can be done.

Im not saying lets overwrite elemental-cli, Im saying "lets take charge of it". Its the kairos lifecycle manager. We cannot and should not have 2 different lifecycle managers (kairos-agent and elemental cli, what?).

Also, yes we have to be opinionated. This is the kairos lifecycle, used for kairos and derivatives. Same as we fixed where to search for grub binaries because we are providing those binaries, we have to be opinionated with this. If the installer works only for kairos and derivatives...well, sucks for you, but not for kairos. We are not doing a generic distro installer here, we are doing a kairos+derivatives installer/upgrade/reset and it will be opinionated. Not sure how merging the agent changes in there will change that.

no need to expose the full codebase for the agent portion. there is a clear responsibility cut between the two pieces (configuring a system/installing a system)

Maybe we should split that part then? Installer to elemental-cli, agent/runner/configurer/whatever in a different place, even in the same kairos repo as its part of the system build?

Maybe the problem is that the agent SHOULD NOT be the installer. Agent is agent and can be keep at its place, but installing/reset/upgrade bits should move to elemental-cli?

[mudler]

In any case, I would also accept the agent going into its own repo AND calling the installer/reset/upgrade FUNCTIONS instead of the binary.

There is nothing to gain calling a binary. You mention substituting the elemental binary in the image to workaround some issues but the same is possible with a single agent binary that doesnt call an external binary but a function. You can rebuild it with your patches or fixes and deploy it just the same, only you need to take care of a single piece and can fix everything in a single place.

Yes and no - the gain is that you don't have to deal with go mod deps, pinning et al IF you need to manually fix an image, quite old in time, let's say. But I have no strong opinion here, I find that binary split is more maintainable than relying on go.mod/go version quirks.

if we bundle the agent to the installer, we would start to be really opinionated and the installer wouldn't be much "derivative generic" but, otoh this can be easily fixed by making the agent a little bit more generic (so this can be ignored I think)

I dont see this. Agent can be a subcommand. Can even be a different binary that builds on the same repo using the same libs. There is nothing that prevents us from having it separated from the main elemental-cli althougth I would think that is more maintenance work, but it can be done.

Im not saying lets overwrite elemental-cli, Im saying "lets take charge of it". Its the kairos lifecycle manager. We cannot and should not have 2 different lifecycle managers (kairos-agent and elemental cli, what?).

Also, yes we have to be opinionated. This is the kairos lifecycle, used for kairos and derivatives. Same as we fixed where to search for grub binaries because we are providing those binaries, we have to be opinionated with this. If the installer works only for kairos and derivatives...well, sucks for you, but not for kairos. We are not doing a generic distro installer here, we are doing a kairos+derivatives installer/upgrade/reset and it will be opinionated. Not sure how merging the agent changes in there will change that.

Correct, indeed we need to just slightly adapt our focus around that and mainly documentation, I think it's just clarification that we need here, but from a technical point of view I'm fine with.

no need to expose the full codebase for the agent portion. there is a clear responsibility cut between the two pieces (configuring a system/installing a system)

Maybe we should split that part then? Installer to elemental-cli, agent/runner/configurer/whatever in a different place, even in the same kairos repo as its part of the system build?

Maybe the problem is that the agent SHOULD NOT be the installer. Agent is agent and can be keep at its place, but installing/reset/upgrade bits should move to elemental-cli?

I do fully agree. The agent indeed now is not the installer, it just calls the installer accordingly to the settings (e.g. interactively, automatically, manually, etc). It acts as a wrapper just to enhance it before calling it - other then that it's an agent sitting on the system handling configurations, settings and deployment. Nothing to do with installation (except triggering it with the configs, when required). So overall the plan sounds good to me, as long as we keep the domain of the two very well split (and maybe share the common pieces only in the SDK?)

[Itxaka]

Sounds like a plan!

[mauromorales]

Could we do something like what git cli does and tackle both issues? Having binaries for the different commands and a main app which just calls those other commands behind the scenes? Maybe this is a terrible idea, just thinking out loud 😅

Regarding CI, I remember Concourse being pretty good at showing these dependencies and triggering from different sources, internally from the same project or externally from a dependency for example. Not saying that we should switch, just that I think the webhooks would work well, but we might have to work on making that explicitly visible.