Bug 2012099 - Cluster in Installation phase gets reset back to before installation
Summary: Cluster in Installation phase gets reset back to before installation
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: assisted-installer
Version: 4.9
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
: ---
Assignee: Jonathan Kilzi
QA Contact: Yuri Obshansky
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-08 09:16 UTC by Constantin Vultur
Modified: 2022-08-28 08:45 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-28 08:45:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Constantin Vultur 2021-10-08 09:16:09 UTC
Description of problem:


Version-Release number of selected component (if applicable):
{"release_tag":"v1.0.26.0","versions":{"assisted-installer":"registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-rhel8:v1.0.0-99","assisted-installer-controller":"registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-reporter-rhel8:v1.0.0-123","assisted-installer-service":"quay.io/app-sre/assisted-service:faf9e09","discovery-agent":"registry-proxy.engineering.redhat.com/rh-osbs/openshift4-assisted-installer-agent-rhel8:v1.0.0-69"}}

How reproducible:



Steps to Reproduce:
1. Prepare cluster with 3 masters/3 workers and OCS operator , using 4.8.12
2. Make sure all validation are OK and start installation
3. 

Actual results:
After the Installation was started, and nodes were in "Preparing for installation" the cluster got reset and back into the before installation phase. 
This seems to be caused by some agents that failed the following validation:
Container images availability: Failed to fetch container images needed for installation from quay.io/openshift-release-dev/ocp-release:4.8.12-x86_64.


Expected results:
Validation to fail before user starts Installation

Additional info:

Comment 9 Constantin Vultur 2021-10-08 09:56:34 UTC
There were no installation logs to download, since the cluster moved back to before installation state

Comment 11 Michael Filanov 2021-10-10 07:02:25 UTC
We do try cache some of the images before we start the installation, so network issues can happen anytime, i think that enabling the user to retry is a good solution, the question is if it's visible, do you see any events related to it or did you had to go into the agents logs? 

Besides making it visible i don't see a really good solution, @atraeger @rfreiman what do you think?

Comment 12 Avishay Traeger 2021-10-31 11:29:40 UTC
This is the design that we discussed with UX.  I believe the UI has an open task on making the reason more visible.

Comment 13 Michael Filanov 2021-10-31 11:35:34 UTC
@tjelinek @jkilzi Is there a ticket that we can link?

Comment 14 Jonathan Kilzi 2021-10-31 14:27:57 UTC
Please take a look at this https://issues.redhat.com/browse/MGMT-7943
I couldn't find something more specific.
Please let me know if we need to open such a task.

Comment 15 Michael Filanov 2021-10-31 14:44:21 UTC
@jkilzi i assigned this ticket to you, if it's ok with QE you can probably close this ticket.

Comment 17 Alexander Chuzhoy 2022-01-06 16:19:49 UTC
reproduced on Assisted-ui-lib version:  2.0.6

Comment 19 Jonathan Kilzi 2022-01-24 13:00:13 UTC
@yobshans seems that when this bug was opened the expectation was to receive the validation failure, about container-images-availability, before the installation begins.
This behavior was changed as part of https://issues.redhat.com/browse/MGMT-7943.
The desired behavior now is to take you back to the "Review and create" step and show you a warning about what happened.
The container-images-availability validation is not designed to run before the installation begins, therefore the expected behavior in the description of this bug must be aligned with the one I described before.

Moving back to ON_QA

Comment 20 Yuri Obshansky 2022-02-02 23:19:45 UTC
Not reproducible 
Assisted-ui-lib version:  2.0.9


Note You need to log in before you can comment on or make changes to this bug.