-
Notifications
You must be signed in to change notification settings - Fork 372
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
Decide on a dir:
compatibility guarantee, if any, and a format transition plan, if any
#1874
Comments
dir:
compatibility guarantee, if any, and a versioning format transition, if anydir:
compatibility guarantee, if any, and a format transition plan, if any
So, |
For the third option - would we have to commit to perpetually support the old versions, or could we just offer a ~12 month migration period and remove support for the old version after that point? |
A request was to target old stable releases (which wouldn’t be updated with a newer consumer). I’m not sure how strong that commitment should be. @achilleas-k ? |
If we start versioning now, old clients would still break, right? I feel/think we will find solutions to add new features without breaking backwards compat. |
From our side, our guarantee is that Image Builder (osbuild) can produce images for any version of RHEL, CentOS, and Fedora currently in support. In the worst case, the producer of the Given the lifetime of the .10 releases (5 years), that's a pretty long support lifecycle that we haven't had to deal with yet. To answer the question directly, "perpetual" support would be nice for us, but I understand that might not be convenient or desirable for you. A shorter support lifetime on the order of a major RHEL release would be workable if we had a long enough deprecation time to work around it. |
If the producer of a For everyone's benefit here, and for posterity, a brief description of our use case: We produce images by pulling a container using the tools on the host into a cache, then they're copied into the build root and are then pulled into the target OS image's tree using tools from the target image's repo sources. When the OS is live, the container is run using tools from the OS itself.
The requirement here is for |
(But, I’m afraid I only noticed this now currently that version file is write-only, and existing clients don’t reject unknown versions. #1876 .) Fundamentally, the structure of
Is that basically the “Do nothing and hope that dir: is already good enough” approach? Or is the proposal to never alter format of existing files, but to possibly add more files to the generated directory? Suppose a future producer version adds new files to the generated directory. Old consumer versions don’t look for those files (and don’t fail if unexpected files are found), so they would not break, but they would also not consume the new files. Did we, or did we not, break compatibility, by creating an image that old consumers can’t consume the way the producers understood them? Pragmatically, that depends both on the nature of the files (are they nice icons for a GUI console, or mandatory firewall settings?) and on the nature of the operation (is the old client running the container, where losing icons is OK, or is the old client a part of the official product publishing pipeline, where losing icons is a failure to publish the intended artifact?). It seems to me But given the request that motivates this issue, to support |
Yes, I had that in mind. I am not at all set on that but thought to throw the idea out to discuss it. |
It’s a definitely a good point. Arguably the OTOH if the net effect is losing data, something in that sequence should at least recognize that it might happen, if not prevent that from happening. Currently we require explicit One option would be two producer options like |
I think it's possible to make newer clients smart enough to be able to detect such potential data loss.
Totally agree. Assuming we find a way to have some persistent metadata that doesn't alter the digest/identify of an image, new clients should be able to detect such a data loss. For instance, the metadata claims the existence of an absent file. |
dir:
started as a debugging / scripting tool, and has, per https://github.com/containers/image/blob/main/docs/containers-transports.5.md#dirpath , basically no guarantees.Meanwhile, we are recommending
dir:
as a transport format (second best after using a registry, but still distinctly better thandocker-archive:
for most cases); and that brings up questions of forward/backward compatibility. Typically, we assume that the consumers and producers ofdir:
use fairly close versions (and can manage the consumer and producer versions to be compatible and to notice breakage), but there are requests for a long-term commitment so that future versions of software can reliably producedir:
data consumable by an old (presumably frozen) version.Right now,
dir:
creates aversion
file; that would at least allow detecting incompatibility, but does not allow ensuring it.Some options:
dir:
is already good enough that this will never come up. (We have had one incompatible format change in Feb 2018. OTOH the generalization of image “attachments” from signatures to SBOMs and referenced images https://github.com/opencontainers/distribution-spec/blob/main/spec.md#listing-referrers is on the horizon.)dir:
as is, commit to compatibility (assuming the image contents, e.g. the manifest format, are consumable), and assume that any future additions will become adir2:
--dir-output-version
option (currently accepting only1.1
), and commit to supporting all past formats for the future. (Or only to cleanly failing if the old format is no longer implemented??)@vrothberg @rhatdan @mheon (others) WDYT?
The text was updated successfully, but these errors were encountered: