Description of problem: As a cluster admin, after installing an operator for which the console provides UI for, I expect that UI to become enabled without needing to refresh the browser. There is a race condition however as the console watches the APIServiceModel to recognize when to update the available feature flags. The problem here is that the knative serving api group first becomes available with a subset of the knative serving CRDs. Therefore the first time the console is notified of the new group, it only enables a few feature flags. Later on more CRDs are installed into the same API group but there are no new notifications. Therefore the UI flagged against those CRDs never gets enabled until the user refreshes their browser or a new api group is added which re-runs the whole discovery process again. A polling method is used for non-admin users which suffers from the same issue because, for performance reasons, the api discovery is only run if there is a change in the available api groups, but not if there's a change in the number of resources provided within an already existing api group. How reproducible: Steps to Reproduce: 1. install operator OpenShift Serverless 2. Upon installation wait for `Serverless` navigation section to appear in the admin nav Actual results: Serverless section sometimes contains 1, 2, or 3 nav links. First observed only containing a single link named `Revisions`. Expected results: Serverless section should always contain 3 nav links: Revisions, Routes, Services Additional info:
*** Bug 1832706 has been marked as a duplicate of this bug. ***
Pushing this to 4.6. Its not new, and we don't have time to address in 4.5.
@Ben, I'm unable to look into this bug at this time due to my upcoming leave. I want to reassessing to you so you could assign it to someone else to avoid delay.
I think we can implement this in the backend now and make watch work for all users. We can use the console service account to watch CRDs, but only return the group/version/kind to the client. This wouldn't leak any information not already available through API discovery. Then the UI should be able to respond immediately on changes, and we avoid the race we have today.
This looks similar to https://bugzilla.redhat.com/show_bug.cgi?id=1997269 issue. Jon could you please take a look if the above mentioned BZ is not a dup.? Thanks
@
Jakub, this is related to https://bugzilla.redhat.com/show_bug.cgi?id=1997269 but not quite a duplicate. I think that we can address these separately.
Manually moving to modified since the associated PR merged.
1. Install 'Red Hat OpenShift Serverless' operator $ oc get csv -n knative-serving NAME DISPLAY VERSION REPLACES PHASE serverless-operator.v1.18.0 Red Hat OpenShift Serverless 1.18.0 serverless-operator.v1.17.0 Succeeded $ oc get crd | grep knative | awk -F ' ' '{print $1}' knativeeventings.operator.knative.dev knativekafkas.operator.serverless.openshift.io knativeservings.operator.knative.dev 2. Create 'Knative Serving' instance in 'knative-serving' namespace, wait until `Serverless` navigation section to appear in the admin nav, I can always see 3 nav links: Revisions, Routes, Services ^^ is checked against 4.10.0-0.nightly-2021-11-15-034648 However on a 4.9 nightly(4.9.0-0.nightly-2021-11-12-222121) cluster without the fix code, I can still always see 3 nav links: Revisions, Routes, Services, I didn't reproduce the issue described Anything I'm missing regards to how can I reproduce the issue?
Didn't get response yet, based on comment 27 will move it to VERIFIED any problems or issues we can go back to this BZ
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056