Created attachment 870418 [details] engine setup logs Description of problem: If rhevm-setup, dwh & reports RPMs are installed, before running the setup, and dwh & reports installations is skipped, next time the setup runs, these options (install dwh & reports) are not presented (question are not asked) Version-Release number of selected component (if applicable): AV2 How reproducible: 100% Steps to Reproduce: 1. yum install rhevm-setup, rhevm-reports 2. rhevm-setup (no for dwh & reports) 3. After successful installation, run rhevm-setup again Actual results: Expected results: Additional info:
I think this is as is by design: we don't want to ask for something we already asked in the past. However, maybe a flag for allowing to pull in new features on second run should be provided.
(In reply to Sandro Bonazzola from comment #1) > I think this is as is by design: we don't want to ask for something we > already asked in the past. However, maybe a flag for allowing to pull in new > features on second run should be provided. I think this may be already present. ENABLED flag should be reset either via editing of conf.d post file or a newly added file. Didi, can you confirm?
(In reply to Sandro Bonazzola from comment #1) > I think this is as is by design: we don't want to ask for something we > already asked in the past. However, maybe a flag for allowing to pull in new > features on second run should be provided. yes, it is by design. and this is good idea, we can add environment to present all component, new parameter at engine-setup something like --prompt-all-features. all optional components should re-display their questions... this includes not only dwh/reports... but firewall and all.
(In reply to Alon Bar-Lev from comment #3) > (In reply to Sandro Bonazzola from comment #1) > > I think this is as is by design: we don't want to ask for something we > > already asked in the past. However, maybe a flag for allowing to pull in new > > features on second run should be provided. > > yes, it is by design. > > and this is good idea, we can add environment to present all component, new > parameter at engine-setup something like --prompt-all-features. > > all optional components should re-display their questions... this includes > not only dwh/reports... but firewall and all. You intend to do that in some "sweeping" (is that the word?) way? Or add to many places "or env[PROMPT_ALL_FEATURES]"? Anyway, I postpone to 3.5 for now.
(In reply to Yedidyah Bar David from comment #4) > You intend to do that in some "sweeping" (is that the word?) way? Or add to > many places "or env[PROMPT_ALL_FEATURES]"? I thought that at initialize after of setdefault with None force set to None if PROMPT_ALL_FEATURES.
(In reply to Sandro Bonazzola from comment #1) > I think this is as is by design: we don't want to ask for something we > already asked in the past. However, maybe a flag for allowing to pull in new > features on second run should be provided. Firewall / DB are being asked mant times, for example, I don't understand why installing different components is different. I can think of use cases, when someone would like to install each part separately.
(In reply to Barak Dagan from comment #6) > (In reply to Sandro Bonazzola from comment #1) > > I think this is as is by design: we don't want to ask for something we > > already asked in the past. However, maybe a flag for allowing to pull in new > > features on second run should be provided. > > Firewall / DB are being asked mant times, for example, I don't understand > why installing different components is different. DB is asked many times? I don't think so. Firewall is asked indeed, because we thought people might get surprised if their firewall configuration will change by upgrading the engine, even if they said 'Yes' when they initially set it up. > > I can think of use cases, when someone would like to install each part > separately. I agree. Just do not think it's urgent enough for now. Do you?
(In reply to Yedidyah Bar David from comment #7) > (In reply to Barak Dagan from comment #6) > > (In reply to Sandro Bonazzola from comment #1) > > > I think this is as is by design: we don't want to ask for something we > > > already asked in the past. However, maybe a flag for allowing to pull in new > > > features on second run should be provided. > > > > Firewall / DB are being asked mant times, for example, I don't understand > > why installing different components is different. > > DB is asked many times? I don't think so. I'll have to look it again. > > Firewall is asked indeed, because we thought people might get surprised if > their firewall configuration will change by upgrading the engine, even if > they said 'Yes' when they initially set it up. > > > > > I can think of use cases, when someone would like to install each part > > separately. > > I agree. Just do not think it's urgent enough for now. Do you? Getting the workaround from c#2, I guess its not that urget. I'd recommend adding this behaviour and solution to the documentation.
> Getting the workaround from c#2, I guess its not that urget. I'd recommend > adding this behaviour and solution to the documentation. Ok, setting needinfo on myself to verify this. I personally think it's more important that the documentation clearly explains that there are not anymore 3 setup programs, and that you should yum install all the packages you want and then run just once 'engine-setup'.
Is this bug going to be fixed in 3.4 or 3.5? Yaniv
(In reply to Yaniv Dary from comment #10) > Is this bug going to be fixed in 3.4 or 3.5? > > > > Yaniv I think that 3.5 is right milestone for that as it adds new answer file variable.
Since we have a workaround in comment 2, this will be handled for 3.5.
(In reply to Yaniv Dary from comment #2) > (In reply to Sandro Bonazzola from comment #1) > > I think this is as is by design: we don't want to ask for something we > > already asked in the past. However, maybe a flag for allowing to pull in new > > features on second run should be provided. > > I think this may be already present. ENABLED flag should be reset either via > editing of conf.d post file or a newly added file. Didi, can you confirm? Confirmed: 1. installed engine (no dwh/reports) 2. engine-setup 3. installed dwh 4. engine-setup, replied 'No' to 'Configure DWH?'. 5. engine-setup - does not ask about dwh Then: engine-setup --otopi-environment='OVESETUP_DWH_CORE/enable=bool:True' behaves as if I answered 'yes' (and asks further questions about dwh) engine-setup --otopi-environment='OVESETUP_DWH_CORE/enable=none:None' asks 'configure DWH?'.
Not sure we'll solve this, as a workaround exists (comment 13). Changing severity for now.
BTW, the description does not state what the "Expected results:" are. Just asking them always (if not configured) is a one-line trivial fix - just don't keep the answer in the postinstall file. Is that what we want? Adding something like comment 3 is somewhat more work.
I'd expect these question to be asked as long as these compnentes are not configured and the setup plugins are installed. The solution presented in https://bugzilla.redhat.com/show_bug.cgi?id=1072360#c13 may be satisfied if its well documented. I'd be glad to hear PM's opinion ....
Another BTW, upstream 3.4 is already released, not sure it's sensible to change it there now. In particular, if a user runs engine-setup as described and keeps the negative answer in the postinstall file (either upstream 3.4.x or a beta tester of downstream 3.4), and we then change the code to not keep it in the postinstall file, it will require running 'engine-setup' *twice* in order to be asked about this. So if we do want to drop it from postinstall, the sooner the better. And another one - didn't test that, but I think that another workaround might be: 1. yum remove dwh 2. engine-setup 3. yum install dwh 4. engine-setup I think that (2.) will remove the answer from the postinstall file, so (4.) will ask it again. Even if works, uglier than comment 13, but might be closer to what some users might try.
(In reply to Barak Dagan from comment #16) > I'd expect these question to be asked as long as these compnentes are not > configured and the setup plugins are installed. > > The solution presented in > https://bugzilla.redhat.com/show_bug.cgi?id=1072360#c13 may be satisfied if > its well documented. I'd be glad to hear PM's opinion .... Why only these questions? If the user answers no, why don't we trust the answer?
(In reply to Alon Bar-Lev from comment #18) > (In reply to Barak Dagan from comment #16) > > I'd expect these question to be asked as long as these compnentes are not > > configured and the setup plugins are installed. > > > > The solution presented in > > https://bugzilla.redhat.com/show_bug.cgi?id=1072360#c13 may be satisfied if > > its well documented. I'd be glad to hear PM's opinion .... > > Why only these questions? > If the user answers no, why don't we trust the answer? Because there is no "remind me later" option, and the user has downloaded additional plugins, and run the setup again.
(In reply to Barak Dagan from comment #19) > (In reply to Alon Bar-Lev from comment #18) > > (In reply to Barak Dagan from comment #16) > > > I'd expect these question to be asked as long as these compnentes are not > > > configured and the setup plugins are installed. > > > > > > The solution presented in > > > https://bugzilla.redhat.com/show_bug.cgi?id=1072360#c13 may be satisfied if > > > its well documented. I'd be glad to hear PM's opinion .... > > > > Why only these questions? > > If the user answers no, why don't we trust the answer? > > Because there is no "remind me later" option, and the user has downloaded > additional plugins, and run the setup again. we can add a remind later option. but I do not understand how it related to user downloaded additional plugins, additional = ask unless were setup.
(In reply to Yedidyah Bar David from comment #15) > BTW, the description does not state what the "Expected results:" are. Just > asking them always (if not configured) is a one-line trivial fix - just > don't keep the answer in the postinstall file. Is that what we want? Adding > something like comment 3 is somewhat more work. I think the expected end result here is to add a flag for prompting dwh & Reports options when previously selected "no", ie to add a dedicated flag for -- engine-setup --otopi-environment='OVESETUP_DWH_CORE/enable=bool:True' behaves as if I answered 'yes' (and asks further questions about dwh) -- This should also be added to "--help" and to product documentation.
(In reply to Arthur Berezin from comment #21) > (In reply to Yedidyah Bar David from comment #15) > > BTW, the description does not state what the "Expected results:" are. Just > > asking them always (if not configured) is a one-line trivial fix - just > > don't keep the answer in the postinstall file. Is that what we want? Adding > > something like comment 3 is somewhat more work. > > I think the expected end result here is to add a flag for prompting dwh & > Reports options when previously selected "no", ie to add a dedicated flag for But, as Alon asked above, why just these ones? Perhaps we should add an attribute to the env 'allow_asking_again' or something like that and an option '--ask-again' that will ask again for values having this attribute. Makes sense? > > -- > engine-setup --otopi-environment='OVESETUP_DWH_CORE/enable=bool:True' > behaves as if I answered 'yes' (and asks further questions about dwh) > -- > This should also be added to "--help" and to product documentation. I wouldn't add this specific example to '--help'. Agree about doc. We might want to add '--otopi-environment' to '--help' (it's currently not there, I guess because we kept it as an "internal" option). Also note that I am pretty certain that adding 'OVESETUP_DWH_CORE/enable=bool:True' to an answer file won't help - an alternative nicer workaround not involving such an ugly command line can be to edit /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf and remove (or change) this option (and OVESETUP_REPORTS_CORE/enable). If removed, setup will ask, and then it can also be set in an answer file.
(In reply to Yedidyah Bar David from comment #22) > (In reply to Arthur Berezin from comment #21) > > (In reply to Yedidyah Bar David from comment #15) > > > BTW, the description does not state what the "Expected results:" are. Just > > > asking them always (if not configured) is a one-line trivial fix - just > > > don't keep the answer in the postinstall file. Is that what we want? Adding > > > something like comment 3 is somewhat more work. > > > > I think the expected end result here is to add a flag for prompting dwh & > > Reports options when previously selected "no", ie to add a dedicated flag for > > But, as Alon asked above, why just these ones? > > Perhaps we should add an attribute to the env 'allow_asking_again' or > something like that and an option '--ask-again' that will ask again for > values having this attribute. Makes sense? Agrees, "Why these options ?", the simple answer - because these specific options were missing in the flow I was using, different options can be missing in other flows, and as for 3.5 and up - installed & DB locations are also candidates for a change. > > > > > -- > > engine-setup --otopi-environment='OVESETUP_DWH_CORE/enable=bool:True' > > behaves as if I answered 'yes' (and asks further questions about dwh) > > -- > > This should also be added to "--help" and to product documentation. > > I wouldn't add this specific example to '--help'. Agree about doc. We might > want to add '--otopi-environment' to '--help' (it's currently not there, I > guess because we kept it as an "internal" option). Also note that I am > pretty certain that adding 'OVESETUP_DWH_CORE/enable=bool:True' to an answer > file won't help - an alternative nicer workaround not involving such an ugly > command line can be to edit > /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf and remove (or > change) this option (and OVESETUP_REPORTS_CORE/enable). If removed, setup > will ask, and then it can also be set in an answer file. IMHO, the user will find it easier to use CLI flags (found in the --help menu), or adjust his answer file rather than fixing internal files such the one mentioned above
Doesn't look like a bloker. We can add an option to pass just these two ENABLE=none
I think this case should be documented in a kbase with no other change. Tomas, can you add a kbase on this? Yaniv
Already prepared the code - didn't notice your needinfo, sorry - do you see a problem in using it? It will be useful for other things.
We decided that at this late stage it will not enter 3.5. Shirly cloned to 3.6 where we added an option to engine-setup '--reconfigure-optional-components'. Moving back to Tomas for doc/guides.
KBase article is already linked and published for this BZ. Julie do we want to extend documentation with this upgrade flow?
Not sure we want doc text for this bug - if we do, see comment 13 for the current workaround. In 3.6 we'll add a nicer option for that.
Hi Lucy, Can you have a look at this? Cheers, Julie
BTW, same workaround for reports: engine-setup --otopi-environment='OVESETUP_REPORTS_CORE/enable=bool:True' behaves as if I answered 'yes' (and asks further questions about reports) engine-setup --otopi-environment='OVESETUP_REPORTS_CORE/enable=none:None' asks 'configure Reports?'. To get both you can: engine-setup --offline --otopi-environment='OVESETUP_REPORTS_CORE/enable=bool:True OVESETUP_DWH_CORE/enable=bool:True' or, to be asked: engine-setup --offline --otopi-environment='OVESETUP_REPORTS_CORE/enable=none:None OVESETUP_DWH_CORE/enable=none:None'
This information will be useful to users. I have encountered this exact scenario myself while testing DWH and Reports installation, and successfully used one of the workarounds in Comment #36. I will add the workarounds to the overview article I have written for bug 1121878. The overview links to five possible installation scenarios for DWH and Reports. It is the most central place for this information to appear.