Skip to content
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

Standards around bridging between /usr/lib/os-release and labels/annotations? #1152

Open
cgwalters opened this issue Dec 19, 2023 · 6 comments

Comments

@cgwalters
Copy link

Has there been any discussion on standard bridging between the os-release file and standardized labels/annotation names?

I tried searching issues/PRs here and didn't see anything. This seems like an obvious thing to want. I think to start at least the ID and ID_LIKE keys.

@cgwalters
Copy link
Author

cc @vbatts just because I know you 😄

@vbatts
Copy link
Member

vbatts commented Jan 10, 2024

nothing official. I've heard some tools pull from os-release for the label/annotations.
It seems like a good and fine pattern. Not sure about mandating such.

@cgwalters
Copy link
Author

Yeah agree we can't mandate. But how about adding org.opencontainers.osrelease.id as a start which is just the value of ID from /usr/lib/os-release?

@vbatts
Copy link
Member

vbatts commented Jan 25, 2024

@cgwalters do you have links to places where projects are already doing similar? (maybe not in the org.opencontainers.* prefix, but still)

@cgwalters
Copy link
Author

@cgwalters do you have links to places where projects are already doing similar? (maybe not in the org.opencontainers.* prefix, but still)

Not currently...but I want to. For example, containers/bootc#807 was recently filed, but actually the systemd side has already "standardized" such a thing:
https://www.freedesktop.org/software/systemd/man/latest/os-release.html#SUPPORT_END=

So if we had a standard like org.opencontainers.osrelease.* then we'd automatically have org.opencontainers.osrelease.support-end` which would solve the problem.

@sudo-bmitch
Copy link
Contributor

There's been a lot of discussion on #903 on end of support and end of life annotations. One of the bigger points made there is that a commitment to patching listed in the manifest is a bit confusing. You cannot patch an existing image, rather you must create a new one, with a different digest. Extending support, or eliminating it early, cannot be changed in already deployed images since users may have copied images with the old dates. There was also a lot of confusion in that issue where some wanted to support a tag, and not a digest, despite the annotation being part of the manifest which is unaware of the various tags that may reference it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants