<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <<a href="mailto:fdeutsch@redhat.com">fdeutsch@redhat.com</a>> wrote:<br>
> Hey,<br>
><br>
> lately we had the issue that the answer file for the engine in the HE<br>
> flow changed (it required an additional answer).<br>
<br>
</span>"in the HE flow" specifically?<br>
<br>
As discussed in private, this might best (?) be solved by adding an option<br>
to engine-setup which will make it accept the default answer for each question<br>
where a default is supplied.<br></blockquote><div><br></div><div>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.</div><div>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. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
> Currently the answerfile is maintained by node in the engine appliance.<br>
><br>
> I wonder if it wouldn't make more sense to keep the answer file (which<br>
> is solely used for the HE flow) could be maintained inside the<br>
> hosted-engine-setup repository, and be packaged in a subpackage (i.e.<br>
> hosted-engine-setup-answers[-3.6]).<br>
<br>
</span>IIUC the appliance is not specific to HE, right? Can be used independently.<br>
<span class=""><br>
><br>
> Another thought is that the HE-setup cloud-init is already referencing<br>
> the engine answerfile, if it was matained in the same package, then it<br>
> should also be easier to ensure that the assumed and real paths of the<br>
> answerfile match.<br>
><br>
> So, if the answerfile was in that subpackage of HE-setup, we could<br>
> just install that specific package inside the appliance, and the rest<br>
> is left to the HE-setup logic.<br>
<br>
</span>IMHO it would be best if we do not need to maintain this answerfile at all.<br>
If the existence of such an option would have been enough, I'd vote for<br>
adding it.<br>
<br>
Otherwise, I'd like to understand what, if at all, in the currently-maintained<br>
answerfile is HE-specific, and what is different from merely accepting the<br>
defaults.<br></blockquote><div> </div><div>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.</div><div>Currently we are using two:</div><div>- 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</div><div>- the second contains user preferences (eg. the admin password) and it's generated by hosted-engine-setup and injected via cloud-init</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we do agree eventually that such an answerfile needs to be maintained<br>
manually, I agree with Tolik, who said in a private discussion that it should<br>
be maintained inside the package of engine-setup. Perhaps we even need more<br>
than one such file, depending on the answers to above :-)<br>
<br>
Best,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Didi<br>
</font></span></blockquote></div><br></div></div>