Description of problem: Current version of engine-setup only creates answer-file after attempting an installation. Need ability to create answer-file template without attempting an install. This option was available in earlier versions of RHEV. Version-Release number of selected component (if applicable): 3.3 How reproducible: Very
Yes, I thought of this many times, and it is possible, however: 1. we do not know which components actually register more variables. 2. we do not know what values to put. I guess the option is to just output the keys that can be used in answer file based after setup phase, not sure what the user can do with that information, as the list is quite long and need to be digested into something that is working. The answer file of >=3.3 is much more powerful than what we had before, I am unsure that comparing them is correct.
Agree with Alon. In addition: 1. It's still quite easy to generate postinstall using the existing code, around stage SETUP or so. It will write whatever values are stored at that moment, and we can also make it write just keys. 2. The new setup can be controlled by setting values that are not normally output to the answer file. Almost all of them are undocumented currently and were made answer-file-settable mostly for future use/special cases/etc. Most of these cases are a result of 'self.environment.setdefault(<key>, <defval>)' in the code, but I am pretty certain that not all of them are, so we can quite easily create a possibly-non-complete list of them. 3. Besides the fact that previous versions had such an option, can you suggest a reasonable use case? These versions (iirc?) did not create for you a populated answer file at the end, so using this template was the only option.
What I would expect is an answer file that answers the questions usually asked during an initial RHEV-M install. There are multiple use cases:- 1) It normally takes me two or three tries to complete an initial RHEV-M install. Either something goes wrong, or I fat-finger an answer, or misinterpret a question, or .... 2) As a consultant, I like to fill out a template with all the answers before starting, and then review them with the customer. In most cases, it takes multiple iterations to get this correct. Having an answers file makes this a lot easier. 3) And then there's a scripted install, again having a template to work with makes this easier. As somebody who does a lot of product installs, I hate question and answer sessions. I would much rather prepare all my answers ahead of time.
(In reply to thunt from comment #3) > What I would expect is an answer file that answers the questions usually > asked during an initial RHEV-M install. As explained, the list of these questions is not constant but depends on various things, e.g. plugins installed etc. > > There are multiple use cases:- > 1) It normally takes me two or three tries to complete an initial RHEV-M > install. Either something goes wrong, or I fat-finger an answer, or > misinterpret a question, or .... > > 2) As a consultant, I like to fill out a template with all the answers > before starting, and then review them with the customer. In most cases, it > takes multiple iterations to get this correct. Having an answers file makes > this a lot easier. > > 3) And then there's a scripted install, again having a template to work with > makes this easier. > > As somebody who does a lot of product installs, I hate question and answer > sessions. I would much rather prepare all my answers ahead of time. I think that for all of the above, it will be enough (and perhaps even "best") if the answer file would be generated at the end of the "customization" stage (or perhaps "validation" stage), perhaps optionally (in addition to the existing one generated at the end). This way, you run setup once answering questions interactively, then can continue with the generated answer file. Makes sense? Note that I didn't test this suggestion, and in principle it might happen that a file generated in the middle will be different from a file generated in the end (as is now). Not sure it's significant, though, for your use cases. And another idea: It might help if (optionally) every question will include the key used in the answer file for it. This way, if your answer file does not include the answer to some question, you know what to add without completing a setup.
I don't think this will be used by novices. An initial Q&A session would work provided there's a "do nothing" flag so nothing actually gets changed while the file is being filled out. The idea is to be able to review all the answers before starting the install. My thought would be just to include every question that may need a human generated answer. And if an answer isn't used, that's the way it goes.
After consulting Sandro, our current plan is: * Add an option '--answerfile-only' * If this option is set: - Do not ask 'Please confirm installation settings' at end of validation - At end of validation, generate answer file and exit * If it's not set: - Do everything as is done today, except for writing the answer file at the end of validation instead of at cleanup. The generated file will be same as is created today. In particular, it will not include answers to questions asked by plugins that are currently not installed. More examples: - if you reply 'No' to 'Configure an NFS share on this server to be used as an ISO Domain', you will not be asked about its path (and ACL for 3.4+), and this will not be added to the answer file. - if you choose "Automatic" configuration of postgresql, you will not be asked about credentials, and these will not be added either. Is that ok with you?
That works for me. One question - when in answerfile-only mode, how much validation will be done on user input? Example, if an NFS share is requested, will it validate that the NFS share actually exists and is read/write accessible? My (not strong) preference is to only validate syntax, since I can conceive of using this outside of the target environment. But whichever behavior we choose, it should be clearly documented. Thanks
(In reply to thunt from comment #7) > That works for me. > > One question - when in answerfile-only mode, how much validation will be > done on user input? > > Example, if an NFS share is requested, will it validate that the NFS share > actually exists and is read/write accessible? > > My (not strong) preference is to only validate syntax, since I can conceive > of using this outside of the target environment. But whichever behavior we > choose, it should be clearly documented. > > Thanks The current change 25290 (still not merged, subject to change) does what I described in comment #6. You do want it to finish all the validation stage, because this stage does include more questions you want the answers for to be written to the file. E.g.: During execution engine service will be stopped (OK, Cancel) Do you want Setup to continue, with amount of memory less than recommended? (Yes, No) So, to answer your question, it will validate whatever that's validated until the end of 'Stage: Setup validation'. We try to make as many tests as possible at this stage, so that if we fail on one of them, we still did not change anything on the running system.
Accepted Alon's suggestion: Instead of the above description, merely make answer-file generation occur during stage Cleanup (which always happens, even if choosing 'Cancel', pressing ^C etc) instead of Closeup (happens only at the end of a successful setup).
Verified on RHEL 6.5, rhevm-3.4.0-0.10.beta2.el6ev.noarch, av5. answer file was generated after aborting setup both with ^d at the middle of the proccess and with canceling after setup validation stage.
Closing as part of 3.4.0