On Mon, Oct 12, 2015 at 10:06 AM, Simone Tiraboschi <[email protected]> wrote:
> > > On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <[email protected]> > wrote: > >> On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <[email protected]> >> 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
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
