-
Notifications
You must be signed in to change notification settings - Fork 150
CONSOLE-3220: Add console capability to all manifests #665
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
CONSOLE-3220: Add console capability to all manifests #665
Conversation
|
Hi @raspbeep. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions 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/test-infra repository. |
|
/ok-to-test |
jhadvig
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@raspbeep thanks for the PR! We also need to add the annotation manifests in the bindata/ and quickstarts/ folders.
|
/retest |
spadgett
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we're leaving the console CRDs (ConsoleLink, ConsolePlugin, etc) even if console is removed. Is that right?
We plan to write a conversion webhook for the ConsolePlugin CRD in the console operator, so we won't be able to have the CRD without the operator. We need to decide if
- We want to remove the console CRDs or
- We leave the both the console CRDs and operator (for the webhook) even if console is removed or
- We create a separate pod just for the webhook.
@jhadvig @bparees Opinion? I'm inclined to say we remove the CRDs, but any operators that relies on them would need to tolerate it when they're missing.
i'm also inclined to remove them, i'm not sure what background/motivation lead to the decision to always enable them. Presumably it was to avoid breaking consumers of those apis, as @spadgett said, but we should be moving them towards tolerating the absence of these apis, as we make the console in general an optional component. |
@spadgett @bparees So if the console-operator wont part of the cluster, CVO wont be pulling all it's manifests (together with Console's CRDs) from the image and creating them. For that reason the CRD's should not be created on the cluster if console-operator is disabled. Or is my understanding wrong? |
|
@jhadvig My understanding is the CVO will still install any manifests that don't have the capability annotation. Since we copy the CRD manifests from openshift/api in our Dockerfile, those would still get installed since they don't have the annotation. (Presumably there is a way to add the annotation to the generated CRD from the api repo?) @bparees Can you confirm? |
correct. What matters is the annotations on the resource yamls that go into the payload.
i think you can just add it manually and generation doesn't touch it. |
|
@raspbeep could you please update openshift/api#1232 and at the annotation to our CRDs ? Both: |
|
Thanks for the reviews. Added the annotations to CRDs in openshift/api#1232. |
| app: "console" | ||
| annotations: {} | ||
| annotations: | ||
| capability.openshift.io/name: console |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't believe this needs to be on anything the operator itself creates (in other words anything in bindata). Just the YAML files in manifests.
|
@spadgett you are right. Since operator is working with bindata we dont need to add the annotation to them. On the other hand we should probably add it to the |
Right, the quick start CRs will need it. |
98593d5 to
f9c0546
Compare
jhadvig
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
|
/hold QE Approver: |
|
/retest |
|
Hmm, I was checking in back here to report openshift/installer#5336 landing to unblock your CI. But weirdly, this run from the 23rd has: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_console-operator/665/pull-ci-openshift-console-operator-master-e2e-gcp/1562005782285783040/artifacts/e2e-gcp/ipi-install-install/artifacts/.openshift_install.log | grep -A5 'openshift-console route'
time="2022-08-23T10:11:59Z" level=info msg="Waiting up to 10m0s (until 10:21AM) for the openshift-console route to be created..."
time="2022-08-23T10:11:59Z" level=debug msg="Route found in openshift-console namespace: console"
time="2022-08-23T10:11:59Z" level=debug msg="OpenShift console route is admitted"
time="2022-08-23T10:11:59Z" level=info msg="Install complete!"
time="2022-08-23T10:11:59Z" level=info msg="To access the cluster as the system:admin user when using 'oc', run\n export KUBECONFIG=/tmp/installer/auth/kubeconfig"
time="2022-08-23T10:11:59Z" level=info msg="Access the OpenShift web-console here: https://console-openshift-console.apps.ci-op-zph4n5kx-2f88d.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"Is the plan to leave that route in place, even when the console is removed? Ah, it's because openshift/cluster-version-operator#801 landed: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/pr-logs/pull/openshift_console-operator/665/pull-ci-openshift-console-operator-master-e2e-gcp/1562005782285783040/artifacts/e2e-gcp/gather-extra/artifacts/clusterversion.json | jq -c '.items[].status.capabilities.enabledCapabilities'
["Console","Insights","Storage","baremetal","marketplace","openshift-samples"]and that took CI on this PR from "will things work with our removal annotations?" to "meaningless" 😂. I guess we'll see post-merge ;) |
|
/test e2e-aws-console |
|
/retest |
|
/test e2e-aws-console |
|
/retest |
1 similar comment
|
/retest |
|
Thank you, @invincibleJai 🙏 |
jhadvig
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jhadvig, raspbeep The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
/retest looks like a flake |
|
/retest |
|
@raspbeep: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
…e.url when Console is not enabled Avoid noise like [1,2]: Error from server (NotFound): namespaces "openshift-console" not found when the Console cluster capability is not enabled [3]. With this commit, the output will be: Console is not a ClusterVersion enabled capability: [] [1]: https://prow.ci.openshift.org/view/gs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.12-e2e-aws-sdn-no-capabilities/1568745812194758656 [2]: https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/origin-ci-test/logs/periodic-ci-openshift-release-master-ci-4.12-e2e-aws-sdn-no-capabilities/1568745812194758656/artifacts/e2e-aws-sdn-no-capabilities/ipi-install-install/build-log.txt [3]: openshift/console-operator#665
Since these manifests became deletion manifests in 6c6c5ce (Add release.openshift.io/delete annotation to consoleLink CRDs, 2021-07-15, openshift#565, 4.9 [2]), the only change has been 0f860bb (Add console capability to all manifests in manifests/ and quickstarts/, 2022-07-26, openshift#665). We can remove these deletion references now, because a 4.8 cluster that might have included these resources should have completed an update to 4.9 which would have removed them. And if that failed, they should have completed an update to one of the later 4.y and removed the resources. By removing the resource, we save the cluster-version operator some time checking to ensure deletion, and only expose ourselves to leaking the resources on clusters that updated from 4.8 through to 4.14 without ever having completed an update before reaching 4.14. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1980531#c8
Since these manifests became deletion manifests in 6c6c5ce (Add release.openshift.io/delete annotation to consoleLink CRDs, 2021-07-15, openshift#565, 4.9 [1]), the only change has been 0f860bb (Add console capability to all manifests in manifests/ and quickstarts/, 2022-07-26, openshift#665). We can remove these deletion references now, because a 4.8 cluster that might have included these resources should have completed an update to 4.9 which would have removed them. And if that failed, they should have completed an update to one of the later 4.y and removed the resources. By removing the resource, we save the cluster-version operator some time checking to ensure deletion, and only expose ourselves to leaking the resources on clusters that updated from 4.8 through to 4.14 without ever having completed an update before reaching 4.14. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1980531#c8
https://issues.redhat.com/browse/CONSOLE-3220
Signed-off-by: Pavel Kratochvil [email protected]