This week I spent some time analyzing the parameters that must be passed to all of the different VDSM API calls. For those involving complex types (dictionaries with required keys, magic strings, etc) I have attempted to document the required format and meaning of the required data. The document is in the ovirt wiki: http://ovirt.org/wiki/Vdsm_datatypes . Please take a look and correct any inaccuracies. Next, I would like to document complex return values.
One of the reasons I have done this work is in an attempt to drive some improvements into the API redesign I am working on. I think the structure of the parameters and return values should be codified somehow. I noticed in storage_connection.py that there is some validation being performed on the connection information. Do people agree that this could be way forward for field validation? Are there better methods? Thanks for your comments on this issue!
----- Original Message -----
From: "Adam Litke" agl@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Friday, December 23, 2011 2:52:06 AM Subject: VDSM Data Types
This week I spent some time analyzing the parameters that must be passed to all of the different VDSM API calls. For those involving complex types (dictionaries with required keys, magic strings, etc) I have attempted to document the required format and meaning of the required data. The document is in the ovirt wiki: http://ovirt.org/wiki/Vdsm_datatypes . Please take a look and correct any inaccuracies. Next, I would like to document complex return values.
Have not looked on all types, but at least VM_Create_t will be changed in next version (3.1), of course we'll keep backward compatibility. We must do it to support in several new features in 3.1
Regards, Igor Lvovsky
One of the reasons I have done this work is in an attempt to drive some improvements into the API redesign I am working on. I think the structure of the parameters and return values should be codified somehow. I noticed in storage_connection.py that there is some validation being performed on the connection information. Do people agree that this could be way forward for field validation? Are there better methods? Thanks for your comments on this issue!
-- Adam Litke agl@us.ibm.com IBM Linux Technology Center
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
On Fri, Dec 23, 2011 at 07:12:14AM -0500, Igor Lvovsky wrote:
----- Original Message -----
From: "Adam Litke" agl@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Friday, December 23, 2011 2:52:06 AM Subject: VDSM Data Types
This week I spent some time analyzing the parameters that must be passed to all of the different VDSM API calls. For those involving complex types (dictionaries with required keys, magic strings, etc) I have attempted to document the required format and meaning of the required data. The document is in the ovirt wiki: http://ovirt.org/wiki/Vdsm_datatypes . Please take a look and correct any inaccuracies. Next, I would like to document complex return values.
Have not looked on all types, but at least VM_Create_t will be changed in next version (3.1), of course we'll keep backward compatibility. We must do it to support in several new features in 3.1
I particular, Igor probably referes to stable device addresses: "create" verb is going to accepts a list of devices (disk, nics, etc) with their ide/pci address. Exact new API will be clearer when Igor releases the patches supporting this.
Dan.
----- Original Message -----
On Fri, Dec 23, 2011 at 07:12:14AM -0500, Igor Lvovsky wrote:
----- Original Message -----
From: "Adam Litke" agl@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Friday, December 23, 2011 2:52:06 AM Subject: VDSM Data Types
This week I spent some time analyzing the parameters that must be passed to all of the different VDSM API calls. For those involving complex types (dictionaries with required keys, magic strings, etc) I have attempted to document the required format and meaning of the required data. The document is in the ovirt wiki: http://ovirt.org/wiki/Vdsm_datatypes . Please take a look and correct any inaccuracies. Next, I would like to document complex return values.
Have not looked on all types, but at least VM_Create_t will be changed in next version (3.1), of course we'll keep backward compatibility. We must do it to support in several new features in 3.1
I particular, Igor probably referes to stable device addresses: "create" verb is going to accepts a list of devices (disk, nics, etc) with their ide/pci address. Exact new API will be clearer when Igor releases the patches supporting this.
Igor, please send WIP patches just so that everyone can see the changes you wish to push in.
Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
-----Original Message----- From: Ayal Baron [mailto:abaron@redhat.com] Sent: Sunday, December 25, 2011 3:19 PM To: Dan Kenigsberg Cc: vdsm-devel@lists.fedorahosted.org; Igor Lvovsky Subject: Re: VDSM Data Types
----- Original Message -----
On Fri, Dec 23, 2011 at 07:12:14AM -0500, Igor Lvovsky wrote:
----- Original Message -----
From: "Adam Litke" agl@us.ibm.com To: vdsm-devel@lists.fedorahosted.org Sent: Friday, December 23, 2011 2:52:06 AM Subject: VDSM Data Types
This week I spent some time analyzing the parameters that must be passed to all of the different VDSM API calls. For those involving complex types (dictionaries with required keys, magic strings, etc) I have attempted to document the required format and meaning of the required data. The document is in the ovirt wiki: http://ovirt.org/wiki/Vdsm_datatypes . Please take a look and correct any inaccuracies. Next, I would like to document complex return values.
Have not looked on all types, but at least VM_Create_t will be changed in next version (3.1), of course we'll keep backward compatibility. We must do it to support in several new features in 3.1
I particular, Igor probably referes to stable device addresses: "create" verb is going to accepts a list of devices (disk, nics, etc) with their ide/pci address. Exact new API will be clearer when Igor releases the patches supporting this.
Igor, please send WIP patches just so that everyone can see the changes you wish to push in.
I'll push it soon. Meanwhile you can look at [1] for new interface documentation.
[1] http://www.ovirt.org/wiki/Features/Design/StableDeviceAddresses
Dan. _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel@lists.stg.fedorahosted.org
-
abaron＠redhat.com -
agl＠us.ibm.com -
Dan Kenigsberg -
Igor Lvovsky