-
Notifications
You must be signed in to change notification settings - Fork 658
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
Comments
cc @vbatts just because I know you 😄 |
nothing official. I've heard some tools pull from os-release for the label/annotations. |
Yeah agree we can't mandate. But how about adding |
@cgwalters do you have links to places where projects are already doing similar? (maybe not in the |
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: So if we had a standard like |
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. |
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
andID_LIKE
keys.The text was updated successfully, but these errors were encountered: