Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1518697 - engine-setup upgrade of postgres to pg95 env variables not stored to answer file
Summary: engine-setup upgrade of postgres to pg95 env variables not stored to answer file
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Setup.Engine
Version: ---
Hardware: All
OS: All
medium
high vote
Target Milestone: ovirt-4.3.0
: 4.3.0
Assignee: Yedidyah Bar David
QA Contact: Lucie Leistnerova
URL:
Whiteboard:
: 1666065 (view as bug list)
Depends On:
Blocks: 1666065
TreeView+ depends on / blocked
 
Reported: 2017-11-29 13:35 UTC by Lukas Svaty
Modified: 2019-02-20 21:29 UTC (History)
11 users (show)

Fixed In Version: ovirt-engine-4.3.0_alpha
Doc Type: Enhancement
Doc Text:
Red Hat Virtualization Manager setup now uses oVirt Task Oriented Pluggable Installer/Implementation (otopi) to generate its answer files to eliminate the need for additional code or manual input on stated questions.
Clone Of:
: 1541947 1666065 (view as bug list)
Environment:
Last Closed: 2019-02-13 07:43:43 UTC
oVirt Team: Integration
rule-engine: ovirt-4.3+
rule-engine: blocker+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 85576 master MERGED packaging: setup: Generate otopi answerfiles 2018-02-28 11:45:07 UTC

Description Lukas Svaty 2017-11-29 13:35:57 UTC
Description of problem:
When generating answer file after succssful run of engine-setup (upgrade 4.1 to 4.2) some values are not stored. Therefore automated upgrade with this answer file requries manual attendence. 

Relevenat otopi questions:

This issue is blocking automated testing of upgrade process.
[WARNING] This release requires PostgreSQL server 9.5.9 but the engine database is currently hosted on PostgreSQL server 9.2.23
          This tool can automatically upgrade PostgreSQL. Automatically upgrade? (Yes, No) [Yes]: 
          The size of the PostgreSQL instance used by engine database is 64 MB.
          The destination DB will be created under '/var/opt/rh/rh-postgresql95/lib/pgsql/data' where you currently have 25.5 GB available.
          This tool can perform the DBMS upgrade:
           - copying the data files to the new instance
           - in-place hard-linking them
          Upgrading in-place is faster and doesn't require 64 MB free on the target directory, but it cannot be automatically rolled-back on failures. Please ensure you are able to restore your DBMS instance using engine-backup or other means (DB backup, FS backup, LVM snapshot).
          The in-place upgrade has the data files of the source instance on the same filesystem of the target instance (hard-links).
          Do you want to perform an in-place upgrade? (Yes, No) [No]: 
          Do you want to automatically clean up the old data directory on success to reclaim its space (64 MB)? (Yes, No) [Yes]: 
[ INFO  ] Any further action on the DB will be performed only after PostgreSQL has been successfully upgraded to 9.5.
[ INFO  ] Engine DB and DWH one are on two distinct PostgreSQL instances and both of them have to be upgraded.
[WARNING] This release requires PostgreSQL server 9.5.9 but the DWH database is currently hosted on PostgreSQL server 9.2.23
          This tool can automatically upgrade PostgreSQL. Automatically upgrade? (Yes, No) [Yes]: 
          The size of the PostgreSQL instance used by DWH database is 64 MB.
          The destination DB will be created under '/var/opt/rh/rh-postgresql95/lib/pgsql/data' where you currently have 25.5 GB available.
          This tool can perform the DBMS upgrade:
           - copying the data files to the new instance
           - in-place hard-linking them
          Upgrading in-place is faster and doesn't require 64 MB free on the target directory, but it cannot be automatically rolled-back on failures. Please ensure you are able to restore your DBMS instance using engine-backup or other means (DB backup, FS backup, LVM snapshot).
          The in-place upgrade has the data files of the source instance on the same filesystem of the target instance (hard-links).
          Do you want to perform an in-place upgrade? (Yes, No) [No]: 
          Do you want to automatically clean up the old data directory on success to reclaim its space (64 MB)? (Yes, No) [Yes]: 
[ INFO  ] Any further action on the DB will be performed only after PostgreSQL has been successfully upgraded to 9.5.


Version-Release number of selected component (if applicable):
otopi-1.7.3-1.el7ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. run engine-setup to upgrade rhv-4.1 to rhv-4.2
2. get generated answer file
3. run engine-setup --config--append=answerfile.txt

Actual results:
Requires manual input on stated questions.

Expected results:
Should not need manual interructions.

Additional info:
Please provide WA for this and specify which env values to inject to our answer file so I can lower the priority, for now it is AutomationBlocker.

