Hey, lately we had the issue that the answer file for the engine in the HE flow changed (it required an additional answer).

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

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.

On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <didi(a)redhat.com&gt; wrote: > On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch(a)redhat.com&gt; > 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.

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