Bug 1462006

(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:

> 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.

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>

(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.

(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?

(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?

(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.

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?

(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

Sahina, this is not marked as a blocker, please either block 4.1.7 or push to 4.1.8.

Gobinda, were you working on a patch for this?

I had call with Phillip Bailey, and he said he is already working on this and asked to assign this to him.

Hello,

  I tried verifying the bug and i have given no when the confirm setting screen has come. When i tried restarting the setup i see that cockpit UI prompts for all type of gluster storage which it is not supposed to ask. 

   I see that there is a conf file stored under /var/lib/ovirt-hosted-engine-setup/answers/ but it does not get picked up during restarting of setup.

  Am i missing some thing here?

Thanks
kasturi

(In reply to RamaKasturi from comment #13)
> Hello,

Hi! =)

> 
>   I tried verifying the bug and i have given no when the confirm setting
> screen has come. When i tried restarting the setup i see that cockpit UI
> prompts for all type of gluster storage which it is not supposed to ask.
> 
>    I see that there is a conf file stored under
> /var/lib/ovirt-hosted-engine-setup/answers/ but it does not get picked up
> during restarting of setup. 

Could you please confirm that the conf file in that directory is named "he-answer.conf"? I'm trying it now and it appears that the file is never written to /var/lib/ovirt-hosted-engine-setup/answers, which seems to be related to changes made in [1].

If "he-answer.conf" does exist at that location, please confirm that it is shown in the list of configuration files during HE deployment. The list can be found following the title "Configuration files:" and is the first line of log output.

Thanks!

[1] https://gerrit.ovirt.org/#/c/84623/

(In reply to Phillip Bailey from comment #14)
> (In reply to RamaKasturi from comment #13)
> > Hello,
> 
> Hi! =)
> 
> > 
> >   I tried verifying the bug and i have given no when the confirm setting
> > screen has come. When i tried restarting the setup i see that cockpit UI
> > prompts for all type of gluster storage which it is not supposed to ask.
> > 
> >    I see that there is a conf file stored under
> > /var/lib/ovirt-hosted-engine-setup/answers/ but it does not get picked up
> > during restarting of setup. 
> 
> Could you please confirm that the conf file in that directory is named
> "he-answer.conf"? I'm trying it now and it appears that the file is never
> written to /var/lib/ovirt-hosted-engine-setup/answers, which seems to be
> related to changes made in [1].

Philip, i see that an answer file is written but with a different name and not he-answer.conf and it is answers-<time-stamp>.conf

Following is how the conf file appears in that location

[root@yarrow ~]# ls -l /var/lib/ovirt-hosted-engine-setup/answers/
total 12
-rw-r--r--. 1 root root 2997 Dec  1 13:47 answers-20171201134740.conf
-rw-r--r--. 1 root root 3272 Dec  1 15:43 answers-20171201154337.conf
-rw-rw----. 1 root root 3457 Dec  1 16:30 answers-20171201163049.conf

> 
> If "he-answer.conf" does exist at that location, please confirm that it is
> shown in the list of configuration files during HE deployment. The list can
> be found following the title "Configuration files:" and is the first line of
> log output.
> 
> Thanks!
> 
> [1] https://gerrit.ovirt.org/#/c/84623/

(In reply to RamaKasturi from comment #15)

> Philip, i see that an answer file is written but with a different name and
> not he-answer.conf and it is answers-<time-stamp>.conf
> 
> Following is how the conf file appears in that location
> 
> [root@yarrow ~]# ls -l /var/lib/ovirt-hosted-engine-setup/answers/
> total 12
> -rw-r--r--. 1 root root 2997 Dec  1 13:47 answers-20171201134740.conf
> -rw-r--r--. 1 root root 3272 Dec  1 15:43 answers-20171201154337.conf
> -rw-rw----. 1 root root 3457 Dec  1 16:30 answers-20171201163049.conf

Ok. That's the problem, then. Those other files are general answer files used for HE setup. The gluster information is contained in the he-answer.conf file that should be written there by the gluster wizard. I'm assuming if you open the developer console in the browser while using the gluster wizard, you'll find errors related to writing and backing up the files. 

I'll notify Gobinda that there are bugs with his patch. Thanks for bringing this to our attention!

so philip, if i understand right once the gluster deployment finishes, you are expecting the he-answer.conf files to be written to this directory for your patch to work fine right? 

If that is the case, i think i would like to  move this bug back to Assigned state.

(In reply to RamaKasturi from comment #17)
> so philip, if i understand right once the gluster deployment finishes, you
> are expecting the he-answer.conf files to be written to this directory for
> your patch to work fine right? 

That is correct.
> 
> If that is the case, i think i would like to  move this bug back to Assigned
> state.

I don't believe this bug should be moved back to assigned. At this point, there's no reason to assume that there's anything wrong with the patch I've submitted to address it. I think the appropriate course of action is to note that [1] is blocking it. Once that issue is fixed, it can be determined whether my patch works as intended or not.

[1]

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1415984

Thanks Philip.

Based on https://bugzilla.redhat.com/show_bug.cgi?id=1415984#c4 will not be able to verify until the bug 1415984 is fixed.

In the external trackers i see that this patch is merged only into 4.2 and master and not 4.1 . Please correct me if i am wrong here.

(In reply to Phillip Bailey from comment #18)
> (In reply to RamaKasturi from comment #17)
> > so philip, if i understand right once the gluster deployment finishes, you
> > are expecting the he-answer.conf files to be written to this directory for
> > your patch to work fine right? 
> 
> That is correct.
> > 
> > If that is the case, i think i would like to  move this bug back to Assigned
> > state.
> 
> I don't believe this bug should be moved back to assigned. At this point,
> there's no reason to assume that there's anything wrong with the patch I've
> submitted to address it. I think the appropriate course of action is to note
> that [1] is blocking it. Once that issue is fixed, it can be determined
> whether my patch works as intended or not.
> 
> [1]

Hi Phillip, 

Looking at your patch, it checks for he-answer file and he-common file based on the file locations as present in gdeploy/constants.js
So the location for file is /usr/share/cockpit/ovirt-dashboard/gdeploy-templates/he-common.conf and /tmp/he-answer.conf.
Both these files are present, however these are not appended when deployment is continued later.

Gobinda's patch for Bug 1415984, but as far I see this should not affect this bug - since you read the location of file from constants?

Based on sahina comment, moving this bug back to assigned state.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Bug 1415984 is for 4.2 and the patch is backported to ovirt-4.2. Still I did not understand how does it affecting to 4.1?

(In reply to Sahina Bose from comment #21)

> 
> Hi Phillip, 
> 
> Looking at your patch, it checks for he-answer file and he-common file based
> on the file locations as present in gdeploy/constants.js
> So the location for file is
> /usr/share/cockpit/ovirt-dashboard/gdeploy-templates/he-common.conf and
> /tmp/he-answer.conf.
> Both these files are present, however these are not appended when deployment
> is continued later.

I just tested it on my setup and found that it was appending one of the files, but not the other. The original intention was for the wizard to ignore the he-common.conf file as it provides values that may conflict with those provided by the user in the HE wizard. I have submitted a patch to update the HE wizard to use both files. I will address the values included in the he-common.conf file separately.

> 
> Gobinda's patch for Bug 1415984, but as far I see this should not affect
> this bug - since you read the location of file from constants?

Based on my current testing (without Gobinda's pending fix), the files aren't being written correctly, which means they aren't available at the locations indicated in constants. That will still prevent the functionality from behaving correctly once my pending patch is merged, so it is still a blocker for this bug.

Tested with cockpit-ovirt-dashboard-0.10.10-0.el7ev.noarch

1. After preparing gluster environment, closed the 'Hosted Engine with Gluster' wizard.
2. While restarting the wizard, observed the new radio button with option 'Hosted Engine using existing Gluster configuration'
3. Answer files with the relevant information is found under /var/lib/ovirt-hosted-engine-setup/answers directory

This bugzilla is included in oVirt 4.1.9 release, published on Jan 24th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.1.9 release, published on Jan 24th 2018, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.