+++ This bug was initially created as a clone of Bug #1462006 +++

Description of problem:
If 'no' is selected when confirming the installation setting for Hosted Engine, different questions are asked.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Install Grafton
2. Once prompted to confirm the hosted engine setting, enter no.
3.

Actual results:
When prompted for the questions, the installer starts asking different questions than it originally did.

Two such questions are:
What type of storage (nfs, glusterfs, etc)

Please specify the full shared storage connection path to use (example: host:/path):


Expected results:
Same questions asked as the first time.


Additional info:

--- Additional comment from Sandro Bonazzola on 2017-06-16 02:30:28 EDT ---

(In reply to joherr from comment #0)
> Description of problem:
> If 'no' is selected when confirming the installation setting for Hosted
> Engine, different questions are asked.

In cockpit?


> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1. Install Grafton

I assume gdeploy completed its tasks and launching hosted-engine --deploy appending some answer file

> 2. Once prompted to confirm the hosted engine setting, enter no.
> 3.


I think here we are missing 3. execute something.
this may be a command line like hosted-engine --deploy or something different.
What's the action done here?


> 
> Actual results:
> When prompted for the questions, the installer starts asking different
> questions than it originally did.

This depends on the command line used in hosted-engine command.

> 
> Two such questions are:
> What type of storage (nfs, glusterfs, etc)
> 
> Please specify the full shared storage connection path to use (example:
> host:/path):
> 
> 
> Expected results:
> Same questions asked as the first time.
> 
> 
> Additional info:

--- Additional comment from  on 2017-06-16 11:54:45 EDT ---


> In cockpit?

Yes, This was in cockpit.

>> Steps to Reproduce:
>> 1. Install Grafton

> I assume gdeploy completed its tasks and launching hosted-engine --deploy appending some answer file

Yes, the gluster installation finished and I selected to continue with the installation of hosted engine.


>> 2. Once prompted to confirm the hosted engine setting, enter no.
>> 3.


> I think here we are missing 3. execute something.
> this may be a command line like hosted-engine --deploy or something different.
> What's the action done here?

I entered 'no' and submitted it. It then went and started asking the different set of questions. Since this is done through the cockpit gui, I did not run any commands from the command line.

--- Additional comment from Sahina Bose on 2017-06-28 03:18:19 EDT ---

We need a way to store the he answers file generated during gdeploy, so that subsequent HE deploy can pick this.

Sandro, what would be best location to store this file so that Hosted engine deployment can automatically be invoked using hosted-engine --deploy --append <this file>

--- Additional comment from Sandro Bonazzola on 2017-07-17 07:56:14 EDT ---

(In reply to Sahina Bose from comment #3)
> We need a way to store the he answers file generated during gdeploy, so that
> subsequent HE deploy can pick this.
> 
> Sandro, what would be best location to store this file so that Hosted engine
> deployment can automatically be invoked using hosted-engine --deploy
> --append <this file>

I'm not familiar with gdeploy, but I guess that a place like /var/lib/gdeploy/ is a good place to store data generated by gdeploy.
Not sure about how do you plan to invoke automatically
 hosted-engine --deploy --append <this file>
So my answer may change following implementation details.

--- Additional comment from Sahina Bose on 2017-07-19 01:25:30 EDT ---

(In reply to Sandro Bonazzola from comment #4)
> (In reply to Sahina Bose from comment #3)
> > We need a way to store the he answers file generated during gdeploy, so that
> > subsequent HE deploy can pick this.
> > 
> > Sandro, what would be best location to store this file so that Hosted engine
> > deployment can automatically be invoked using hosted-engine --deploy
> > --append <this file>
> 
> I'm not familiar with gdeploy, but I guess that a place like
> /var/lib/gdeploy/ is a good place to store data generated by gdeploy.
> Not sure about how do you plan to invoke automatically
>  hosted-engine --deploy --append <this file>
> So my answer may change following implementation details.

Currently, once gdeploy completes the process, user is presented with an option "Continue to Hosted Engine deployment" - this calls hosted-engine --deploy --append with the generated answer file.
The problem appears when users do not click on Continue. But come back to the Hosted engine deployment later. At this time, if the deployment takes the file that was originally created by gdeploy (if it exists in some pre-defined directory), we can solve this issue, I think. Your thoughts?

--- Additional comment from Sandro Bonazzola on 2017-07-26 03:49:53 EDT ---

(In reply to Sahina Bose from comment #5)

> Currently, once gdeploy completes the process, user is presented with an
> option "Continue to Hosted Engine deployment" - this calls hosted-engine
> --deploy --append with the generated answer file.
> The problem appears when users do not click on Continue. But come back to
> the Hosted engine deployment later. At this time, if the deployment takes
> the file that was originally created by gdeploy (if it exists in some
> pre-defined directory), we can solve this issue, I think. Your thoughts?

What if you change your mind after gdeploy execution and decide to continue with iSCSI storage on Hosted Engine?

--- Additional comment from Sahina Bose on 2017-07-26 04:51:15 EDT ---

(In reply to Sandro Bonazzola from comment #6)
> (In reply to Sahina Bose from comment #5)
> 
> > Currently, once gdeploy completes the process, user is presented with an
> > option "Continue to Hosted Engine deployment" - this calls hosted-engine
> > --deploy --append with the generated answer file.
> > The problem appears when users do not click on Continue. But come back to
> > the Hosted engine deployment later. At this time, if the deployment takes
> > the file that was originally created by gdeploy (if it exists in some
> > pre-defined directory), we can solve this issue, I think. Your thoughts?
> 
> What if you change your mind after gdeploy execution and decide to continue
> with iSCSI storage on Hosted Engine?

Isn't it very unlikely that a user would set up gluster volumes on the nodes, and then decide to use iSCSI or a different storage. We could, of course provide a work-around to delete the generated file, in such a case.

--- Additional comment from Sahina Bose on 2017-08-18 05:07:18 EDT ---

Sandro, ping.
How do you suggest we move forward with this? Is saving the generated answer file in a pre-defined location not an option?

--- Additional comment from Sandro Bonazzola on 2017-08-24 07:19:20 EDT ---

(In reply to Sahina Bose from comment #7)

> > What if you change your mind after gdeploy execution and decide to continue
> > with iSCSI storage on Hosted Engine?
> 
> Isn't it very unlikely that a user would set up gluster volumes on the
> nodes, and then decide to use iSCSI or a different storage. We could, of
> course provide a work-around to delete the generated file, in such a case.

Fine for me.
In such case, I think you can save the generated answer file in /var/lib/ovirt-hosted-engine-setup/answers with some meaningful name.
I would suggest to change the cockpit UI for checking if the file exists and if it exists show a checkbox for resuming the deployment, meaning it will execute hosted-engine --deploy appending the config file