store: If ostree >= 2024.3, retain content in /var
#602
Conversation
| @@ -471,6 +473,7 @@ impl ImageImporter { | |||
| proxy_img, | |||
| target_imgref: None, | |||
| no_imgref: false, | |||
| ostree_v2024_3: ostree::check_version(2024, 3), | |||
There was a problem hiding this comment.
Now of course, we in theory need to care about the case where a new ostree is deploying an old target. But personally, I don't care too much about this; we'll get the new ostree out pretty quickly. And also the emphasis on the bootc side is on self-installing operating systems, which don't have this problem.
There was a problem hiding this comment.
Does this mean we need to make sure not to ship ostree 2024.3 in any version of OCP that has 2024.2 or older and commit only to backports?
There was a problem hiding this comment.
This is a good topic to raise. There's a lot of complexity and nuance here. First, all of this code is really only relevant in the case of deploying a container image with content in /var.
Our stock FCOS/RHCOS images don't have any. Now until the previous change here in #569 we just dropped all container /var content on the floor.
This change is taking it from using systemd-tmpfiles with C+ where we have "add new files" semantics to "at most once" semantics.
Now that all said:
Now of course, we in theory need to care about the case where a new ostree is deploying an old target.
For OCP (and really most cases) we are always going from old ➡️ new, as one would expect.
So I don't think this is a problem.
The bigger thing to do here is to verify that these new semantics for /var work as expected before we do another release.
I plan to add another variant of this behavior in the future, and having a proper structure is better than a single `bool`.
This is intended to pair with ostreedev/ostree#3166 If we detect a new enough ostree version, then by default don't remap content in `/var`, assuming that ostree itself will handle it. In order to unit test this (without depending on the ostree version that happens to be on the host) add an API to the importer which allows overriding the version.
cgwalters
force-pushed
the
support-ostree-var
branch
from
6e80fdf
to
4bcc315
Compare
This is intended to pair with ostreedev/ostree#3166
If we detect a new enough ostree version, then by default don't remap
content in
/var, assuming that ostree itself will handle it.In order to unit test this (without depending on the ostree version
that happens to be on the host) add an API to the importer
which allows overriding the version.