Modularity for extending the host

[jlebon]

Do we want to support users layering packages from modules? This is related to the kube/origin support story (#93); whereas modularity is mostly associated with apps that'd do well in containers, it could also be one way in which we support multiple versions of Kubernetes/Origin. There's of course other modules out there (try dnf module list in f29), but AFAICT the kubernetes, cri-o, and container-tools ones are the most obvious targets for rpm-ostree install support.

If we do go this way, one of the major outcomes would be that we'd need to teach rpm-ostree to support modularity. This is also somewhat related to #77, which is about the base package set, but if modularity is wanted there as well, then it's likely that the rpm-ostree support for this could be shared for both the server side compose and client-side layering.

[dustymabe]

Do we want to support users layering packages from modules? This is related to the kube/origin support story (ticket pending); whereas modularity is mostly associated with apps that'd do well in containers, it could also be one way in which we support multiple versions of Kubernetes/Origin. There's of course other modules out there (try dnf module list in f29), but AFAICT the kubernetes, cri-o, and container-tools ones are the most obvious targets for rpm-ostree install support.

Yep. In my mind modularity is one answer to "how do we support multiple versions" of the few things we care to do that for. kubernetes/openshift, cri-o, and moby-engine (docker) were possible things that we wanted to support multiple versions of.

If we do go this way, one of the major outcomes would be that we'd need to teach rpm-ostree to support modularity.

yeah I think the more fedora becomes modular we would be getting users wanting us to add support to rpm-ostree for silverblue anyways, right? So probably not wasted effort either way.

[lucab]

@jlebon @ajeddeloh @dustymabe side-question: assuming we recommend users to pick their preferred container-runtime version via modularity+overlaying, how would that fit in the first boot flow? That is, can a modularity+overlaying step exist between ignition-files and pivot_root?

[jlebon]

Hmm, that'd be tricky to do since it'd need to create a new deployment. One approach might be to teach rpm-ostree to read drop-in files in /run for packages to overlay and fix up livefs so it all gets applied from the first boot too?

[dustymabe]

One answer we've discussed in the past for something like this is server side package layering, but I don't know how well it fits into what we are discussing here now. With server side package layering the idea is that you define a manifest that builds on top of another ostree branch, similar to a layered container image with a FROM directive. If we did that we could theoretically just build our golden image from a "layered branch" from the repo.

One problem that arises here is that we'd like to have several different components that we are able to swap out (or even remove for people who don't want that functionality) for different versions. moby-engine (docker) and kube/openshift are the two shining examples here.

[dustymabe]

another thought I just had. is that maybe we could implement some of this functionality as portable services. Since portable services aren't containers maybe we wouldn't have the same problems we did in the past when trying to run docker or the kubelet within a container itself. If we were to go this route I think it would be really cool if we could do some "version management" of portable services via hooks in rpm-ostree itself (related to this is the conversation of being able to PIN package versions in rpm-ostree)

[jlebon]

We do support package layering and modularity is just another fancier version of that. rpm-ostree now supports layering modules, so let's close this.