csv spec update to include release attr #1884
Conversation
Signed-off-by: grokspawn <jordan@nimblewidget.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Signed-off-by: grokspawn <jordan@nimblewidget.com>
Signed-off-by: grokspawn <jordan@nimblewidget.com> Assisted-by: claude
grokspawn
force-pushed
the
csv-release-attr
branch
from
2fd4d1e to
f427e81
Compare
Signed-off-by: grokspawn <jordan@nimblewidget.com>
|
/assign @Xia-Zhao-rh |
|
|
||
| ### API Extensions | ||
|
|
||
| Adds optional `release` field to FBC package schema in operator-registry declcfg format. Pure additive change—no CRDs, webhooks, or finalizers modified. Change confined to bundle metadata schema in FBC catalogs and operator-registry databases. |
There was a problem hiding this comment.
Is this still accurate?
Modifications are being made to the CSV CRD right?
There was a problem hiding this comment.
Bundle versions are authored in the form of CSVs, which are a part of the registry+v1 bundle format. However, this is bundle-scoped data which is ultimately composed in FBC by opm tooling as part of the olm.bundle schema. The full scope of this feature will represent the information in the declcfg olm.bundle schema of the FBC, but to get there it has to exist in the bundle somewhere.
|
|
||
| ## Motivation | ||
|
|
||
| FBC lacks a standardized mechanism for operator repackaging. Current approaches encode release information in semver build metadata (e.g., `7.10.2-opr-2+0.1676475747.p`), conflating operator version with build/release metadata. This violates [the semver spec](https://www.semver.org) and undermines FBC's reliance on semver ordering. This enhancement enables programmatic distinction between operator version and release version, supporting repackaging workflows without version changes. |
There was a problem hiding this comment.
To make sure I'm following along correctly, the crux of the issue here is that operator authors don't have a way to make a packaging metadata change without also up-versioning their entire package?
And the proposed solution here is to keep that requirement, but add a new field that allows an operator author to state that this up-versioned package actually installs release X of the operator?
There was a problem hiding this comment.
operator authors publishing via SQLite catalog approaches have a way to make a packaging-only metadata change w/o up-versioning. (With the caveat that only Freshmaker used it, for CVE resolution in base images, with a hidden flag in opm tooling that made it essentially pipeline-only.) FBC doesn't provide an analogue.
So we need versioning data for the packaging version, distinct from the operator version.
Signed-off-by: grokspawn <jordan@nimblewidget.com>
grokspawn
force-pushed
the
csv-release-attr
branch
from
72b17d5 to
e1af5b8
Compare
|
@grokspawn: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/assign @oceanc80 |
everettraven
left a comment
everettraven
left a comment
There was a problem hiding this comment.
Aside from ongoing review of the API changes, this change seems fine to me.
6 participants
No description provided.