Comment 1 Yedidyah Bar David 2017-11-29 13:39:14 UTC
Is it really an automation blocker? Can't you use --accept-defaults? I realize this blocks automated testing of the non-default-answers flows, some of which are quite relevant, mainly testing rollback (do you do that?).

Comment 2 Lukas Svaty 2017-11-29 13:54:15 UTC
Can't-do, we like to track changes among RHV releases, where accept-defaults would just ignore them.

Comment 3 Yedidyah Bar David 2017-12-05 09:18:37 UTC
/me is wondering if we should fix instead bug 1396925...

Comment 4 Lukas Svaty 2017-12-07 16:38:46 UTC
Didi do we have env vars we can set in answer file or outside of it to WA this issue in automation? So we will unblock QA for upgrade automation process until this o BZ#1396925 is resolved.

Comment 5 Yedidyah Bar David 2017-12-10 06:52:18 UTC
Sadly, no.

I suggest to use accept-defaults for now. Perhaps you can make this optional, so you can easily turn off/on as needed, or run part of the tests with it (those that test further things, for which you do not care much about engine-setup itself) and part without it (where you actually want to test engine-setup).

Comment 6 Yedidyah Bar David 2017-12-19 10:56:45 UTC
Lukas - now pushed and verified a patch for bug 1396925. Didn't merge yet. CI builds it though, so you can use the generated RPMs for testing, if you want.

Would you consider it a good enough solution for current bug as well?

Do you think it's a good time to get it into 4.2, or it's too late?

Merging it means you now have two kinds of answer files - one generated by engine-setup and one (optionally) by otopi. otopi's currently has no cli option to cause it to be generated - see the gerrit page.

To _use_ them, you keep using the existing --config-append option.

But, to use otopi's, you'd have to re-generate your answer file (by running manually with DIALOG/answerFile=str:/some/file and perhaps editing).

So to fully migrate QE to otopi's, you'd need to convert all your answer files. Nothing prevents doing this gradually, though. But once we merge it, we are much more likely to not ever fix anymore bugs like current, instead replying "Please use otopi's answerfile". What do you think?

Comment 7 Yedidyah Bar David 2017-12-19 11:10:19 UTC
To clarify (also for Sandro):

I didn't do anything specific for current bug, but if we have agreement, I'd like to push a patch to engine-setup to replace the existing generated answer files (both the ones in /var/lib/ovirt-engine/setup/answers and the one of '--generate-answer') with otopi-generated ones.

In theory, we can do this also in the middle of z-stream, because officially we always say that answer files are valid only for the exact same version/env they were created with. But in reality, I expect such a change to cause some noise, so it's probably better to introduce it in .0 - 4.2.0 or 4.3.0.

Comment 8 Sandro Bonazzola 2017-12-19 11:34:41 UTC
Agreed, targeting to 4.3.0

Comment 9 Red Hat Bugzilla Rules Engine 2017-12-19 11:34:48 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 10 Lukas Svaty 2018-01-08 07:48:32 UTC
Agreed with using OTOPI's answer file. If possible it would be preferred from QE side in 4.2, as this is currently there is no automated way to add non-default answers. However, I understood that this may cause significant regressions.

Comment 11 Yedidyah Bar David 2018-01-08 08:03:04 UTC
There are two mostly-independent parts here:

1. Merging bug 1396925 and using its generated answer files explicitly. In theory this is harmless. In practice this has the risk, that if e.g. QE move on to verify everything with otopi-style files, they might not run into bugs caused by using old-style files, so will not notice them. So if we go that way, we should make sure we have good coverage of both.

2. Make the files generated by engine-setup (/var/lib and --generate-answer) also have the content of bug 1396925, otopi-style answer-files. As I wrote in comment 7, I expect this to cause some noise, although I didn't do a full analysis of the kinds of problems that we should expect. But do note that existing, old-style answer files will continue to work exactly the same way, so it's not that kind of breakage. Most noise, assuming we do not have bugs :-), will probably be from people noticing the change and wondering what they need to do, if at all. More noise will come from cases where we decide to not fix some bug because it does not happen with otopi-generated files, like current bug :-), because they then feel like we force them to do a rather drastic change (rewrite/regenerate all of their answer files) in the middle of a z-stream.

Comment 12 Yedidyah Bar David 2018-01-08 09:48:19 UTC
Lukas - merged https://gerrit.ovirt.org/85551 . So once it's passing the change-queue you can use it from master snapshot. Please use it and tell me if you have issues, probably as comments on bug 1396925 or as new bugs. Now added there a comment about how to use etc.

Keeping current bug on 4.3 for now.

Comment 13 Yedidyah Bar David 2018-01-10 08:11:53 UTC
Removing AutomationBlocker, it should now be possible to automate this using bug 1396925. Keeping current bug as-is for now, for 4.3.

