olm(channel): change from rhtas-1-0 to stable-1-0 #359
Conversation
|
Skipping CI for Draft Pull Request. |
| @@ -193,7 +193,7 @@ metadata: | |||
| features.operators.openshift.io/token-auth-aws: "false" | |||
| features.operators.openshift.io/token-auth-azure: "false" | |||
| features.operators.openshift.io/token-auth-gcp: "false" | |||
| operators.operatorframework.io/builder: operator-sdk-v1.32.0 | |||
| operators.operatorframework.io/builder: operator-sdk-v1.34.1 | |||
There was a problem hiding this comment.
Since we are bumping this dont we also need to bump the operator sdk verison in the makefile
There was a problem hiding this comment.
Probably - I just ran make bundle 🤷
There was a problem hiding this comment.
I've updated the makefile and also noticed an old alpha annotation hanging around that I changed to stable
There was a problem hiding this comment.
I agree with new format of channel naming.
I found few places with old version v1.32.0 of operator sdk and alpha channel. Can you please to update them too.
- https://github.com/lance/secure-sign-operator/blob/channel-conventions/bundle.Dockerfile#L8-L9
secure-sign-operator/fbc/generate-fbc.sh
Lines 75 to 76 in 5a523fd
- https://github.com/search?q=repo%3Asecuresign%2Fsecure-sign-operator+%22quay.io%2Foperator-framework%2Fscorecard-test%3Av1.32.0%22&type=code
fbc/generate-fbc.sh
Outdated
| @@ -73,7 +73,7 @@ LABEL operators.operatorframework.io.bundle.manifests.v1=manifests/ | |||
| LABEL operators.operatorframework.io.bundle.metadata.v1=metadata/ | |||
| LABEL operators.operatorframework.io.bundle.package.v1=rhtas-operator | |||
| LABEL operators.operatorframework.io.bundle.channels.v1=alpha | |||
There was a problem hiding this comment.
| LABEL operators.operatorframework.io.bundle.channels.v1=alpha | |
| LABEL operators.operatorframework.io.bundle.channels.v1=stable |
Always forget about that... |
This commit modifies the channels we advertise for the operator, removing the `rhtas-` prefix in favor of a `stable-` prefix, indicating the major/minor version for that particular stable line. This channel naming is based on the olm documentation best practices found at: https://olm.operatorframework.io/docs/best-practices/channel-naming/#example-3-recommended-option-is-the-most-common-scenarios I did not include a `fast-1-0` or `candidate-1-0`, however the current configuration does not prevent these channels from being used in the future. At this point, I don't think we have a strong enough cadence to be using `fast` and `candidate`, however we may want to consider that for the July release, or at least the EOY release. If we want to follow the recommended semver naming conventions, then we should consider the July release to be v1.1.0, given that it _should_ introduce new functionality with SECURESIGN-720 and possibly others Jiras as well (key rotation, independently deployable services, etc). If this PR is merged, the user would see only two channels when installing `stable` and `stable-1-0`. They would (for now) contain the exact same versions. But ultimately, as newer minor versions are released, they will _all_ appear in `stable`, but `stable-1-0` will only contain 1.0.0, 1.0.1, and any other 1.0.* releases we produce. Do not merge this commit without discussion. I think we really want to get it right and not have to make further changes. Signed-off-by: Lance Ball <[email protected]>
Signed-off-by: Lance Ball <[email protected]>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Gregory-Pereira, JasonPowr, lance The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This commit modifies the channels we advertise for the operator, removing the
rhtas-prefix in favor of astable-prefix, indicating the major/minor version for that particular stable line. This channel naming is based on the olm documentation best practices found at: https://olm.operatorframework.io/docs/best-practices/channel-naming/#example-3-recommended-option-is-the-most-common-scenariosI did not include a
fast-1-0orcandidate-1-0, however the current configuration does not prevent these channels from being used in the future. At this point, I don't think we have a strong enough cadence to be usingfastandcandidate, however we may want to consider that for the July release, or at least the EOY release.If we want to follow the recommended semver naming conventions, then we should consider the July release to be v1.1.0, given that it should introduce new functionality with SECURESIGN-720 and possibly others Jiras as well (key rotation, independently deployable services, etc).
If this PR is merged, the user would see only two channels when installing:
stableandstable-1-0. They would (for now) contain the exact same versions. But ultimately, as newer minor versions are released, they will all appear instable, butstable-1-0will only contain 1.0.0, 1.0.1, and any other 1.0.* releases we produce.Do not merge this commit without discussion. I think we really want to get it right and not have to make further changes.