With this update, the option '--accept-defaults' has been added to the engine-setup command. This option causes engine-setup to no longer prompt for answers that have a default. This option saves time for the user as they no longer need to answer the prompts individually if they are planning to accept the defaults and also allows other tools to run engine-setup unattended. If the engine-setup command is run using this option and a weak password is provided the user will be prompted for a stronger password because the default answer to 'Use weak password?' is No. To workaround this add the answer to an answer file. Updates needed in the installation procedure to explain this option. Addtional changes for the engine-cleanup command. Possibly engine-backup as well.
Assigning to Emma for review.
Hi Didi I'm documenting the --accept-defaults feature. Please confirm that I have understood the following correctly from the original bug. 1. This does not work for the self-hosted installation (host-deploy), according to https://bugzilla.redhat.com/show_bug.cgi?id=1270719#c8 2. For engine cleanup they must add the OK answer to this question" "All the installed ovirt components are about to be removed, data will be lost (OK, Cancel) [Cancel]:" to the answer file. Otherwise it will select Cancel 3. If you run engine-setup with only this option, and supply a too-easy admin password, you'll not be prompted 'Use weak password?', because it defaults to 'No'. So you'll be forced to supply a strong one. To workaround this, add an admin password to the answer file. 4. Please confirm whether we are trying to encourage customers to use this option by default. It was not clear from the discussion whether this is good for everyone.
(In reply to Emma Heftman from comment #2) > Hi Didi > I'm documenting the --accept-defaults feature. > Please confirm that I have understood the following correctly from the > original bug. > > > 1. This does not work for the self-hosted installation (host-deploy), > according to https://bugzilla.redhat.com/show_bug.cgi?id=1270719#c8 "host-deploy" is what runs when you Add a host to an engine (e.g. using the web admin ui, or the sdk). It's unrelated to "hosted-engine --deploy". The above comment was about host-deploy. The command-line option '--accept-defaults' was only added to 'engine-setup'. > > 2. For engine cleanup they must add the OK answer to this question" > > "All the installed ovirt components are about to be removed, data will be > lost (OK, Cancel) [Cancel]:" > > to the answer file. Otherwise it will select Cancel Generally speaking, we do not provide official documentation to the answer files, so I think you can ignore this part. > > > 3. If you run engine-setup with only this option, and supply a too-easy > admin password, you'll not be prompted 'Use weak password?', because it > defaults to 'No'. So you'll be forced to supply a strong one. > > To workaround this, add an admin password to the answer file. Again, I do not think you have to describe the answer file part. It's enough that you write something like: =========================================================================== If you use 'engine-setup' with '--accept-defaults', you will effectively be required to supply a strong admin password. Explanation: Without '--accept-defaults', if you supply a too-simple password, it prompts, asking "Use weak password?", but the default answer to this question is 'No'. So when you do pass '--accept-defaults', it will not ask it, accepting the default 'No', and then go back and ask again for another password. =========================================================================== > > 4. Please confirm whether we are trying to encourage customers to use this > option by default. It was not clear from the discussion whether this is good > for everyone. That's a great question, actually the most important one :-) I do not encourage them. Casual users that run engine-setup only sporadically, to setup/upgrade their systems, should carefully read all questions, all default answers, and only press 'Enter' when they really want the default. Users that need to run this command much more often (e.g. oVirt testers or developers), and already know what they are doing, can use this option. This is especially useful for running engine-setup unattended, by supplying all answers in the answer file (which we do not document), and using this option they make sure it will not suddenly start prompting asking a new question, e.g. if one was added in a later version than the one used to generate the answer file, if it has a default. The only other group of users that should use this option is those that completely trust us to supply sane defaults, never actually read questions or default answers (even though they should!), and simply want it to not prompt them unless strictly required. See also: http://www.ovirt.org/develop/developer-guide/engine/otopi/ https://www.ovirt.org/develop/developer-guide/engine/engine-setup/
Hi Lucy Could you please take a look at Didi's answer to question 4 above and let me know how you would like me to handle this. Sounds like it's a feature that we do not want to encourage the average user to use. Would we normally document this as a warning? Thanks. Emma
Hey Emma, I agree that it doesn't sound like we want to advertise this feature to the average user as part of a recommended procedure, and we likely do not want to mention it without some strong warnings. Based on the information provided in this bug, I think we want to do two things: 1. Acknowledge that the option exists. 2. Clearly explain the risks of using it. There is a 'Note' box at the beginning of the configuration procedure[1] that explains the way that engine-setup uses defaults. This could upgraded to an 'Important' box, and be expanded with a sentence that mentions the '--accept-defaults' option, and strongly warns the user to review the default values before accepting them. (We also briefly mention the answer file at the end of the procedure.) What do you think? [1] https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/installation_guide/#Red_Hat_Enterprise_Virtualization_Manager_Configuration_Overview
(In reply to Lucy Bopf from comment #5) > Hey Emma, > > I agree that it doesn't sound like we want to advertise this feature to the > average user as part of a recommended procedure, and we likely do not want > to mention it without some strong warnings. > > Based on the information provided in this bug, I think we want to do two > things: > > 1. Acknowledge that the option exists. > 2. Clearly explain the risks of using it. > > There is a 'Note' box at the beginning of the configuration procedure[1] > that explains the way that engine-setup uses defaults. This could upgraded > to an 'Important' box, and be expanded with a sentence that mentions the > '--accept-defaults' option, and strongly warns the user to review the > default values before accepting them. > > (We also briefly mention the answer file at the end of the procedure.) > > What do you think? > > [1] > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > html-single/installation_guide/ > #Red_Hat_Enterprise_Virtualization_Manager_Configuration_Overview I agree Lucy. Yaniv, please confirm that customers should be discourage from using this feature. If this is not the case, please explain in which circumstances we would want customers to use this.
(In reply to Emma Heftman from comment #6) > (In reply to Lucy Bopf from comment #5) > > Hey Emma, > > > > I agree that it doesn't sound like we want to advertise this feature to the > > average user as part of a recommended procedure, and we likely do not want > > to mention it without some strong warnings. > > > > Based on the information provided in this bug, I think we want to do two > > things: > > > > 1. Acknowledge that the option exists. > > 2. Clearly explain the risks of using it. > > > > There is a 'Note' box at the beginning of the configuration procedure[1] > > that explains the way that engine-setup uses defaults. This could upgraded > > to an 'Important' box, and be expanded with a sentence that mentions the > > '--accept-defaults' option, and strongly warns the user to review the > > default values before accepting them. > > > > (We also briefly mention the answer file at the end of the procedure.) > > > > What do you think? > > > > [1] > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > > html-single/installation_guide/ > > #Red_Hat_Enterprise_Virtualization_Manager_Configuration_Overview > > I agree Lucy. > > Yaniv, please confirm that customers should be discourage from using this > feature. If this is not the case, please explain in which circumstances we > would want customers to use this. Yes this is the case. We should tell users to not just if in general user cases.
Didi, can you please confirm that this option can also be used for a self-hosted engine deployment?
(In reply to Emma Heftman from comment #11) > Didi, can you please confirm that this option can also be used for a > self-hosted engine deployment? It can. It's actually already *in* use in hosted-engine deployment, if you ask it to automatically run engine-setup. So I assume that users that do not want deploy to automatically run engine-setup, will probably also not want to use this option - but they can.
(In reply to Yedidyah Bar David from comment #13) > (In reply to Emma Heftman from comment #11) > > Didi, can you please confirm that this option can also be used for a > > self-hosted engine deployment? > > It can. > > It's actually already *in* use in hosted-engine deployment, if you ask it to > automatically run engine-setup. So I assume that users that do not want > deploy to automatically run engine-setup, will probably also not want to use > this option - but they can. So you're saying that it's not a new option for self-hosted so there is nothing to add to self-hosted guide? I see that the installation guide says the following. Is this the stage where the automatic option is selected: " Specify Yes if you want cloud-init to perform the initial configuration of the Manager virtual machine. Specify Generate for cloud-init to performs tasks like setting the root password, configuring networking, configuring the host name, injecting an answers file for engine-setup to use, and running engine-setup on boot. Optionally, select Existing if you have an existing cloud-init script to take care of more sophisticated functions of cloud-init. Would you like to use cloud-init to customize the appliance on the first boot (Yes, No)[Yes]? Would you like to generate on-fly a cloud-init ISO image (of no-cloud type) or do you have an existing one (Generate, Existing)[Generate]?"
(In reply to Emma Heftman from comment #14) > (In reply to Yedidyah Bar David from comment #13) > > (In reply to Emma Heftman from comment #11) > > > Didi, can you please confirm that this option can also be used for a > > > self-hosted engine deployment? > > > > It can. > > > > It's actually already *in* use in hosted-engine deployment, if you ask it to > > automatically run engine-setup. So I assume that users that do not want > > deploy to automatically run engine-setup, will probably also not want to use > > this option - but they can. > So you're saying that it's not a new option for self-hosted so there is > nothing to add to self-hosted guide? There is no problem adding the same text also to hosted-engine guide. I am just saying I am not sure many people will use it, but I think we do want to clarify that these are the same - that people that read both guides will not have to ask themselves if these are different. > > I see that the installation guide says the following. Is this the stage > where the automatic option is selected: > > " Specify Yes if you want cloud-init to perform the initial configuration of > the Manager virtual machine. Specify Generate for cloud-init to performs > tasks like setting the root password, configuring networking, configuring > the host name, injecting an answers file for engine-setup to use, and > running engine-setup on boot. Optionally, select Existing if you have an > existing cloud-init script to take care of more sophisticated functions of > cloud-init. > > Would you like to use cloud-init to customize the appliance on the first > boot (Yes, No)[Yes]? > > Would you like to generate on-fly a cloud-init ISO image (of no-cloud type) > or do you have an existing one (Generate, Existing)[Generate]?" Yes, that's what I referred to.
(In reply to Yedidyah Bar David from comment #15) > (In reply to Emma Heftman from comment #14) > > (In reply to Yedidyah Bar David from comment #13) > > > (In reply to Emma Heftman from comment #11) > > > > Didi, can you please confirm that this option can also be used for a > > > > self-hosted engine deployment? > > > > > > It can. > > > > > > It's actually already *in* use in hosted-engine deployment, if you ask it to > > > automatically run engine-setup. So I assume that users that do not want > > > deploy to automatically run engine-setup, will probably also not want to use > > > this option - but they can. > > So you're saying that it's not a new option for self-hosted so there is > > nothing to add to self-hosted guide? > > There is no problem adding the same text also to hosted-engine guide. > > I am just saying I am not sure many people will use it, but I think we do > want to clarify that these are the same - that people that read both guides > will not have to ask themselves if these are different. > > > > > I see that the installation guide says the following. Is this the stage > > where the automatic option is selected: > > > > " Specify Yes if you want cloud-init to perform the initial configuration of > > the Manager virtual machine. Specify Generate for cloud-init to performs > > tasks like setting the root password, configuring networking, configuring > > the host name, injecting an answers file for engine-setup to use, and > > running engine-setup on boot. Optionally, select Existing if you have an > > existing cloud-init script to take care of more sophisticated functions of > > cloud-init. > > > > Would you like to use cloud-init to customize the appliance on the first > > boot (Yes, No)[Yes]? > > > > Would you like to generate on-fly a cloud-init ISO image (of no-cloud type) > > or do you have an existing one (Generate, Existing)[Generate]?" > > Yes, that's what I referred to. So if the Generate option is actually = to the accept defaults key, I don't see that it is correct to copy the same text - there is no point at which they need to use --accept-default as is.
Sorry for not being accurate. After the question about Generate, if the user replies Generate, we also ask: Automatically execute engine-setup on the engine appliance on first boot (Yes, No) [Yes]? See this in: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/self-hosted_engine_guide/deploying_self-hosted_engine If the user replies here Yes, then we run it automatically, and use --accept-defaults (the user has no control over that). If the user replies No, the user then has to run it manually, and can use '--accept-defaults'. As I said, I expect most users that reply No, to also want to have full control, thus not use --accept-defaults. But they still can.
(In reply to Yedidyah Bar David from comment #17) > Sorry for not being accurate. After the question about Generate, if the user > replies Generate, we also ask: > > Automatically execute engine-setup on the engine appliance on first boot > (Yes, No) [Yes]? > > See this in: > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > html/self-hosted_engine_guide/deploying_self-hosted_engine > > If the user replies here Yes, then we run it automatically, and use > --accept-defaults (the user has no control over that). > > If the user replies No, the user then has to run it manually, and can use > '--accept-defaults'. > > As I said, I expect most users that reply No, to also want to have full > control, thus not use --accept-defaults. But they still can. Now it makes sense. Thanks Didi!
The following documents have been published: Installation Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/installation_guide/#Red_Hat_Enterprise_Virtualization_Manager_Configuration_Overview Self-Hosted Engine Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/self-hosted_engine_guide/#Deploying_Self-Hosted_Engine