Comment 14 Yedidyah Bar David 2018-02-05 09:38:22 UTC
Lukas, I understand you asked to move this to 4.2.2 for QE to be able to use. I do not think you need this. You can use the functionality of bug 1396925 right now, without touching engine-setup - everything should work. Please ping me with any issues/questions. Please move bug back to 4.3, I do not want to make bug 1396925 behavior the default one in the middle of 4.2, at least not without significant testing.

Comment 15 Yedidyah Bar David 2018-02-05 09:45:45 UTC
After a private discussion with Lukas, moving back to 4.3, and cloning to a test-only bug for testing in 4.2.

Comment 16 Lukas Svaty 2018-02-05 10:02:33 UTC
We do not require it however, it's nice to have. After the conversation on IRC, this change had a huge impact on answer file and automated way of engine-setup, thus I recommend leaving it on 4.3.

Comment 17 Yedidyah Bar David 2018-02-28 12:13:37 UTC
Tareq, why do you think it's still an AutomationBlocker? See also comment 13.

Comment 18 Yedidyah Bar David 2018-02-28 12:26:57 UTC
Also note that I merged today [1] to otopi (master branch only), which changes the behavior a bit. Some relevant flows to test with it:

1.
engine-setup --otopi-environment="DIALOG/answerFile=str:/root/ans-otopi-1"

Kill it at 'PREVIEW'

engine-setup --config-append=/root/ans-otopi-1

2.
engine-setup --otopi-environment="DIALOG/answerFile=str:/root/ans-otopi-2" --accept-defaults

Kill it at 'PREVIEW'

engine-setup --config-append=/root/ans-otopi-2

Compare the behavior of (1.) and (2.). With [1], (2.) will have answers for more questions (all? not sure).

[1] https://gerrit.ovirt.org/88278

Comment 19 Tareq Alayan 2018-03-07 15:35:11 UTC
Becuase it just broke our upgrade tests that was working before.

Comment 20 Yedidyah Bar David 2018-03-07 15:44:25 UTC
OK, understood. So you might keep Regression, but I do not agree with AutomationBlocker. If the current state of 4.2 allows QE automation, with current bug unfixed, the bug does not block automation :-) Seriously, please invest time in bug 1396925, and then adapt your 4.2 automation to use it. That's the only way to get serious testing for it.

Comment 21 Tareq Alayan 2018-03-11 08:24:41 UTC
It is not blocking *all* automation it only blocks testing upgrade automatically. 
Svaty will you modify our code to work with the new style answere file?

Comment 22 Yedidyah Bar David 2018-03-11 09:40:22 UTC
Note that no *code* (logic) changes are needed, only data - generating new answer files (once) to replace your existing ones. And you do not need to change anything in where you *use* them - you pass them to '--config-append' just like the legacy ones - so can do this gradually.

Comment 23 Lukas Svaty 2018-03-19 11:55:18 UTC
Tareq, you just need to regenerate answer file for upgrade inside the oVirt repository.

Comment 24 Red Hat Bugzilla Rules Engine 2018-08-22 14:29:47 UTC
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.

Comment 25 Lucie Leistnerova 2018-09-10 08:47:46 UTC
postgres upgrade (4.1 -> 4.3) answers stored and running other upgrade with the answer file doesn't need any more interaction

verified in ovirt-engine-setup-4.3.0-0.0.master.20180903111244.git94dce75.el7.noarch.rpm

Comment 26 Sandro Bonazzola 2018-11-02 14:38:36 UTC
This bugzilla is included in oVirt 4.2.7 release, published on November 2nd 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.7 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.

Comment 27 Sandro Bonazzola 2018-11-02 14:50:38 UTC
Closed by mistake, moving back to qa -> verified

Comment 28 Sandro Bonazzola 2019-01-23 09:10:39 UTC
*** Bug 1666065 has been marked as a duplicate of this bug. ***

Comment 29 Sandro Bonazzola 2019-02-13 07:43:43 UTC
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 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.

Comment 30 Greg Scott 2019-02-20 20:57:44 UTC
Hi - just to clarify - this is fixed in 4.3; was there a backport to 4.2.z?

thanks

Comment 31 Yedidyah Bar David 2019-02-20 21:29:13 UTC
(In reply to Greg Scott from comment #30)
> Hi - just to clarify - this is fixed in 4.3; was there a backport to 4.2.z?

There was _not_ a backport - see comment 11.

bug 1396925 _was_ backported to 4.2. So the following two are equivalent:

4.2 : engine-setup --otopi-environment="DIALOG/answerFile=str:/tmp/ans1"

4.3 : engine-setup --generate-answer=/tmp/ans1


Note You need to log in before you can comment on or make changes to this bug.