Apologies for the late response... On 25/01/15 13:44, Moti Asayag wrote: > > > ----- Original Message ----- >> From: "Eli Mesika" <emes...@redhat.com> >> To: "Sahina Bose" <sab...@redhat.com>, "Allon Mureinik" >> <amure...@redhat.com>, "Arik Hadas" <aha...@redhat.com>, >> "Mike Kolesnik" <mkole...@redhat.com>, "Gilad Chaplik" <gchap...@redhat.com> >> Cc: "engine-de...@ovirt.org" <devel@ovirt.org> >> 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 >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel