3scale-operator
3scale-operator copied to clipboard
Controlling Operator compatibility with OpenShift Container Platform versions
What
Controlling Operator compatibility with OpenShift Container Platform versions at the upstream level.
Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all
Code Climate has analyzed commit 8c2628f9 and detected 0 issues on this pull request.
View more on Code Climate.
Having an issue with the operator-sdk
tool. It does not allow me to add bundle annotations. They are being removed when running operator-sdk generate bundle
command.
diff --git a/bundle.Dockerfile b/bundle.Dockerfile
index 6c97c553..8c812a23 100644
--- a/bundle.Dockerfile
+++ b/bundle.Dockerfile
@@ -10,7 +10,6 @@ LABEL operators.operatorframework.io.metrics.mediatype.v1=metrics+v1
LABEL operators.operatorframework.io.metrics.project_layout=go.kubebuilder.io/v2
LABEL operators.operatorframework.io.test.config.v1=tests/scorecard/
LABEL operators.operatorframework.io.test.mediatype.v1=scorecard+v1
-LABEL com.redhat.openshift.versions=v4.11-v4.14
COPY bundle/manifests /manifests/
COPY bundle/metadata /metadata/
COPY bundle/tests/scorecard /tests/scorecard/
diff --git a/bundle/metadata/annotations.yaml b/bundle/metadata/annotations.yaml
index df5c05bf..7d7cbc95 100644
--- a/bundle/metadata/annotations.yaml
+++ b/bundle/metadata/annotations.yaml
@@ -9,4 +9,3 @@ annotations:
operators.operatorframework.io.metrics.project_layout: go.kubebuilder.io/v2
operators.operatorframework.io.test.config.v1: tests/scorecard/
operators.operatorframework.io.test.mediatype.v1: scorecard+v1
- com.redhat.openshift.versions: v4.11-v4.14
Maybe upgrade needed?
Any reason why you want that annotation in dockerfile? IMO it doesn't need to be there, as long as the CSV contains the annotation we are fine?
Any reason why you want that annotation in dockerfile? IMO it doesn't need to be there, as long as the CSV contains the annotation we are fine?
In the CSV you can specify olm.properties: '[{"type": "olm.maxOpenShiftVersion", "value": "4.14"}]'
, for preventing cluster upgrades if the operator does not support it. But the catalog target (com.redhat.openshift.versions=v4.11-v4.14
) needs to be as label in the bundle image as well as in the bundle/metadata/annotations.yaml
file. Let me know if I am wrong.
Any reason why you want that annotation in dockerfile? IMO it doesn't need to be there, as long as the CSV contains the annotation we are fine?
In the CSV you can specify
olm.properties: '[{"type": "olm.maxOpenShiftVersion", "value": "4.14"}]'
, for preventing cluster upgrades if the operator does not support it. But the catalog target (com.redhat.openshift.versions=v4.11-v4.14
) needs to be as label in the bundle image as well as in thebundle/metadata/annotations.yaml
file. Let me know if I am wrong.
Any reason why you want that annotation in dockerfile? IMO it doesn't need to be there, as long as the CSV contains the annotation we are fine?
In the CSV you can specify
olm.properties: '[{"type": "olm.maxOpenShiftVersion", "value": "4.14"}]'
, for preventing cluster upgrades if the operator does not support it. But the catalog target (com.redhat.openshift.versions=v4.11-v4.14
) needs to be as label in the bundle image as well as in thebundle/metadata/annotations.yaml
file. Let me know if I am wrong.
Following docs https://docs.openshift.com/dedicated/operators/operator_sdk/osdk-working-bundle-images.html it seems that the values in dockerfile and annotations should be added manually.
There's also this PR but it doesn't look like it's merged - https://github.com/operator-framework/operator-sdk/pull/5560
I think we could investigate further to see if the issue of syncing annotations info to dockerfile was resolved but IMO, we need sdk bump since it's definitely not working as expected on current version we are using.
I think we could investigate further to see if the issue of syncing annotations info to dockerfile was resolved but IMO, we need sdk bump since it's definitely not working as expected on current version we are using.
It seems to me that even with the latest operator-sdk, the issue is still there. We should test that first.