| Summary: | [RFE] - HE wizard should keep the answers from previous runs. | ||
|---|---|---|---|
| Product: | [oVirt] cockpit-ovirt | Reporter: | Yaniv Lavi <ylavi> |
| Component: | Hosted Engine | Assignee: | Ryan Barry <rbarry> |
| Status: | CLOSED DEFERRED | QA Contact: | Ying Cui <ycui> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | bugs, cshao, didi, stirabos, weiwang, ycui |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | rule-engine:
planning_ack?
rule-engine: devel_ack? ycui: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-04-26 12:22:32 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: | |
|
Description
Yaniv Lavi
2016-09-26 12:59:40 UTC
This should be fixed in ovirt-hosted-engine-setup. There is no logic or persistent information in the HE install plugin, and we don't want to start keeping track of where previous install logs are (which are dated) or reading them from the filesystem. I'll submit a patch to ovirt-hosted-engine-setup to resolve this. (In reply to Ryan Barry from comment #1) > This should be fixed in ovirt-hosted-engine-setup. > > There is no logic or persistent information in the HE install plugin, and we > don't want to start keeping track of where previous install logs are (which > are dated) or reading them from the filesystem. > > I'll submit a patch to ovirt-hosted-engine-setup to resolve this. hosted-engine-setup is already saving an answerfile on each run, also for aborted ones, in /var/lib/ovirt-hosted-engine-setup/answers/ It is -- I think the goal of the RFE here is to automatically consume the most recent answerfile and suggest *those* answers as defaults (with the questions still presented, rather than skipped because the answerfile contains some value for it), so a failed: hosted-engine --deploy # enter some values for storage server, OVA path, etc Results in the next: hosted-engine --deploy # storage type, storage server, etc are already known from the last answerfile, and suggested as defaults so users can <enter> <enter> <enter> through until whatever answer caused a problem was found From the cockpit perspective, it's probably possible for us to list all of the answer files, find the most recent one (and guess that's what users want -- or present some list), open it, get all the values, and suggest them based on key. If we're going to do this, though, it seems that this logic should be in base hosted-engine-setup, since it applies to more use cases than just cockpit. (In reply to Ryan Barry from comment #3) > Results in the next: > hosted-engine --deploy > # storage type, storage server, etc are already known from the last > answerfile, and suggested as defaults so users can <enter> <enter> <enter> > through until whatever answer caused a problem was found you can run it with: hosted-engine --deploy --config-append=/var/lib/ovirt-hosted-engine-setup/answers/my.conf But it will consume all the available answers without letting the user review the single answer. At the moment there is no answer ordering so there is no way to keep just the answers till a specific point. (In reply to Simone Tiraboschi from comment #4)> > you can run it with: > hosted-engine --deploy > --config-append=/var/lib/ovirt-hosted-engine-setup/answers/my.conf > > But it will consume all the available answers without letting the user > review the single answer. > > At the moment there is no answer ordering so there is no way to keep just > the answers till a specific point. Right -- However, I think the goal is (Yaniv can correct me), for the cockpit hosted engine plugin to pre-fill values for questions based on the last run. This is something which could be done from the cockpit side only (though we don't want to have any specific application logic in cockpit, and this definitely counts). But there's benefit to CLI users for "hosted-engine --deploy" to also have defaults from the last run set, so there is not a need to re-enter iSCSI/NFS information (etc). But with the answers presented rather than skipping the questions. Not to keep the answers until some specific point, but to present the questions (again) with the default set to the values from the answer file. Yaniv, am I understanding this correctly? Let me get this straight. You want: 1. hosted-engine --deploy provide answers to some questions, then kill it somehow (for sake of simplicity/current bug, let's assume you killed it early, so system is not touched). 2. Run again hosted-engine --deploy Now you want, without passing any other option (?), to be asked the same questions, but have the defaults to be, instead of the "default defaults", the answers you provided in previous run. Right? Some thoughts/notes: 1. Sounds to me like an interesting and useful feature. 2. Is not really related to hosted-engine - applies equally to engine-setup. 3. In much of our current code, there is no way to do this _using_the_answerfile_. Why? Because there is no direct relation, in much of the code, between the _questions_ and the _answers_ as saved in the answerfile. See also bug 4. Actually, using the machine dialog, a client _can_ already do this today. Each question has an identifier, and the client can save somewhere this identifier together with the provided answer. Unrelated to hosted-engine's answerfile. 5. Of course, hosted-engine or otopi can also do (4.). But still, that's unrelated to the answerfile. 6. What happens if you replied differently to some answer, changing the default? It might make the defaults for the next answers irrelevant anymore when taken from saved answers - so perhaps better make them the computed, "default" default. 7. Another approach: Collect and save all (or last 3, or whatever) answers to this question, and allow choosing between them, including the computed default, as well as inputting a new one. For the command line interface, perhaps integrate this with readline, where pressing Up/DownArrow will cycle between them. In principle, the client (cockpit plugin) can again already do this today, but it might make sense to do this in otopi, together with some addition to the machine dialect protocol to expose these for clients. (In reply to Yedidyah Bar David from comment #6) > 3. In much of our current code, there is no way to do this > _using_the_answerfile_. Why? Because there is no direct relation, in much of > the code, between the _questions_ and the _answers_ as saved in the > answerfile. See also bug bug 1328776 . (In reply to Ryan Barry from comment #5) > > Yaniv, am I understanding this correctly? The goal is to not need to enter the same answers in rerun if something failed and letting you use them again. For command line? Cockpit? Both? We still do not have a clear design, but IMO we'll need at least one bug for each, perhaps more. Cockpit should be able to directly consume the CLI, since we just attach stdin/stdout and parse the otopi output anyway. We're trying very hard to avoid keeping any logic in cockpit, since we don't want to have a need to keep up with changes in the CLI and/or diverge. Option 7 (from comment#6) is pretty much the idea, I think. (In reply to Yedidyah Bar David from comment #9) > For command line? Cockpit? Both? > > We still do not have a clear design, but IMO we'll need at least one bug for > each, perhaps more. The goal is to have this in CockPit, since this is a more UI type of behavior, but this could be useful for CLI as well. (In reply to Yaniv Dary from comment #11) > (In reply to Yedidyah Bar David from comment #9) > > For command line? Cockpit? Both? > > > > We still do not have a clear design, but IMO we'll need at least one bug for > > each, perhaps more. > > The goal is to have this in CockPit, since this is a more UI type of > behavior, but this could be useful for CLI as well. OK. So I think we'll want these bugs to be opened: 1. otopi should keep the answers from previous runs 2. otopi machine dialect should extend the machine dialect to allow passing answers saved from previous runs 3. otopi should provide comfortable, interactive means, perhaps based on readline, to select between answers saved from previous run. Current bug should depend on (2.), which should depend on (1.). (3.) should depend on (1.) too, and is unrelated to current bug otherwise. *** Bug 1528806 has been marked as a duplicate of this bug. *** Closing due to capacity. |