Bug 1713211
Summary: | Stateful set donut does not update on overview when stateful set is scaled | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Ian Lawson <ian.lawson> |
Component: | Management Console | Assignee: | Samuel Padgett <spadgett> |
Status: | CLOSED ERRATA | QA Contact: | Yadan Pei <yapei> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 3.11.0 | CC: | aos-bugs, jokerman, mmccomas, smunilla, xiaocwan, yapei |
Target Milestone: | --- | ||
Target Release: | 3.11.z | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
Previously, the web console could show an incorrect "Scaling to..." value for stateful sets in the project overview under some conditions. The stateful set desired replicas value now correctly updates in the web console project overview.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2019-06-26 09:08:11 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Ian Lawson
2019-05-23 07:37:47 UTC
Mentioned above, 3.11.88 build is where I'm seeing this..... (In reply to Ian Lawson from comment #2) > Mentioned above, 3.11.88 build is where I'm seeing this..... OK I see that but I don't know how that relates to the release team. We build and deliver the code. We don't debug and fix why pods aren't scaling. I think you need another team for this. (In reply to Tim Bielawa from comment #3) > (In reply to Ian Lawson from comment #2) > > Mentioned above, 3.11.88 build is where I'm seeing this..... > > OK I see that but I don't know how that relates to the release team. We > build and deliver the code. We don't debug and fix why pods aren't scaling. > I think you need another team for this. This is a code issue not a debug issue - the UI is not behaving as expected or intended, and the resulting information to the end user is confusing and incorrect. The event model in the UI isn't being called correctly when the scaling of the Pod changes *when* the Pod is a StatefulSet and not a DeploymentConfig. It's a code issue in the UI - given this UI is effectively retired as of 3.11 I wouldn't normally raise it but a lot of customers will be sticking with 3.11 for a while *and* Operators are the key feature people will be using. Given the fact the Operators use StatefulSets for replication this issue will be seen a lot going forward. The UI shows the value of `spec.replicas` in the center of the donut. Does the value displayed match what's in the stateful set? $ oc get statefulset <my-stateful-set> -o jsonpath='{.spec.replicas}' Console has no knowledge of Infinispan. Adding special support for Infinispan would be a separate RFE. I think the 'Infinispan' stuff is a red herring, that's just the CR/CRD consumed by the Operator. I've checked the replica count in the example - it returns '0' as expected when I downscale the number, the UI displays 'Scaling to 4' in the Pod graphic as shown in attached file..... Created attachment 1575643 [details]
Screenshot showing the statefulset scaled to 0 and the UI displaying 'Scaling to 4'
This is fixed on the version: OpenShift Web Console: v3.11.117 When the pods are scaling up to 10, then soon update the replicas to 0 (edit the yaml spec.replicas). The donut number is quickly updated to 0 with the notification message "Stateful Set example-ss was successfully updated." Created attachment 1580597 [details]
This is working, donut replicas number is soon updated to 0
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-2019:1605 |