Operator design pattern for systems (yafti++)

[liljenstolpe]

Yafti is a good way to bootstrap a new system, but if you have multiple systems to manage, you will, overtime, get drift between them.

The classical CN design-pattern would be to have your systems have labels (laptop, photo-processing, desktop, work, gaming, etc), then have an operator that would run on each system that would reconcile the current installed apps (flatpaks, etc), git repos, distroboxes with various packages loaded, etc.... against a desired set (say listed in a git repo) based on a selector set of labels in the desired set and on the system. The operator would then do the CRUD operations to keep the correct apps/versions, etc. set across all the systems you manage.

You could then take the idea one step further and start thinking about configs for those, given that flatpaks tend to make dotfiles a bit of a pain. Maybe a central server for config data that can drive templated systems. Oh wait, I think someone did something like that a while back, what was it called again, etc-something..... :) Actually, that would be a metric ton of work to adapt for desktop applications, so probably a bridge to far...

[liljenstolpe]

If people think this is interesting, I'll try and write up some example yaml for the desired state files.

[liljenstolpe]

I suggest we think about the first (install and reconciliation) and ignore the config portion. If we ever want to deal with that, it's definitely chunky enough for a whole other discussion, flame war, end of civilization as we know it, etc.

[bketelsen]

Love this idea. If implemented, security would have to be the first consideration. I'm not turning on a service that installs random stuff from a source I don't control!

[liljenstolpe]

Of course. This is standard CN design pattern. I would assume that the config for the operator would point to a config file/dir/repo that was owned by you. Would be a sane thing to make sure that it was either signed by a trusted entity, or the git checkin was signed, etc.

[marcoceppi]

I'm interested in the idea. I don't have that use case personally, but I can see the need to administer multiple machines, using something like a ublue based system. If that's an extension of Yafti, a superset of Yafti, or something entirely different I'm in support of. I'm about to go through a re-work of the yafti project to split core from the graphical installers. The goal being to have a yafti.core, yafti.cli, yafti.gtk, yafti.kde, etc that all implement the core functionality and allow porting yafti to different runtimes where GNOME / GTK aren't implicitly already installed

[liljenstolpe]

No reason to re-invent the wheel. Probably extend. Really there are two things where it extends what Yafi does today.

• A reconciliation loop
• A selector (i.e. this sub-section of the yafi config only runs on node(s) that are flagged as 'bob', and this sub-section are only run on node(s) that are flagged as 'alice' AND 'charlie').

The concept for the second can be seen in k8s as the 'node-selector' concept.

Christopher

[liljenstolpe]

@marcoceppi - you may have the use case, even if you only have one machine. If you use this model, then, when you want to install another application, container, etc, you do so by updating the 'yafti' file and letting the reconciliation loop pick it up and do the install.

That way, when you have the inevitable disaster (laptop gets backed-up over, or you leave it in the trunk of your car in San Francisco) and you install you new one, yafti installs to your last state, not the original state. It drives a current idempotent system configuration.

[marcoceppi]

yeah, I totally understand what you're getting at :D I'd be interested to see what you come up with for a YAML design. It would be easy enough to define package "groups" / roles and use that for the software selection screen. Keeping the UI workflow file separate from the "roles" software groups file so that the software groups file could be updated over time and not need to evaluate the first time installer gui config.

Not to be too much of a heretic but it's pretty much ansible lite ;)