Re: [vdsm] [RFC] Implied UUIDs in API
On 08/31/2012 12:33 AM, Alon Bar-Lev wrote: - Original Message - From: Saggi Mizrahi smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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.) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
- Original Message - From: Juan Hernandez jhern...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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. 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 vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
On 08/31/2012 03:36 PM, Alon Bar-Lev wrote: - Original Message - From: Juan Hernandez jhern...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 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 vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins build failure for change that adds build dependencies
On 08/31/2012 12:31 AM, Adam Litke wrote: Hi, My change, http://gerrit.ovirt.org/#/c/7516/ adds the following build dependencies. Since they are not installed on the system running patch verification tests I am getting build failures. Can we get these packages installed on the testing host(s) please? +BuildRequires: gobject-introspection-devel +BuildRequires: glib2-devel +BuildRequires: json-glib-devel +BuildRequires: vala +BuildRequires: libgee-devel you should email this to infra mailing list. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Jenkins build failure for change that adds build dependencies
CCing powerful infra folks On Thu, Aug 30, 2012 at 04:31:55PM -0500, Adam Litke wrote: Hi, My change, http://gerrit.ovirt.org/#/c/7516/ adds the following build dependencies. Since they are not installed on the system running patch verification tests I am getting build failures. Can we get these packages installed on the testing host(s) please? +BuildRequires: gobject-introspection-devel +BuildRequires: glib2-devel +BuildRequires: json-glib-devel +BuildRequires: vala +BuildRequires: libgee-devel -- Adam Litke a...@us.ibm.com IBM Linux Technology Center ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] Implied UUIDs in API
- Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 jhern...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Itamar Heim ih...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Saggi Mizrahi smizr...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 smizr...@redhat.com To: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org 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 vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
