declarative human-editable representation for rpm-ostree client-side operations

[dustymabe]

I've chatted with jlebon and walters some about this before. It would be nice if we had a plain text representation of all the rpm mutations that have been done to a system. All current mutations and all future mutations can be filtered through this representation. This representation can be editted with something like rpm-ostree edit layers, which will open the representation in a text editor and allow for the representation to be modified/written (and sanity checked upon write).

An example would be:

rpm-ostree install foo

text representation now shows:

Added:
    foo # requested by user
    baz #dep of foo
    bar #subdep of foo

text representation now shows:

rpm-ostree install apple

Added:
    foo # requested by user
    apple # requested by user
    baz #dep of foo
    bar #subdep of foo
    seeds # dep of apple
    stem # dep of apple

rpm-ostree ex override remove tmux

Added:
    foo # requested by user
    apple # requested by user
    baz #dep of foo
    bar #subdep of foo
    seeds # dep of apple
    stem # dep of apple

Removed:
    tmux # removed by user

rpm-ostree ex override replace kubernetes

Changed:
    kubernetes 1.2.3 -> 4.2.5 # replaced by user

Added:
    foo # requested by user
    apple # requested by user
    baz #dep of foo
    bar #subdep of foo
    seeds # dep of apple
    stem # dep of apple

Removed:
    tmux # removed by user

One could then rpm-ostree edit layers and change any of the
mutations that have been done to the system or even add more. The
idea is that every mutation distills down into a single representation
of what the final system state should be (as compared to the base
layer).

There are probably many things wrong with what I have suggested so far
but it generated enough good discussion for us to want to create an
issue out of it and have further discussion. Let's do that here.

[cgwalters]

I'd like to consider what an rpm-ostree ansible module would look like. So I'd say we frame this in YAML.

Also as you noted BTW, it's not just layering; for example there's also rpm-ostree initramfs --enable.

[dustymabe]

I'd like to consider what an rpm-ostree ansible module would look like. So I'd say we frame this in YAML.

+1

Also as you noted BTW, it's not just layering; for example there's also rpm-ostree initramfs --enable.

ahh - yep. rpm-ostree edit mutations maybe :)

[cgwalters]

One way I've been thinking of this is to try to be more Dockerfile like. One of the major reasons for the success of Docker IMO is the magical FROM line. One can definitely think of rpm-ostree in a similar way, an rpm-ostree origin with package layering is like:

FROM fedora/27/x86_64/atomic-host
INSTALL emacs git-evtag ...

Except of course INSTALL here is a lot better than RUN yum -y install as e.g. we know how to avoid redownloading packages each time, it's true "layering" in that we (by default) won't allow replacing the base, etc.

[jlebon]

OK this is very similar to my idea in #2326 (comment), to the point where I'm thinking this issue might've been the inception of the idea in my brain and I just forgot about it. Let's keep discussing this in the fresher #2326 issue.