-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
store: Support importing images without /ostree
#887
Conversation
A sticking point keeping ostree in the picture here for containers was SELinux handling. When we started this effort I'd feared rewriting. But recently we changed things such that we label derived images using the policy from the final root. This is a relatively small change in code size and complexity, that allows us to import images that don't have "ostree stuff" in them at all, i.e. there's no `/ostree/repo/objects`. The advantage here is that this significantly simplifies constructing base images. The main disadvantage today for people who build images this way is that we end up re-labeling and re-checksumming all objects. But, the real fix for that in the future will be for us to rework things such that we support `security.selinux` for example as native xattrs in the tar stream. Signed-off-by: Colin Walters <[email protected]>
This was migrated from ostreedev/ostree-rs-ext#674 btw. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
if I understand correctly, there is still a requirement then for the container image to be composefs not just any image can be used? Or any image like ubi could end up being used here?
composefs is something we generate client side; it's not directly related except in that today one needs to explicitly turn on ostree-composefs in the container image's content.
See https://gitlab.com/fedora/bootc/tracker/-/issues/32#note_2201993683 - so yes, one could derive from ubi too. |
I was asked about this PR recently, and just to clarify: I'd consider this PR "supported" in the sense that we will absolutely fix any bugs that arise, and we do have some tests, but it's just less battle tested than the previous path. At some point we will probably try to change fedora-bootc to do this by default, but we have to be really cautious because we need to support people upgrading from old systems where the bootc won't support this. So the overall goal is basically:
(This issue also touches on #640 in that in theory it could help us get out of these bootstrap requirements; the bootc-in-target could handle any fixups) |
A sticking point keeping ostree in the picture here for containers was SELinux handling. When we started this effort I'd feared rewriting.
But recently we changed things such that we label derived images using the policy from the final root.
This is a relatively small change in code size and complexity, that allows us to import images that don't have "ostree stuff" in them at all, i.e. there's no
/ostree/repo/objects
.The advantage here is that this significantly simplifies constructing base images.
The main disadvantage today for people who build images this way is that we end up re-labeling and re-checksumming all objects.
But, the real fix for that in the future will be for us to rework things such that we support
security.selinux
for example as native xattrs in the tar stream.