|Summary:||deployment config page contains an error in the pod counter [openshift-4.4]|
|Product:||OpenShift Container Platform||Reporter:||Priyanka Kanthale <pkanthal>|
|Component:||Management Console||Assignee:||David Taylor <dtaylor>|
|Status:||CLOSED ERRATA||QA Contact:||Yadan Pei <yapei>|
|Version:||4.2.z||CC:||aos-bugs, bpeterse, fshaikh, hasha, jokerman, yanpzhan, yapei|
|Fixed In Version:||Doc Type:||Bug Fix|
Cause: If you increase the amount of pods on the Deployment Config Page to e.g. 5 and then on this same page you use Actions -> Edit Count to set the number of pods e.g. 10, the number counter increases on the Deployment Config Page and the number of pods grows. Consequence: If you then use the 'up' arrow to increase the number by one, the GUI adds one pod to the old '5' counter, setting the total number of pods to 6 instead of 11. Fix: Added useEffect to update state variable if # pods changed outside of PodRing component. This happens in the Edit Count modal, which closes without reloading page or remounting PodRing component. Result: PodRing component shows the correct count after using Actions -> Edit Count so that up/down arrows on the PodRing work correctly upon the updated count.
|Last Closed:||2020-05-04 11:21:35 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Priyanka Kanthale 2020-01-01 13:32:40 UTC
Description of problem: If you increase the amount of pods on the Deployment Config Page to e.g. 5 and then on this same page you use Actions -> Edit Count to set the number of pods e.g. 10, the number counter increases on the Deployment Config Page and the number of pods grows. However, if you then use the 'up' arrow to increase the number by one, the GUI adds one pod to the old '5' counter, setting the total number of pods to 6 instead of 11. So instead of adding one pod, you're actually killing 4 Version-Release number of selected component (if applicable): Tested on Openshift 4.2.9 and on 4.2.12
Comment 3 Yanping Zhang 2020-02-10 16:23:54 UTC
Checked on OCP 4.4 env with payload 4.4.0-0.nightly-2020-02-09-220310. Create dc in project, the pod number is 5, use Actions -> Edit Count to set the number of pods to 10, in the counter icon, there is no "scaling to" indicating pods number change, if time passes long enough, click the 'up' arrow, check pods number, it will be 11. If click the 'up' arrow too early after edit count to 10, the pods number will be 6 instead of 11. It's better to have "scaling to" info to indicate the scale status, so assign the bug back.
Comment 4 David Taylor 2020-02-10 17:42:13 UTC
I'm not seeing this behavior using 4.4.0-0.ci-2020-02-07. I have a dc with 5 pods, use Actions -> Edit Count to set the number of pods to 10, in the counter icon, there IS a "scaling to 10" indicating pods number change. Hitting the up or down arrows adjusts the 'scaling to' label to '11' or '9' appropriately.
Comment 5 David Taylor 2020-02-10 18:03:36 UTC
Updated: I see what I mentioned above ^^ using 4.4.0-0.ci-2020-02-09-194845.
Comment 6 David Taylor 2020-02-14 15:00:59 UTC
Hi, myself and another dev are able to see this fix and are not seeing the behavior Yanping Zhang indicated in 2020-02-10 comment. Putting this back on_qa
Comment 7 David Taylor 2020-02-14 15:17:10 UTC
Hi, ok, was able to reproduce. Issue only seems to happen during dc creation, after Pods are created count seems to reverts to initial count, then once Pods are created, count correctly goes to correct count. We do not see this issue once dc and/or pods have been created.
Comment 8 David Taylor 2020-02-18 18:45:43 UTC
Hi, the issue is the property updates are intentional delayed until after initial render in order to animate the ChartDonut. The window for this bug to occur is rare as it only occurs in the time between dc creation and initial Pod creation; and the only affect is the donut chart label is temporarily incorrect. We do not see this issue after dc and initial pods have been created.
Comment 9 David Taylor 2020-02-18 18:50:01 UTC
I recommend https://github.com/openshift/console/pull/4157 fixed this bug and that a new bug filed if necessary to capture and track any additional work.
Comment 10 shahan 2020-02-19 05:02:54 UTC
1. create dc with one replica and wait for the initial pod become running 2. increase the replica to 5 by edit yaml file 3. then increase the replica to 10 by clicking action-> edit count 4. and then increase the replica to 11 by clicking the 'up' arrow one time But the final count of running pod is 2 instead of 11 that we expected replica num. And monitoring the whole updating process after above operations, the ChartDonut is always showing "scaling to 10". 4.4.0-0.nightly-2020-02-17-211020
Comment 11 shahan 2020-02-19 05:15:14 UTC
I also tried bellow steps according to the description 1. create dc with 5 replicas and wait for the five initial pods become running 2. then increase the replica to 10 by clicking action-> edit count 4. and then increase the replica to 11 by clicking the 'up' arrow one time But the final count of running pod is 6 instead of 11 that we expected replica num. And monitoring the whole updating process after above operations, the ChartDonut did not showing "scaling to 10". 4.4.0-0.nightly-2020-02-17-211020 Please let me know if there is anything wrong in my verification steps.
Comment 12 shahan 2020-02-19 05:25:14 UTC
It seems we need to wait for the "edit count" take effect, and then click 'up' arrow . That would be works well. If you thought this is our expected behavior for the issue, please feel free change to on qa status again. Thanks
Comment 13 David Taylor 2020-02-19 15:01:23 UTC
Created attachment 1664076 [details] Successfully ran pod ring scenarios
Comment 14 David Taylor 2020-02-19 15:05:04 UTC
Hi, I don't believe I am seeing what your are seeing :-( Please see attachment "Successfully ran pod ring scenarios" where I run through the steps which result in the final pod count to be 11 as expected. Is this a timing/network issue? I'm running locally, perhaps it's slower over the network?
Comment 17 Yadan Pei 2020-02-24 01:39:37 UTC
Clear needinfo for me since bug is verified and question is answered
Comment 19 errata-xmlrpc 2020-05-04 11:21:35 UTC
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, 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/RHBA-2020:0581