Cause: When User start a rollout on a Deployment Config page, no action is taken.
Consequence: When user starts a rollout on a Deployment Config, no noticeable is action is taken, should be redirected to created Replication Controller.
Fix: Redirect user to the new Replication Controller that was created as part of the started rollout.
Result: After starting a new rollout, user is redirected to the new Replication Controller page.
Description of problem:
When user starts a new rollout by clicking Actions -> Start Rollout, it updated Latest Version but not easy to observe
Version-Release number of selected component (if applicable):
4.1.0-0.nightly-2019-05-22-190823
console image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:e6b3e376fd5e0e69d65d12f75e349691e21b155b196618dcbfc3cd9865c343cf
console commit: https://github.com/openshift/console/commit/d8fc460a3d0e9f8de3d14373de8f36ba09103537
How reproducible:
Always
Steps to Reproduce:
1. Create a test Deployment Config on console
2. Go to Workloads -> Deployment Config -> Actions -> Start Rollout
Actual results:
2. A subtle change in Latest Version, use may even can't notice
Expected results:
2. It's better if we can give some message OR take user to RC page as what we do for Start Build, when user Start Build, it takes user to the builds page.
Additional info:
As soon as taking user to RC page and the latest version haven's started roll out yet, the RC page content displays "404: Not Found" for a few second and then displays normally.
Another issue is, when the pods are scaled up and are not all ready yet, try to roll out for several times. The page stay on DC and here comes an error message, plz refer to the screenshot.
Tested on latest Console commit: 46c502055e75f88c76995fae1afaaa21845c07c6
4.1.0-0.nightly-2019-06-20-015058
image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:ed455e4edada79ace735f0c5d2b00485ae74020ad144a225794c555ddd041c71
When user click Actions -> Start Rollout, user will be taken to new RC page, it's much clear now.
The problem described in comment 3 is a different issue then the original bug, going to verify this.
verified on 4.2.0-rc.5
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:2922