----- Original Message -----
From: "Lior Vernia" <lvernia(a)redhat.com>
To: "Moti Asayag" <masayag(a)redhat.com>
Cc: "Martin Mucha" <mmucha(a)redhat.com>,
"engine-devel(a)ovirt.org" <devel(a)ovirt.org>, "Eli Mesika"
Sent: Thursday, January 29, 2015 2:46:40 PM
Subject: Re: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per installation
Apologies for the late response...
On 25/01/15 13:44, Moti Asayag wrote:
> ----- Original Message -----
>> From: "Eli Mesika" <emesika(a)redhat.com>
>> To: "Sahina Bose" <sabose(a)redhat.com>, "Allon
>> <amureini(a)redhat.com>, "Arik Hadas" <ahadas(a)redhat.com>,
>> "Mike Kolesnik" <mkolesni(a)redhat.com>, "Gilad
>> Cc: "engine-devel(a)ovirt.org" <devel(a)ovirt.org>
>> Sent: Wednesday, January 21, 2015 6:05:51 PM
>> Subject: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per
>> I am trying to cleanup all the data insertion to the engine DB and make it
>> more general
>> The main drive to that is DB version squashing that was done manually and
>> therefor was error prone ...
>> I know that both storage_pool_id (a.k.a DC) and vds_group_id (a.k.a
>> needs to get a different UUID per installation.
>> But I had found that UUIDs are generated per installation for also :
>> table | column/s
>> [cpu_profiles] : id
>> [gluster_services] : id
>> [mac_pools] : id
> Added Martin to comment on this one. AFAIK the id can be static for
> all installations.
Looks okay to have a static ID for the default MAC pool.
>> [permissions] : id, object_id
>> [vm_device]: device_id, vm_id
>> [vm_static] : vm_guid
>> [vnic_profiles] : id
> Added Lior to comment. In any case, we can evaluate the id by querying
> by name, hence the specific value id value shouldn't be important.
We don't need to have distinct IDs by installation, however the current
upgrade script creating the IDs (03_03_0710) creates one for each
existing network, and every deployment will have its own networks... If
your change might affect upgrades from versions < 3.3, then I don't see
how you could achieve this using static IDs.
That's not a problem
Keep in mind that we are squashing always (latest-version - 3)
So, when we squash this 03_03_0710 script
1) upgrade for current installations will be supported only from 3.4 and up, that means
that DB already run the 03_03_0710 script.
2) new installation , and then we have no problem either
The main point is that we squash only when we DON'T SUPPORT and upgrade from the
squashed version, so he problem you had mentioned never occurs
>> Please let me know if any of the above should be generated using the
>> uuid_generate_v1() function on each installation or we can have static IDs
>> for those.
>> Eli Mesika
>> Devel mailing list