Created attachment 1099663 [details]
mac pool dialog

engine=# select * from mac_pool_ranges ;
             mac_pool_id              |     from_mac     |      to_mac      
--------------------------------------+------------------+------------------
 0000001c-001c-001c-001c-0000000000e7 | 00:1a:4a:1:4f:00 | 00:1a:4a:1:4f:ff
(1 row)

Probably 03_06_0090_add_mac_pool_ranges_to_storage_pool.sql is the issue.

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.

I 'tested' upgrade script using:

select mac_range[1], mac_range[2] from
(SELECT string_to_array(unnest(string_to_array('00:1a:4a:1a:25:00-00:1a:4a:1a:25:ff', ',')),'-') as mac_range ) as mac_ranges;

which works as expected. So it seemsw, that if there was valid range in vdc_options table, it will be correctly moved to new data structure. We need to retest this making sure, whether there's valid range in MacPoolRanges vdc option before upgrading. Jiri already has it in his queue of tasks.

If 00:1a:4a:1a:25:0 was considered as a valid address by former releases, the upgrade script should be protective and add leading zeros when needed.

(In reply to Dan Kenigsberg from comment #7)
> If 00:1a:4a:1a:25:0 was considered as a valid address by former releases,
> the upgrade script should be protective and add leading zeros when needed.

Why? Do we have customers with such issue? Looks like such a far fetched corner case, that the fix might be more complex and risky.

I did not touch anything in that 3.5.x engine. Anyway, I'll be re-trying the flow again soon (some hour).

It could be that 3.5.6's /usr/share/ovirt-engine/setup/plugins/ovirt-engine-setup/ovirt-engine/config/macrange.py could put single hexadecimal digit... But I'm not pythonista.

Only suspicious cause must be some internal code, as engine-config prevents putting single hexa digit in mac address group:

# engine-config -s MacPoolRanges=00:1a:4a:1:25:00-00:1a:4a:1:25:ff                                        
Cannot set value 00:1a:4a:1:25:00-00:1a:4a:1:25:ff to key MacPoolRanges. The range start/end is an invalid MAC address. 00:1a:4a:1:25:00 should be in a format of AA:AA:AA:AA:AA:AA


I could not reproduce with valid mac range (ie. valid mac range in 3.5.6 -> 3.6.x). Unfortunately I didn't save "setup/ovirt-engine-setup-*.log" from original VM :/

This is a part from non-problematic VM:

~~~
2015-11-20 14:11:06 DEBUG otopi.context context._executeMethod:138 Stage misc METHOD otopi.plugins.ovirt_engine_setup.ovirt_engine.config.macrange.Plugin._misc
2015-11-20 14:11:06 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:164 Database: 'None', Statement: '
                    select count(*) as count
                    from vdc_options
                    where
                        option_name=%(name)s and
                        version=%(version)s
                ', args: {'version': 'general', 'name': 'MacPoolRanges'}
2015-11-20 14:11:06 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:214 Result: [{'count': 1L}]
2015-11-20 14:11:06 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:164 Database: 'None', Statement: '
                        update vdc_options
                        set
                            option_value=%(value)s
                        where
                            option_name=%(name)s and
                            version=%(version)s
                    ', args: {'version': 'general', 'name': 'MacPoolRanges', 'value': '00:1a:4a:1a:25:00-00:1a:4a:1a:25:ff'}
2015-11-20 14:11:06 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:214 Result: []

~~~

Please inspect setup tool if it was possible to put such bad mac range. If so, it could cause problem for users...

what's the required action? Given python script was deleted in 3.6, so it can issue problem only when updating from version when this script existed. I cannot estimate the chance of this script is generating wrong macs. We can either ignore it as a not probable situation (someone should probably estimate that probability then) or we can write db upgrade script, which fixes this  wrong macs.

I suggest close-wontfix.

(In reply to Yaniv Kaul from comment #13)
> I suggest close-wontfix.

Nobody confirmed that the code could generate such mac pool (#10). If this could appear in wild (it appeared on my env by itself), we should at least know if the code was/is wrong in 3.5 engine-setup and at least document some solution for this.

I don't know the circumstances in which the python script is called. I got confirmed, that bug is there. Provided, that there are 2 random generated fields which gets badly aligned, it means 40% probability of bad MAC? Depending on pseudo-random number generator used in python. So if this script was likely to be executed, it's quite probable, that there's user with defective settings.

In 3.5, prior to changes to mac pool the code behaves like this: insufficient checks of input validity are done, and code flow changes original MAC "00:1a:4a:1:4f:00" to "00:01:a4:a1:4f:00" as a coincidence. There may be scenarios, when the code might fail, I did not check. So if python generated bad macs and code did not fail, wrong range was used. After upgrade the code behaves in similar way — what's once stored in db is considered as has-to-be-valid value.

possible update script posted to gerrit.

Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Sorry for the noise with assignee, something went wrong while setting target release.

Hi, 

Our team(network) couldn't reproduce this report, not even one time. 
I performed upgrade flows multiple times 3.5>3.6 and 3.4>3.5>3.6 and we can't get to situation that the MAC address contains an invalid MAC address range like described above^^ 

On 3.4 and 3.5 it's not possible to configure an invalid MAC address range like described above^^ via the engine-config.

In comment #11 I stated I could not reproduce, keep in mind that mac range was somehow generated (python code).

In comment #20, you can see that bad mac ranges exist in wild, so I did not fabricate the issue.

Finished a full upgrade cycle 3.4(latest av) > 3.5.7 > 3.6.2.6 with success, this report is not reproducible. DC properties are editable after upgrade.
Suggesting to move to VERIFIED on 3.6.2.6

Yaniv, pleas ack

Please consulate with assignee on how to mod the database to get the state we saw in the field and then test.

"… state we saw in the field and then test." — I'm not sure if I understand that. But if you want to get DB to state which led to inability to edit DC properties, then simple update of records in mac_pool_ranges, which makes value in column 'from_mac' or 'to_mac' defective (single char on secord or third group from the right) should bring you to defective state. Fix only treated DB data, and did not enforce check constraint on aforementioned columns, so you can easily do this.

With Martin's help we had an invalid MAC address range before the upgrade --> 

engine-config -g MacPoolRanges
MacPoolRanges: 00:1a:4a:b:7:00-00:1a:4a:b:7:ff version: general

Run upgrade from 3.5.7 > 3.6.3 -->

engine=# select * from mac_pool_ranges;
             mac_pool_id              |     from_mac      |      to_mac       
--------------------------------------+-------------------+-------------------
 0000001c-001c-001c-001c-00000000030f | 00:00:1a:4a:b7:00 | 00:00:1a:4a:b7:ff

Verified on - 3.6.3-0.1.el6