-
Notifications
You must be signed in to change notification settings - Fork 26
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
#674
base: main
Are you sure you want to change the base?
Conversation
Pairs with ostreedev/ostree-rs-ext#674 to enable consuming containers that don't have `/ostree`. Signed-off-by: Colin Walters <[email protected]>
Pairs with ostreedev/ostree-rs-ext#674 to enable consuming containers that don't have `/ostree`. Signed-off-by: Colin Walters <[email protected]>
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.
Looks like the same testing failure as #673 but apart from that it builds and tests for me. LGTM but I'm going to keep reading and digging in because there's a lot here that I'm not familiar with.
Pairs with ostreedev/ostree-rs-ext#674 to enable consuming containers that don't have `/ostree`. Signed-off-by: Colin Walters <[email protected]>
b239fdc
to
554d777
Compare
Pairs with ostreedev/ostree-rs-ext#674 to enable consuming containers that don't have `/ostree`. Signed-off-by: Colin Walters <[email protected]>
I'm picking this one back up, fixing conflicts and adding tests |
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]>
554d777
to
3c4eb7b
Compare
OK rebased 🏄 and now with tests! However, something kind of left open here is basically nailing down things like:
|
Pairs with ostreedev/ostree-rs-ext#674 to enable consuming containers that don't have `/ostree`. Signed-off-by: Colin Walters <[email protected]>
OK for reference, this gets to running with
So we can use this as an optimization target. |
Although moving back to draft as this technically breaks semver, and I'd like to do another release with other fixes before we do this one. |
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 exampleas native xattrs in the tar stream.