Apologies for the late response...

On 25/01/15 13:44, Moti Asayag wrote:
> 
> 
> ----- Original Message -----
>> From: "Eli Mesika" <[email protected]>
>> To: "Sahina Bose" <[email protected]>, "Allon Mureinik" 
>> <[email protected]>, "Arik Hadas" <[email protected]>,
>> "Mike Kolesnik" <[email protected]>, "Gilad Chaplik" <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> Sent: Wednesday, January 21, 2015 6:05:51 PM
>> Subject: [ovirt-devel] [DB] Diffrent UUIDs for inserted data per installation
>>
>> Hi
>>
>> 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 Cluster)
>> 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.

>>
>> 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.
>>
>>  
>>
>> Thanks
>> Eli Mesika
>>
>> _______________________________________________
>> Devel mailing list
>> [email protected]
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel

Reply via email to