Description of problem: Within the web ui in OCP 4.0 the ability to scale a deployment that is controlled by an operator does not work as expected, the operator scales it back to the original replicas Version-Release number of selected component (if applicable): 4.0.0-0.1 How reproducible: login to the web ui and scale the OCP router that resides in the openshift-ingress Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This works by design. The purpose of the operator is to keep the specified number or replicas, which is 1 in this case.
It's understood that the operator is configured to keep the replicas at 1 (in this case). However, because of this, it renders the UI to change replicas to not work as expected. This needs to be fixed.
It would be out suggestion that in the case of something like the router pod that one of the following would happen: 1 grey out the ability to scale that pod via the current web ui or 2 the scaling function makes the proper call behind the scenes such as this command from the cli: oc scale clusteringresses default --replicas 3
This is a feature, not a bug! The operator makes sure the deployment is in the correct state. You should not be modifying these resources directly. There's no good way for the web console to know what resources and what specific fields each operator controls. It's not limited to scaling, but any field in any resource controlled by an operator. This is not specific to the web console, either. You could change the fields using the CLI, and the changes would be overwritten. Additionally, there is an option to mark some operators as "unmanaged" where you can change these values, and we wouldn't want to block users from making these changes in the UI. If I delete a pod that's part of a replica set, the pod automatically gets recreated. We don't block the delete action in the UI, however. I see this as being very similar.