----- Original Message ----- > In my opinion the implications on the engine database storage are not > relevant, the engine can still choose to store everything as UUID if > it finds it more easier. > The only change would be that VDMS wouldn't care if they are UUIDs or > not. They can still *be* UUIDs. > The only problem is that if other managers start creating entities > you will have to be able to gracefully handle that in API responses.
Wrt db - nothing needs to change. The value is determined by engine today and can go on being a UUID even if VDSM doesn't validate it to be one. > > I also wonder why libvirt chose to validate UUIDs. Because as I said, > as long as you don't generate them the fact that the are *possibly* > unique is of no consequence to you. Seeing as the field comes to > libvirt from an XML stream there is no real issue with parsing and > putting it in a properly null terminated buffer. > For fields on which underlying components apply limitations such as the VM ID passed to libvirt I think we should validate but note in the documentation that there is no guarantee that it is a UUID as implementation may change. Wrt Daniel's comment about fixed length - I agree it is easier to deal with fixed length strings (we also rely on this in sanlock iirc) so I would keep a length limitation on the string. > The main reason I want to rid away the UUID restriction is that I > think that it will help us have namespacing. > > As VDSM's API becomes open and the ovirt-engine less centralized it > will be harder to know which VDSM side resources are owned by which > managing entity. > Being able to mangle in you data (eg. > OVIRT_ENGINE_0003-321321-321321-3213) will make it easier to know > which VMs, domains, storage connections, are owned by which entity > without actually going into implementing access controls on VDSM > resources. > > Further more, subsystems that might generate IDs in a different way > could be fitted more easily. > > ----- Original Message ----- > > From: "Alon Bar-Lev" <[email protected]> > > To: "Itamar Heim" <[email protected]> > > Cc: "Juan Hernandez" <[email protected]>, "arch" > > <[email protected]>, "VDSM Project Development" > > <[email protected]> > > Sent: Friday, August 31, 2012 9:52:33 AM > > Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > > > > > > > ----- Original Message ----- > > > From: "Itamar Heim" <[email protected]> > > > To: "Alon Bar-Lev" <[email protected]> > > > Cc: "Juan Hernandez" <[email protected]>, "arch" > > > <[email protected]>, "VDSM Project Development" > > > <[email protected]> > > > Sent: Friday, August 31, 2012 4:22:14 PM > > > Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > > > > > On 08/31/2012 03:36 PM, Alon Bar-Lev wrote: > > > > > > > > > > > > ----- Original Message ----- > > > >> From: "Juan Hernandez" <[email protected]> > > > >> To: "Alon Bar-Lev" <[email protected]> > > > >> Cc: "Itamar Heim" <[email protected]>, "arch" <[email protected]>, > > > >> "VDSM Project Development" > > > >> <[email protected]> > > > >> Sent: Friday, August 31, 2012 12:36:10 PM > > > >> Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > > >> > > > >> On 08/31/2012 11:27 AM, Alon Bar-Lev wrote: > > > >>> > > > >>> > > > >>> ----- Original Message ----- > > > >>>> From: "Itamar Heim" <[email protected]> > > > >>>> To: "Alon Bar-Lev" <[email protected]> > > > >>>> Cc: "Saggi Mizrahi" <[email protected]>, "arch" > > > >>>> <[email protected]>, "VDSM Project Development" > > > >>>> <[email protected]> > > > >>>> Sent: Friday, August 31, 2012 12:23:38 PM > > > >>>> Subject: Re: [vdsm] [RFC] Implied UUIDs in API > > > >>>> > > > >>>> On 08/31/2012 12:33 AM, Alon Bar-Lev wrote: > > > >>>>> > > > >>>>> > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Saggi Mizrahi" <[email protected]> > > > >>>>>> To: "arch" <[email protected]>, "VDSM Project Development" > > > >>>>>> <[email protected]> > > > >>>>>> Sent: Friday, August 31, 2012 12:19:46 AM > > > >>>>>> Subject: [vdsm] [RFC] Implied UUIDs in API > > > >>>>>> > > > >>>>>> Hi, in the API a lot of IDs get passed around are UUIDs. > > > >>>>>> The point is that as long as you are not the entity > > > >>>>>> generating > > > >>>>>> the > > > >>>>>> UUIDs the fact that these are UUIDs have no real > > > >>>>>> significance > > > >>>>>> to > > > >>>>>> you. > > > >>>>>> I suggest removing the validation of UUIDs from the > > > >>>>>> receiving > > > >>>>>> end. > > > >>>>>> There is no real reason to make sure these are real UUIDs. > > > >>>>>> It's another restriction we can remove from the interface > > > >>>>>> simplifying > > > >>>>>> the code and the interface. > > > >>>>>> > > > >>>>>> Just to be clear I'm not saying that we should stop using > > > >>>>>> UUIDs. > > > >>>>>> For example, vdsm will keep generating task IDs as UUIDs. > > > >>>>>> But > > > >>>>>> the > > > >>>>>> documentation will state that it could be *any* string > > > >>>>>> value. > > > >>>>>> If for some reason we choose to change the format of task > > > >>>>>> IDs. > > > >>>>>> There > > > >>>>>> will be no need to change the interface. > > > >>>>>> > > > >>>>>> The same goes for VM IDs. Currently the engine uses UUIDs > > > >>>>>> but > > > >>>>>> there > > > >>>>>> is no reason for VDSM to enforce this and limit the engine > > > >>>>>> from > > > >>>>>> ever > > > >>>>>> changing it in the future and using other string values. > > > >>>>> > > > >>>>> I agree that UUID is just a method of generating unique > > > >>>>> strings, > > > >>>>> there is no reason to validate the value nor the format. > > > >>>> > > > >>>> I'm with daniel on this one - knowing a field is a uuid > > > >>>> makes > > > >>>> it > > > >>>> easier > > > >>>> to deal with in the db and code around it compared to a > > > >>>> string > > > >>>> (stored > > > >>>> binary instead of string representation, etc.) > > > >>>> > > > >>> > > > >>> Why to store binary? > > > >> > > > >> An UUID stored in its binary format takes 16 bytes. Stored as > > > >> an > > > >> string > > > >> it takes 36 bytes, and more than 72 bytes in memory in the > > > >> engine. > > > >> The > > > >> amount of CPU needed to create/compare/etc is proportional. > > > >> > > > >> The engine takes advantage of this and uses an specialized > > > >> UUID > > > >> class > > > >> and a specialized database type to manage them. If we change > > > >> to > > > >> arbitrary strings then a *lot* of changes have to be done to > > > >> the > > > >> engine. > > > > > > > > We are trying to reduce types of vdsm to simplify the VDSM-next > > > > API. > > > > > > > > I guess it will derive a lot of changes in the engine anyway... > > > > > > > > 32->72 bytes in memory of JVM is not something that I care, JVM > > > > is > > > > not optimized for memory use in any sense. > > > > > > that doesn't mean you should abuse it. it's not a single item. > > > its > > > all > > > the items. > > > > I guess you want me to analyse our current implementation and find > > optimizations that can be done... or in different words, find > > entities we abuse now... :) > > > > > > > > > > > > > I am not sure that compare in database of binary or string has > > > > significant impact, if there is a proper indexing, and if > > > > foreign > > > > key is used to cascade. > > > > > > > > Regards, > > > > Alon. > > > > > > > > > > > > > > > _______________________________________________ > > vdsm-devel mailing list > > [email protected] > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > _______________________________________________ > vdsm-devel mailing list > [email protected] > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ Arch mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/arch
