Description of problem: If a 4.1 engine has a VM with more memory than the maximum allowed, upgrade to 4.2 fails with: [ERROR] Failed to execute stage 'Misc configuration': Engine schema refresh failed setup log has: 2018-01-09 08:07:02,091+0100 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20180109080109-ftui7e.log', '-c', 'apply'] stderr: psql:/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql:2: ERROR: check constraint "vm_static_max_memory_size_lower_bound" is violated by some row FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql 2018-01-09 08:07:02,092+0100 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:374 schema.sh: FATAL: Cannot execute sql command: --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_02_0140_add_max_memory_constraint.sql 2018-01-09 08:07:02,094+0100 DEBUG otopi.context context._executeMethod:143 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 133, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 376, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2018-01-09 08:07:02,099+0100 ERROR otopi.context context._executeMethod:152 Failed to execute stage 'Misc configuration': Engine schema refresh failed This didn't happen to me personally, but was already reported several times in the users mailing list, most of them specifically about a the HostedEngine VM - not sure if that's a mere coincidence. See e.g.: http://lists.ovirt.org/pipermail/users/2018-January/086182.html We should handle this at validation stage.
Workaround (copied from link in comment 0): update vm_static set max_memory_size_mb = mem_size_mb where mem_size_mb > max_memory_size_mb
Eli - I assume that fkvalidator.sh does not handle this automatically, as this isn't a foreign key. Is it possible to make it automatically handle also such issues?
(In reply to Yedidyah Bar David from comment #2) > Eli - I assume that fkvalidator.sh does not handle this automatically, as > this isn't a foreign key. Is it possible to make it automatically handle > also such issues? Looking in the vm_static table in master I see that this CHECK exists : "vm_static_max_memory_size_lower_bound" CHECK (mem_size_mb <= max_memory_size_mb) So, the violating data was inserted there before .... The CHECK is not checking current data , just preventing new data to be inserted if it violates it CHECK and if exists to update the data accordingly Going over all the existing CHECKs automatically, understanding them and verify that all data does no violates any of them, seems to me a very complicated task (if even possible , since CHECKs are much more robust in there conditions than FKs)
(In reply to Eli Mesika from comment #3) > So, the violating data was inserted there before .... > The CHECK is not checking current data , just preventing new data to be > inserted if it violates it CHECK and if exists to update the data > accordingly sorry, some of my text was removed here : I meant to say that it is the programmer that adds the CHECK task to verify that no data violates the new CHECK and update it accordingly if needed
isn't it fixed by this commit? commit 622ebc982a4a1658d981cadc10d1d578b0ed3cc1 Author: Shmuel Melamud <smelamud> Date: Wed Dec 27 22:15:57 2017 +0200 core: Ensure that max_memory_size is not less than mem_size In 04_01_0640_add_max_memory_size_column.sql DB upgrade script, when creating the max_memory_size_mb column, it was set to 4 * mem_size_mb, but not more than 1 Tb. But since it is now allowed to have memory size more than 1 Tb, max_memory_size_mb in such cases was set to less than mem_size_mb. Adding a new upgrade script that sets max_memory_size_mb to be equal to mem_size_mb, if it is currently less than mem_size_mb. Change-Id: Ifeaadf65896444b2a9f48cfd6c1756a90f54c95a Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=1519811 Signed-off-by: Shmuel Melamud <smelamud>
As I wrote, this didn't happen to me, and at least the linked report does not have a version containing the mentioned patch. However, I do not think it would have fixed this case, because the patch adds a file "04_02_0870_fix_max_memory_size_limit.sql", and the failure is in a file which runs before it, because they are running ordered sorted by name: "04_02_0140_add_max_memory_constraint.sql". Also, not sure the flow in current bug is the same as the one verified in the other bug - which says "1. Setup a VM with mem_size_mb and min_allocated_mem to '1572864' in RHEV 3.6". So it might be something else.
(In reply to Yedidyah Bar David from comment #6) > As I wrote, this didn't happen to me, and at least the linked report does > not have a version containing the mentioned patch. However, I do not think > it would have fixed this case, because the patch adds a file > "04_02_0870_fix_max_memory_size_limit.sql", and the failure is in a file > which runs before it, because they are running ordered sorted by name: > "04_02_0140_add_max_memory_constraint.sql". Also, not sure the flow in > current bug is the same as the one verified in the other bug - which says > "1. Setup a VM with mem_size_mb and min_allocated_mem to '1572864' in RHEV > 3.6". So it might be something else. In this case, the fix script should be located in he pre-upgrade directory and then data will be fixed before the constraint is added
I'm moving to 4.2.3 since workaround exists as per comment #1.
Back to 4.2.2 and high priority. Setting as blocker too.
Upgrade was successful, VM max_mem_size_mb was set to value of memory_size_mb and check constraint added. verified in ovirt-engine-setup-4.2.2.2-0.1.el7.noarch
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 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.