Closed leelavg closed 1 month ago
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: leelavg Once this PR has been reviewed and has the lgtm label, please assign agarwal-mudit for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
fix for https://bugzilla.redhat.com/show_bug.cgi?id=2311857, I tested wrt expectation and scenarios that I could think of, pls review and surface any left out paths orrefactoring efforts. thanks.
What is a need of doing it via the deployment now.
- I explained the reasoning of why deployment is being brought down in code comment and why only setting single CSV replicas to 0 isn't working in PR description. May I know what more info is required?
We had a discussion over a call and we decided to close the BZ https://bugzilla.redhat.com/show_bug.cgi?id=2311857#c7
t0: odf-op w/ X.Y.Z is installed and all dependecies at same version will be installed t1: odf-op is upgraded from X.Y.Z to X.(Y+1).0 and update will happen for odf-op unless there are explicit not upgradeable conditions set t2: dependencies will first get updated from X.Y.Z to X.Y.(Z+1) if the channel has the update, now if one of the dependencies is stuck odf-op keeps trying to check for upgraded install plan which will not be created due to previous install plan for dependencies not being fulfilled.
now, odf-op always tries to scale down client-op if not in provider mode in above scenario t1 & t2 aren't strictly linear and odf-op ended up scaling down X.Y.Z version of client-op but not X.Y.(Z+1) which will never reach running state if cluster is configured as non-provider mode.
current PR makes sure that client-op csv & deployments are always scaled down for all non-provider cases.