You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The goal here is to support rpm-ostree install executing in a container. From a user experience perspective we should basically behave the same as yum install. Though there's some debate about whether we should silently upgrade "base image" dependencies.
Implementation
At a technical level, this involves effectively skipping lots of our custom infrastructure that is designed to run under systemd on host systems using ostree. For example, today we run each RPM script in its own isolated container. But because "nested containerization" today requires nontrivial additional privileges granted to the outer container, and is not the norm/default, requiring it would mean we couldn't work where people are using apt and yum today in Dockerfile etc.
We'd need to skip the "check out the base filesystem tree" stage - that's already done.
I think we would still use the custom "import rpm to ostree commit" code - in theory we could write to /ostree/repoand directly overlay to the live /. We could also perform SELinux labeling at this time, because in the Docker/OCI model it's required that derived images are rebuilt to pick up base changes.
There's quite a bit I'm glossing over here really, but we can come back and edit this issue over time.
The text was updated successfully, but these errors were encountered:
See coreos/enhancements#7
User experience
The goal here is to support
rpm-ostree install
executing in a container. From a user experience perspective we should basically behave the same asyum install
. Though there's some debate about whether we should silently upgrade "base image" dependencies.Implementation
At a technical level, this involves effectively skipping lots of our custom infrastructure that is designed to run under systemd on host systems using ostree. For example, today we run each RPM script in its own isolated container. But because "nested containerization" today requires nontrivial additional privileges granted to the outer container, and is not the norm/default, requiring it would mean we couldn't work where people are using
apt
andyum
today inDockerfile
etc.We'd need to skip the "check out the base filesystem tree" stage - that's already done.
I think we would still use the custom "import rpm to ostree commit" code - in theory we could write to
/ostree/repo
and directly overlay to the live/
. We could also perform SELinux labeling at this time, because in the Docker/OCI model it's required that derived images are rebuilt to pick up base changes.There's quite a bit I'm glossing over here really, but we can come back and edit this issue over time.
The text was updated successfully, but these errors were encountered: