Where should the answer file for the improved HE flow be located?
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. Thoughts? - fabian
On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch@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.
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. 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
On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch@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.
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
On Mon, Oct 12, 2015 at 10:06 AM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch@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
On Mon, Oct 12, 2015 at 11:22 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
On Mon, Oct 12, 2015 at 10:06 AM, Simone Tiraboschi <stirabos@redhat.com> wrote:
On Mon, Oct 12, 2015 at 7:29 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Sun, Oct 11, 2015 at 10:36 PM, Fabian Deutsch <fdeutsch@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.
Now filed [1] (and several duplicates, not sure what's wrong with bugzilla). [1] https://bugzilla.redhat.com/1270719 [RFE] Add an option to automatically accept defaults -- Didi
participants (4)
-
Fabian Deutsch -
Sandro Bonazzola -
Simone Tiraboschi -
Yedidyah Bar David