Bug 1396925
Summary: | [RFE] restructure answer-file behavior | ||
---|---|---|---|
Product: | [oVirt] otopi | Reporter: | Yedidyah Bar David <didi> |
Component: | Plugins.dialog | Assignee: | Yedidyah Bar David <didi> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavel Novotny <pnovotny> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | master | CC: | bugs, lsvaty, lveyde, mailinglists, pnovotny, ratamir, trichard, ylavi |
Target Milestone: | ovirt-4.2.1 | Keywords: | FutureFeature |
Target Release: | 1.7.6 | Flags: | ratamir:
needinfo-
rule-engine: ovirt-4.2+ grafuls: testing_plan_complete- ylavi: planning_ack+ rule-engine: devel_ack+ lsvaty: testing_ack+ |
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | otopi-1.7.6 | Doc Type: | Enhancement |
Doc Text: |
Otopi can now optionally write its own answer files, which are simpler to understand compared to tool-specific files written by existing tools that use otopi. The functionality is also different, imitating more closely the behavior without an answer file and answers provided interactively.
To generate:
engine-setup --otopi-environment=DIALOG/answerFile=str:/tmp/ans1
To use:
engine-setup --config-append=/tmp/ans1
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-03-29 10:47:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Integration | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1414915, 1541947, 1551825 |
Description
Yedidyah Bar David
2016-11-21 08:38:13 UTC
We should also add code to prevent collisions in question names - to warn/fail if the same name is used for two different questions. I think I'll simply save/restore all occurrences of each question/answer, e.g.: - Engine admin password: QUESTION/1/OVESETUP_CONFIG_ADMIN_SETUP=str:pass1 QUESTION/2/OVESETUP_CONFIG_ADMIN_SETUP=str:pass2 - Passwords do not match QUESTION/3/OVESETUP_CONFIG_ADMIN_SETUP=str:pass1 QUESTION/4/OVESETUP_CONFIG_ADMIN_SETUP=str:pass1 - Password is weak: QUESTION/1/OVESETUP_CONFIG_WEAK_ENGINE_PASSWORD=str:no - Engine admin password: QUESTION/5/OVESETUP_CONFIG_ADMIN_SETUP=str:pass1 QUESTION/6/OVESETUP_CONFIG_ADMIN_SETUP=str:pass1 - Password is weak: QUESTION/2/OVESETUP_CONFIG_WEAK_ENGINE_PASSWORD=str:yes I think it can express accurately the actual flow the interactive setup went through. (In reply to Yedidyah Bar David from comment #2) > I think it can express accurately the actual flow the interactive setup went > through. and also work well in case of bugs, which above actually is - engine-setup gives these two questions the same name: Engine admin password: Confirm engine admin password: Keeping bug in POST, machine dialog is missing and seems like it's needed. To generate: engine-setup --otopi-environment=DIALOG/answerFile=str:/tmp/ans1 To use: engine-setup --config-append=/tmp/ans1 Compared to files created by engine-setup's --generate-answer ("old-style" answer files): 1. Content will be different. Keys are Questions Names + number (occurrence), not functional entities. Values are (should be) always strings, as that's what users reply to questions. 2. Output of a run with --config-append will be different - it will look almost like an interactive run, as opposed to a run with old-style files, which does not show the questions. 3. In principle, logic can be different too, and that's a potential source of bugs. Some places in the code have assumptions about whether they run with an answer file or not (checking if a value is already supplied), and these places will now always behave as if an answer file was not supplied. We'll have to get some experience about this to know more. machine dialog patch merged, moving to modified. Functionality is almost identical to the human dialog. Example use: engine-setup --otopi-environment="DIALOG/answerFile=str:/root/ans-otopi-1 DIALOG/dialect=str:machine" - Kill it in the middle of the interaction, or re-use in another machine, or whatever. Then use the generated answer file, works with either dialogs: engine-setup --otopi-environment="DIALOG/dialect=str:machine" --config-append=/root/ans-otopi-1 engine-setup --config-append=/root/ans-otopi-1 Some notes/open questions/potential future improvements: 1. Currently, this: engine-setup --otopi-environment="DIALOG/answerFile=str:/root/ans-otopi-1" engine-setup --config-append=/root/ans-otopi-1 --otopi-environment="DIALOG/answerFile=str:/root/ans-otopi-2" Will create ans-otopi-2 with all the contents of ans-otopi-1 (plus whatever new answers provided). It's not completely clear we always want this behavior. 2. We might want to add to the machine dialog functionality to tell the client that we were supposed to ask a question but already got one. Currently this is output as a text note. 3. Code is currently specific to each dialog dialect (machine and human). If we add a new dialect one day (say, something that runs a GUI or whatever), we'll have to adapt it as well. It might make sense to unify the behavior. Verified in otopi-1.7.7-1.el7ev.noarch ovirt-engine-setup-4.2.2.4-0.1.el7.noarch ovirt-engine-setup-plugin-ovirt-engine-4.2.2.4-0.1.el7.noarch Running 'engine-setup with --otopi-environment="DIALOG/answerFile=str:/tmp/otopi-answers"' creates otopi-style aswer file /tmp/otopi-answers Command 'engine-setup --config-append=/tmp/otopi-answers' then loads the answer file as usually. The functionality is almost the same as with the answer file generated by engine-setup, with few key differences: 1) Otopi answer file contains the occurrence number of the answer, in case the user entered the answer multiple times, for example, the password confirmation(s) - see Example #1. This mimics the user behavior more realistically as it replays also the incorrect answers (except invalid values). 2) The questions and answers are shown in the console, except sensitive data - see Example #2 and #3. Showing the questions & answers during the playback makes it easier for a later inspection than searching the answers only in the answer file. Example #1: multiple attempts of password entering ~~~ console: # engine-setup --otopi-environment="DIALOG/answerFile=str:/tmp/otopi-answers" ... Engine admin password: Confirm engine admin password: [WARNING] Passwords do not match Engine admin password: Confirm engine admin password: [WARNING] Passwords do not match Engine admin password: Confirm engine admin password: [WARNING] Passwords do not match Engine admin password: Confirm engine admin password: [ ERROR ] Invalid value Use weak password? (Yes, No) [No]: yes ~~~ ~~~ answer file /tmp/otopi-answers: # OTOPI answer file, generated by human dialog [environment:default] ... QUESTION/1/OVESETUP_CONFIG_ADMIN_SETUP=str:123 QUESTION/2/OVESETUP_CONFIG_ADMIN_SETUP=str:1234 QUESTION/3/OVESETUP_CONFIG_ADMIN_SETUP=str:123 QUESTION/4/OVESETUP_CONFIG_ADMIN_SETUP=str:12# QUESTION/5/OVESETUP_CONFIG_ADMIN_SETUP=str:123 QUESTION/6/OVESETUP_CONFIG_ADMIN_SETUP=str:1233 QUESTION/7/OVESETUP_CONFIG_ADMIN_SETUP=str:123 QUESTION/8/OVESETUP_CONFIG_ADMIN_SETUP=str:123 QUESTION/1/OVESETUP_CONFIG_WEAK_ENGINE_PASSWORD=str:yes ... ~~~ Example #2: visible questions & answers ~~~ # engine-setup --config-append=/tmp/otopi-answers ... [ INFO ] Stage: Environment customization --== PRODUCT OPTIONS ==-- Configure Engine on this host (Yes, No) [Yes]: provided answer: yes Configure ovirt-provider-ovn (Yes, No) [Yes]: provided answer: no Configure Image I/O Proxy on this host? (Yes, No) [Yes]: provided answer: yes Configure WebSocket Proxy on this host (Yes, No) [Yes]: provided answer: yes ~~~ Example #3: (not) showing the sensitive data ~~~ # engine-setup --config-append=/tmp/otopi-answers ... --== OVIRT ENGINE CONFIGURATION ==-- Engine admin password: provided answer: (hidden) Confirm engine admin password: provided answer: (hidden) ~~~ Thanks for the verification and the detailed report. One area you might to inspect further, and perhaps report about and/or open RFEs/bugs about, is when mixing files. Some examples: 1. engine-setup --generate-answer=f1 engine-setup --config-append=f1 --generate-answer=f2 engine-setup --config-append=f2 engine-setup --config-append=f1 --config-append=f2 vs: 2. engine-setup --generate-answer=f1 engine-setup --config-append=f1 --otopi-environment="DIALOG/answerFile=str:f2" engine-setup --config-append=f2 engine-setup --config-append=f1 --config-append=f2 vs: 3. engine-setup --otopi-environment="DIALOG/answerFile=str:f1" engine-setup --config-append=f1 --generate-answer=f2 engine-setup --config-append=f2 engine-setup --config-append=f1 --config-append=f2 Also, all of above, but when killing engine-setup in the middle. And of course you can do this even with more files - say, you started it once, answered some questions, then decided to start over but reuse first file, and again, and again. Or, what happens if each run is in a different version, and the next ones are upgrades. Etc. Another thing to consider is what should happen with --accept-defaults. Only quite recently I pushed a patch that changes the behavior of this: https://gerrit.ovirt.org/88278 It's only in master (otopi-1.8), not in 4.2 (otopi-1.7). You might want to try both and decide if you prefer a certain behavior. Please also consider that we plan to make --generate-answer in 4.3 identical with --otopi-environment=DIALOG/answerFile , see bug 1518697. Previous comment will still apply, if the saved files f1, f2, etc. were generated in 4.2. This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. (In reply to Sandro Bonazzola from comment #11) > This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. > > Since the problem described in this bug report should be > resolved in oVirt 4.2.1 release, it has been closed with a resolution of > CURRENT RELEASE. > > If the solution does not work for you, please open a new bug report. Now that this has been closed as aparently it's been 'resolved' in oVirt 4.2.1 - is it _really_ a resolution, or is that some kind of automatec closure just because a release went out? (In reply to Sam McLeod from comment #12) > (In reply to Sandro Bonazzola from comment #11) > > This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. > > > > Since the problem described in this bug report should be > > resolved in oVirt 4.2.1 release, it has been closed with a resolution of > > CURRENT RELEASE. > > > > If the solution does not work for you, please open a new bug report. > > Now that this has been closed as aparently Why apparently? Do you think it's not resolved? > it's been 'resolved' in oVirt > 4.2.1 - is it _really_ a resolution, or is that some kind of automatec > closure just because a release went out? I guess it was semi-automatic. I guess Sandro's filter picks only bugs in VERIFIED. The move from ON_QA to VERIFIED is (hopefully?) never automatic - always done by a person that verifies. Also, please note comment 10. Current bug is on otopi, for 4.2. Bug 1518697 is on engine-setup, only for 4.3. I decided to not do this on 4.2 there, feeling it's a rather disruptive change to do inside the z-stream. Feel free to comment there if you feel otherwise. (In reply to Yedidyah Bar David from comment #13) I think I actually slightly misread this yesterday when I was a little surprised to see it had been closed, sorry for that! Noted re: comment 10, I'll keep half an eye on Bug 1518697 |