Created attachment 1894863 [details] descheduler Description of problem: Currently, the descheduler option is disabled in template's scheduling tab, user may wonder why it's there and disabled. I cannot see a good reason to disable it, so let's either enable it or hide it. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The Descheduler operator must be installed on the cluster for the option to be enabled. Please verify that the operator is installed. We may need to add an explanation in the case it is disabled
Hello, we have already for some time the extra popover implemented: "To enable the Descheduler, you must install the Kube Descheduler Operator from OperatorHub and enable one or more Descheduler profiles." See also the attachment. Is this text incorrect? Should we change it? IMO it is sufficient enough. Thanks!
(In reply to Hilda Stastna from comment #2) > Hello, > > we have already for some time the extra popover implemented: > "To enable the Descheduler, you must install the Kube Descheduler Operator > from OperatorHub and enable one or more Descheduler profiles." > See also the attachment. > Is this text incorrect? Should we change it? IMO it is sufficient enough. > Thanks! The Kube Descheduler Operator is not related, after install the descheduler operator, the custom template still see the same thing in scheduling tab. And I believe the UI does not check the operator state to enable and disable it. Since other fields are editable, there is no reason to just disable this field.
Hi Guohua, the UI does check the operator state to enable and disable. Maybe there is some problem with the check. The reason to disable this field is to provide the info for the user that there is this feature but to enable it the operator must be installed. By hiding this completely the user will lose the information entirely. Also it is a part of the new design to just disable this field if the operator is not installed.
If the operator is not installed the field is disabled just like Hilda said. If the operator is installed and it's still disabled, it's a bug and we need to fix it.
There should have no check about the descheduler operator. 1. the descheduler field is disabled on custom template 2. create a vm from this custom template, the field is editable 1 and 2 are conflict each other if there is a checking about the descheduler operator.
There has to be check about the operator, otherwise we won't know when to enable/disable it. Regarding the rest, I agree, there is a conflict and it is there because the editability of the Descheduler field in the VM page is missing the check for the operator installed.
Hi Hilda, After uninstall the descheduler operator, should the descheduler option be disabled again? Reproduce steps: 1. On a cluster has no descheduler operator installed, the descheduler option is disabled 2. Install the descheduler operator, the descheduler option is enabled 3. Delete the descheduler operator, the descheduler option is enabled My question is on step 3, should it be disabled again?
If the Kube Descheduler Operator is not installed, Descheduler field should be disabled. I've tried to reproduce your step 3, but was not able to reproduce. Works for me as expected. Did you follow the steps https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-descheduler.html#nodes-descheduler-uninstalling_nodes-descheduler?
Guohua, where exactly is the Descheduler field enabled for you (step 3)?
Guohua, you need to follow the whole procedure of uninstalling the descheduler: https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-descheduler.html#nodes-descheduler-uninstalling_nodes-descheduler From the attachment you've provided, I can see you've missed the steps 2, 4, 5 from the doc above. Thanks.
(In reply to Hilda Stastna from comment #14) > Guohua, > > you need to follow the whole procedure of uninstalling the descheduler: > https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes- > descheduler.html#nodes-descheduler-uninstalling_nodes-descheduler > From the attachment you've provided, I can see you've missed the steps 2, 4, > 5 from the doc above. Thanks. Could you tell me why need to do that, I don't see any reason to do those steps as they're not related. For step2, There is no instances created at all when the operator is installed, and the descheduler becomes enabled. So it seems no need to create the instance and of course no instances to be deleted. For step 4 and 5, they're totally not related.
How can those steps not be related? They are part of the procedure, as the doc says. Did you try to do all the steps? Also I remember you've sent me that doc and suggested me to follow that procedure when I asked you how to uninstall the Descheduler. > For step2, There is no instances created at all when the operator is installed, and the descheduler becomes enabled. I cannot reproduce that. The Descheduler is enabled after I follow the whole process of installing the Descheduler: https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-descheduler.html#nodes-descheduler-installing_nodes-descheduler
(In reply to Guohua Ouyang from comment #15) > (In reply to Hilda Stastna from comment #14) > > Guohua, > > > > you need to follow the whole procedure of uninstalling the descheduler: > > https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes- > > descheduler.html#nodes-descheduler-uninstalling_nodes-descheduler > > From the attachment you've provided, I can see you've missed the steps 2, 4, > > 5 from the doc above. Thanks. > > Could you tell me why need to do that, I don't see any reason to do those > steps as they're not related. > For step2, There is no instances created at all when the operator is > installed, and the descheduler becomes enabled. So it seems no need to > create the instance and of course no instances to be deleted. > For step 4 and 5, they're totally not related. ah, so I did these steps and the problem in step 3 is not showing. But I still don't understand why it checks so much, I think the checking of namespace and CRD are not correct behavior. In my opinion, it should only check the operator status.
Close the bug so far.
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 (Important: OpenShift Virtualization 4.12.0 Images 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-2023:0408