Created attachment 917714 [details] ovirt-engine-setup log Description of problem: Regular expression for the bridge_opts in db looks as follows: bridge_opts=^[^s=]+=[^s=]+(s+[^s=]+=[^s=]+)*$, but should be bridge_opts=^[^\s=]+=[^\s=]+(\s+[^\s=]+=[^\s=]+)*$', '3.5') Because of the missing '\' it expects s character instead of space. Version-Release number of selected component (if applicable): Steps to Reproduce: 1. Try to create bridge_opts for specific VM network on NIC with several parameters and space between them 2. 3. Actual results: Action succeeds only if you replace ' ' character with 's' character Expected results: Action should succeed with ' ' character Additional info: In ovirt-engine-setup log the regex appears with'\' characters
Alon, this is an interesting bug, as when performing a clean dev install on my machine I do not encounter this - the backslashes are preserved all the way to the DB. Could you think what the difference could be between the QE's deployment and my dev deployment, which strips away backslashes before they're stored in the DB entry?
Hi, Need more input... What stored? where? when? Sources? Thanks!
The entry Genadi mentioned above in the vdc_options table: 'bridge_opts=^[^\s=]+=[^\s=]+(\s+[^\s=]+=[^\s=]+)*$', key 'PreDefinedNetworkCustomProperties', version '3.5'. This entry is added from the 0000_config.sql DB pre-upgrade script. When I checkout the ovirt-engine-3.5 branch, compile and run engine-setup as a non-root user, the DB contains the correct string in that entry and everything works fine. On Genadi's deployment, which I suspect is installed like a normal user would install oVirt (yum install, then run engine-setup as root), the value appears in the DB with backslashes stripped, which of course causes some malfunctions. Does this make sense?
hmmm.... this is strange! we run the dbscripts in production and devenv exactly the same. I have fedora and I see this ok, maybe it is rhel thing (older psql). is this fresh system or upgrade? can you clean system and reinstall so we make sure it is reproducible?
This is fresh system and was reproduced on 2 other fresh installations
yes, probably change between postgresql-8.4 and postgresql-9.2, hope that it is not rhel specific. 8.4 --- engine=> insert into vdc_options values (9999, 'alon', '\s', 'general'); INSERT 0 1 engine=> select * from vdc_options where option_name = 'alon'; option_id | option_name | option_value | version -----------+-------------+--------------+--------- 9999 | alon | s | general (1 row) engine=> insert into vdc_options values (9999, 'alon', '\\s', 'general'); INSERT 0 1 engine=> select * from vdc_options where option_name = 'alon'; option_id | option_name | option_value | version -----------+-------------+--------------+--------- 9999 | alon | \s | general (1 row) --- 9.2 --- engine=> insert into vdc_options values (9999, 'alon', '\s', 'general'); INSERT 0 1 engine=> select * from vdc_options where option_name = 'alon'; option_id | option_name | option_value | version -----------+-------------+--------------+--------- 9999 | alon | \s | general (1 row) engine=> insert into vdc_options values (9999, 'alon', '\\s', 'general'); INSERT 0 1 engine=> select * from vdc_options where option_name = 'alon'; option_id | option_name | option_value | version -----------+-------------+--------------+--------- 9999 | alon | \\s | general (1 row) --- need to figure out how to bridge this gap.
solution: engine=> insert into vdc_options values (9999, 'alon', $q$\s$q$, 'general'); INSERT 0 1 engine=> select * from vdc_options where option_name = 'alon'; option_id | option_name | option_value | version -----------+-------------+--------------+--------- 9999 | alon | \s | general (1 row) please embed.
Thanks Alon for the quick response and solution, will do!
Verified on- oVirt Engine Version: 3.5.0-0.0.master.20140804172041.git23b558e.el6
oVirt 3.5 has been released and should include the fix for this issue.