[ovirt-devel] Where should the answer file for the improved HE flow be located?

[Sandro Bonazzola]

On Mon, Oct 12, 2015 at 10:06 AM, Simone Tiraboschi <stirabos at redhat.com>
wrote:

>
>
> On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <didi at redhat.com>
> wrote:
>
>> On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch at redhat.com>
>> wrote:
>> > Hey,
>> >
>> > lately we had the issue that the answer file for the engine in the HE
>> > flow changed (it required an additional answer).
>>
>> "in the HE flow" specifically?
>>
>> As discussed in private, this might best (?) be solved by adding an option
>> to engine-setup which will make it accept the default answer for each
>> question
>> where a default is supplied.
>>
>
> Yes, this one is probably the best option but it requires to add an
> additional CLI option and tweak otopi dialog to handle it if required so
> the impact is not that small.
> On my opinion is the way to go for 4.0 but for 3.6.0 it would be much
> simpler to just add the missing value in the appliance answerfile.
>

I agree that a shortcut for using defaults may be useful in general, not
only for tha HE flow.
+1 for adding it in 4.0. For 3.6 we should keep the existing architecture,
as far as I understood, the only issue we had was a missing key in the
answer file and it has been already solved.
I also think we should keep the answer file where it currently is for 3.6
scope.




>
>
>>
>> >
>> > Currently the answerfile is maintained by node in the engine appliance.
>> >
>> > I wonder if it wouldn't make more sense to keep the answer file (which
>> > is solely used for the HE flow) could be maintained inside the
>> > hosted-engine-setup repository, and be packaged in a subpackage (i.e.
>> > hosted-engine-setup-answers[-3.6]).
>>
>> IIUC the appliance is not specific to HE, right? Can be used
>> independently.
>>
>> >
>> > Another thought is that the HE-setup cloud-init is already referencing
>> > the engine answerfile, if it was matained in the same package, then it
>> > should also be easier to ensure that the assumed and real paths of the
>> > answerfile match.
>> >
>> > So, if the answerfile was in that subpackage of HE-setup, we could
>> > just install that specific package inside the appliance, and the rest
>> > is left to the HE-setup logic.
>>
>> IMHO it would be best if we do not need to maintain this answerfile at
>> all.
>> If the existence of such an option would have been enough, I'd vote for
>> adding it.
>>
>> Otherwise, I'd like to understand what, if at all, in the
>> currently-maintained
>> answerfile is HE-specific, and what is different from merely accepting the
>> defaults.
>>
>
> When the user selects to deploy hosted-engine using the appliance we could
> run engine-setup there in a not interactive way, to do that we need a least
> an answerfile.
> Currently we are using two:
> - one is already inside the appliance, it contains all the appliance
> defaults. It's there to loose the coupling between hosted-engine-setup and
> engine-setup as much as possible
> - the second contains user preferences (eg. the admin password) and it's
> generated by hosted-engine-setup and injected via cloud-init
>
> In this case is the appliance we got a new rpm (the serial console proxy)
> witch requires an additional answer so, to keep that principle and couple
> as less as possible, it's answer should go inside the appliance.
>
> As Didi proposed the best long term solution is to have a default-only
> mode in engine-setup so that we could get rid of the appliance answerfile.
>
>
>
>> If we do agree eventually that such an answerfile needs to be maintained
>> manually, I agree with Tolik, who said in a private discussion that it
>> should
>> be maintained inside the package of engine-setup. Perhaps we even need
>> more
>> than one such file, depending on the answers to above :-)
>>
>> Best,
>> --
>> Didi
>>
>
>


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20151012/091235f9/attachment-0001.html>