[vdsm] Using vdsm hook to exploit gluster backend of qemu
Hello, Recently there were patches posted in qemu-devel to support gluster as a block backend for qemu. This introduced new way of specifying drive location to qemu as ... -drive file=gluster:volumefile:image name where... volumefile is the gluster volume file name ( say gluster volume is pre-configured on the host ) image name is the name of the image file on the gluster mount point I wrote a vdsm standalone script using SHAREDFS ( which maps to PosixFs ) taking cues from http://www.ovirt.org/wiki/Vdsm_Standalone The conndict passed to connectStorageServer is as below... [dict(id=1, connection=kvmfs01-hs22:dpkvol, vfs_type=glusterfs, mnt_options=)] Here note that 'dpkvol' is the name of the gluster volume I and am able to create and invoke a VM backed by a image file residing on gluster mount. But since this is SHAREDFS way, the qemu -drive cmdline generated via VDSM is ... -drive file=/rhev/datacentre/mnt/ -- which eventually softlinks to the image file on the gluster mount point. I was looking to write a vdsm hook to be able to change the above to -drive file=gluster:volumefile:image name which means I would need access to some of the conndict params inside the hook, esp. the 'connection' to extract the volume name. 1) In looking at the current VDSM code, i don't see a way for the hook to know anything abt the storage domain setup. So the only way is to have the user pass a custom param which provides the path to the volumefile image and use it in the hook. Is there a better way ? Can i use the vdsm gluster plugin support inside the hook to determine the volfile from the volname, assuming I only take the volname as the custom param, and determine imagename from the existing source file = .. tag ( basename is the image name). Wouldn't it be better to provide a way for hooks to access ( readonly) storage domain parameters, so that they can use that do implement the hook logic in a more saner way ? 2) In talking to Eduardo, it seems there are discussion going on to see how prepareVolumePath and prepareImage could be exploited to fit gluster ( and in future other types) based images. I am not very clear on the image and volume code of vdsm, frankly its very complex and hard to understand due to lack of comments. I would appreciate if someone can guide me on what is the best way to achive my goal (-drive file=gluster:volumefile:image name) here. Any short term solutions if not perfect solution are also appreciated, so that I can atleast have a working setup where I just run my VDSM standaloen script and my qemu cmdline using gluster:... is generated. Currently I am using qemu:commandline tag facility of libvirt to inject the needed qemu options and hardcoding the volname, imagename but i would like to do this based on the conndict passed by the user when creating SHAREDFS domain. thanx, deepak ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. - Original Message - From: Anthony Liguori anth...@codemonkey.ws To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Adam Litke a...@us.ibm.com, Saggi Mizrahi smizr...@redhat.com Sent: Monday, June 25, 2012 10:18:33 AM Subject: [RFC] An alternative way to provide a supported interface -- libvdsm Hi, I've been reading through the API threads here and considering the options. To be honest, I worry a lot about the scope of these discussions and that there's a tremendous amount of work before we have a useful end result. I wonder if we can solve this problem by adding another layer of abstraction... As Adam is currently building a schema for VDSM's XML-RPC, we could use the QAPI code generators to build a libvdsm that provided a programmatic C interface for the XML-RPC interface. It would take some tweaking, but this could be made a supportable C interface. The rules for having a supportable C interface are basically: 1) Never change function signatures 2) Never remove functions 3) Always allocate structures in the library and/or pad 4) Only add to structures, never remove or reorder 5) Provide flags that default to zero to indicate that fields/features are not present. 6) Always zero-initialize structures Having a libvdsm would allow the transport to change over time w/o affecting end-users. There are lots of good tools for documenting C APIs and dealing with versioning of C APIs. While we can start out with a schema-generated API, over time, we can implement libvdsm in an open-coded fashion allowing old APIs to be reimplemented in terms of new APIs. From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) but may require new versions of libvdsm to talk to new versions of VDSM. That would allow for APIs to be deprecated within VDSM without breaking old clients. I think this would be an incremental approach to building a supportable API today while still giving the flexibility to make changes in the long term. And it should be fairly easy to generate a JNI binding and also port ovirt-engine to use an interface like this (since it already uses the XML-RPC API). Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
- Original Message - The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. The current API is irrelevant, we should focus on the API we will deliver for Fedora 18 / RHEL 7. I also really don't see what xmlrpc has to do with it. We specifically separated the transport from the API and the c bindings should have nothing to do with xmlrpc. - Original Message - From: Anthony Liguori anth...@codemonkey.ws To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Cc: Adam Litke a...@us.ibm.com, Saggi Mizrahi smizr...@redhat.com Sent: Monday, June 25, 2012 10:18:33 AM Subject: [RFC] An alternative way to provide a supported interface -- libvdsm Hi, I've been reading through the API threads here and considering the options. To be honest, I worry a lot about the scope of these discussions and that there's a tremendous amount of work before we have a useful end result. I wonder if we can solve this problem by adding another layer of abstraction... As Adam is currently building a schema for VDSM's XML-RPC, we could use the QAPI code generators to build a libvdsm that provided a programmatic C interface for the XML-RPC interface. It would take some tweaking, but this could be made a supportable C interface. The rules for having a supportable C interface are basically: 1) Never change function signatures 2) Never remove functions 3) Always allocate structures in the library and/or pad 4) Only add to structures, never remove or reorder 5) Provide flags that default to zero to indicate that fields/features are not present. 6) Always zero-initialize structures Having a libvdsm would allow the transport to change over time w/o affecting end-users. There are lots of good tools for documenting C APIs and dealing with versioning of C APIs. While we can start out with a schema-generated API, over time, we can implement libvdsm in an open-coded fashion allowing old APIs to be reimplemented in terms of new APIs. From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) but may require new versions of libvdsm to talk to new versions of VDSM. That would allow for APIs to be deprecated within VDSM without breaking old clients. I think this would be an incremental approach to building a supportable API today while still giving the flexibility to make changes in the long term. And it should be fairly easy to generate a JNI binding and also port ovirt-engine to use an interface like this (since it already uses the XML-RPC API). Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
On 06/27/2012 05:13 PM, Ayal Baron wrote: - Original Message - The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. The current API is irrelevant, we should focus on the API we will deliver for Fedora 18 / RHEL 7. I also really don't see what xmlrpc has to do with it. We specifically separated the transport from the API and the c bindings should have nothing to do with xmlrpc. And I'm suggesting is to make the C bindings the supported interface and make the wire protocol an implementation detail. You could then implement the C bindings (using GObject or whatever) via the XML-RPC transport if you liked. It also presents a better integration story as you could more easily expose the VDSM API as part of a large CIM/AMQP model data model if you like. Regards, Anthony Liguori - Original Message - From: Anthony Liguorianth...@codemonkey.ws To: VDSM Project Developmentvdsm-devel@lists.fedorahosted.org Cc: Adam Litkea...@us.ibm.com, Saggi Mizrahi smizr...@redhat.com Sent: Monday, June 25, 2012 10:18:33 AM Subject: [RFC] An alternative way to provide a supported interface -- libvdsm Hi, I've been reading through the API threads here and considering the options. To be honest, I worry a lot about the scope of these discussions and that there's a tremendous amount of work before we have a useful end result. I wonder if we can solve this problem by adding another layer of abstraction... As Adam is currently building a schema for VDSM's XML-RPC, we could use the QAPI code generators to build a libvdsm that provided a programmatic C interface for the XML-RPC interface. It would take some tweaking, but this could be made a supportable C interface. The rules for having a supportable C interface are basically: 1) Never change function signatures 2) Never remove functions 3) Always allocate structures in the library and/or pad 4) Only add to structures, never remove or reorder 5) Provide flags that default to zero to indicate that fields/features are not present. 6) Always zero-initialize structures Having a libvdsm would allow the transport to change over time w/o affecting end-users. There are lots of good tools for documenting C APIs and dealing with versioning of C APIs. While we can start out with a schema-generated API, over time, we can implement libvdsm in an open-coded fashion allowing old APIs to be reimplemented in terms of new APIs. From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) but may require new versions of libvdsm to talk to new versions of VDSM. That would allow for APIs to be deprecated within VDSM without breaking old clients. I think this would be an incremental approach to building a supportable API today while still giving the flexibility to make changes in the long term. And it should be fairly easy to generate a JNI binding and also port ovirt-engine to use an interface like this (since it already uses the XML-RPC API). Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
- Original Message - On 06/27/2012 05:13 PM, Ayal Baron wrote: - Original Message - The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. The current API is irrelevant, we should focus on the API we will deliver for Fedora 18 / RHEL 7. I also really don't see what xmlrpc has to do with it. We specifically separated the transport from the API and the c bindings should have nothing to do with xmlrpc. And I'm suggesting is to make the C bindings the supported interface and make the wire protocol an implementation detail. You could then implement the C bindings (using GObject or whatever) via the XML-RPC transport if you liked. It also presents a better integration story as you could more easily expose the VDSM API as part of a large CIM/AMQP model data model if you like. Sounds good then. Your previous comment: From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) Threw me off there as we would not want to keep on supporting XML-RPC. What's more, the current API has way too many things that have to go so needing to keep those would just be sad and painful. Regards, Anthony Liguori - Original Message - From: Anthony Liguorianth...@codemonkey.ws To: VDSM Project Developmentvdsm-devel@lists.fedorahosted.org Cc: Adam Litkea...@us.ibm.com, Saggi Mizrahi smizr...@redhat.com Sent: Monday, June 25, 2012 10:18:33 AM Subject: [RFC] An alternative way to provide a supported interface -- libvdsm Hi, I've been reading through the API threads here and considering the options. To be honest, I worry a lot about the scope of these discussions and that there's a tremendous amount of work before we have a useful end result. I wonder if we can solve this problem by adding another layer of abstraction... As Adam is currently building a schema for VDSM's XML-RPC, we could use the QAPI code generators to build a libvdsm that provided a programmatic C interface for the XML-RPC interface. It would take some tweaking, but this could be made a supportable C interface. The rules for having a supportable C interface are basically: 1) Never change function signatures 2) Never remove functions 3) Always allocate structures in the library and/or pad 4) Only add to structures, never remove or reorder 5) Provide flags that default to zero to indicate that fields/features are not present. 6) Always zero-initialize structures Having a libvdsm would allow the transport to change over time w/o affecting end-users. There are lots of good tools for documenting C APIs and dealing with versioning of C APIs. While we can start out with a schema-generated API, over time, we can implement libvdsm in an open-coded fashion allowing old APIs to be reimplemented in terms of new APIs. From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) but may require new versions of libvdsm to talk to new versions of VDSM. That would allow for APIs to be deprecated within VDSM without breaking old clients. I think this would be an incremental approach to building a supportable API today while still giving the flexibility to make changes in the long term. And it should be fairly easy to generate a JNI binding and also port ovirt-engine to use an interface like this (since it already uses the XML-RPC API). Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
On 06/27/2012 05:38 PM, Ayal Baron wrote: - Original Message - On 06/27/2012 05:13 PM, Ayal Baron wrote: - Original Message - The idea of having a supported C API was something I was thinking about doing (But I'd rather use gobject introspection and not schema generation) But the problem is not having a C API is using the current XML RPC API as it's base The current XML-RPC API contains a lot of decencies and inefficiencies and we would like to retire it as soon as we possibly can. Engine would like us to move to a message based API and 3rd parties want something simple like REST so it looks like no one actually wants to use XML-RPC. Not even us. I do think that having C supportability in our API is a good idea, but the current API should not be used as the base. The current API is irrelevant, we should focus on the API we will deliver for Fedora 18 / RHEL 7. I also really don't see what xmlrpc has to do with it. We specifically separated the transport from the API and the c bindings should have nothing to do with xmlrpc. And I'm suggesting is to make the C bindings the supported interface and make the wire protocol an implementation detail. You could then implement the C bindings (using GObject or whatever) via the XML-RPC transport if you liked. It also presents a better integration story as you could more easily expose the VDSM API as part of a large CIM/AMQP model data model if you like. Sounds good then. Your previous comment: From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) Threw me off there as we would not want to keep on supporting XML-RPC. What's more, the current API has way too many things that have to go so needing to keep those would just be sad and painful. libvdsm would keep XML-RPC support--not VDSM itself. IOW, libvdsm would need enough XML-RPC support to talk to old versions of VDSM. That doesn't mean libvdsm needs to expose ever possible thing that's in the current XML-RPC interface. Regards, Anthony Liguori Regards, Anthony Liguori - Original Message - From: Anthony Liguorianth...@codemonkey.ws To: VDSM Project Developmentvdsm-devel@lists.fedorahosted.org Cc: Adam Litkea...@us.ibm.com, Saggi Mizrahi smizr...@redhat.com Sent: Monday, June 25, 2012 10:18:33 AM Subject: [RFC] An alternative way to provide a supported interface -- libvdsm Hi, I've been reading through the API threads here and considering the options. To be honest, I worry a lot about the scope of these discussions and that there's a tremendous amount of work before we have a useful end result. I wonder if we can solve this problem by adding another layer of abstraction... As Adam is currently building a schema for VDSM's XML-RPC, we could use the QAPI code generators to build a libvdsm that provided a programmatic C interface for the XML-RPC interface. It would take some tweaking, but this could be made a supportable C interface. The rules for having a supportable C interface are basically: 1) Never change function signatures 2) Never remove functions 3) Always allocate structures in the library and/or pad 4) Only add to structures, never remove or reorder 5) Provide flags that default to zero to indicate that fields/features are not present. 6) Always zero-initialize structures Having a libvdsm would allow the transport to change over time w/o affecting end-users. There are lots of good tools for documenting C APIs and dealing with versioning of C APIs. While we can start out with a schema-generated API, over time, we can implement libvdsm in an open-coded fashion allowing old APIs to be reimplemented in terms of new APIs. From a compatibility perspective, libvdsm would be fully backwards compatible with old versions of VDSM (so it would keep XML-RPC support forever) but may require new versions of libvdsm to talk to new versions of VDSM. That would allow for APIs to be deprecated within VDSM without breaking old clients. I think this would be an incremental approach to building a supportable API today while still giving the flexibility to make changes in the long term. And it should be fairly easy to generate a JNI binding and also port ovirt-engine to use an interface like this (since it already uses the XML-RPC API). Regards, Anthony Liguori ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager
On 06/26/2012 11:26 AM, Adam Litke wrote: On Tue, Jun 26, 2012 at 11:11:51PM +0800, Shu Ming wrote: On 2012-6-26 20:45, Adam Litke wrote: On Tue, Jun 26, 2012 at 09:53:10AM +0800, Xu He Jie wrote: On 06/26/2012 05:19 AM, Adam Litke wrote: On Mon, Jun 25, 2012 at 05:53:31PM +0300, Dan Kenigsberg wrote: On Mon, Jun 25, 2012 at 08:28:29AM -0500, Adam Litke wrote: On Fri, Jun 22, 2012 at 06:45:43PM -0400, Andrew Cathrow wrote: - Original Message - From: Ryan Harperry...@us.ibm.com To: Adam Litkea...@us.ibm.com Cc: Anthony Liguorialigu...@redhat.com, VDSM Project Developmentvdsm-devel@lists.fedorahosted.org Sent: Friday, June 22, 2012 12:45:42 PM Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager * Adam Litkea...@us.ibm.com [2012-06-22 11:35]: On Thu, Jun 21, 2012 at 12:17:19PM +0300, Dor Laor wrote: On 06/19/2012 08:12 PM, Saggi Mizrahi wrote: - Original Message - From: Deepak C Shettydeepa...@linux.vnet.ibm.com To: Ryan Harperry...@us.ibm.com Cc: Saggi Mizrahismizr...@redhat.com, Anthony Liguori aligu...@redhat.com, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, June 19, 2012 10:58:47 AM Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager On 06/19/2012 01:13 AM, Ryan Harper wrote: * Saggi Mizrahismizr...@redhat.com [2012-06-18 10:05]: I would like to put on to the table for descussion the growing need for a way to more easily reuse of the functionality of VDSM in order to service projects other than Ovirt-Engine. Originally VDSM was created as a proprietary agent for the sole purpose of serving the then proprietary version of what is known as ovirt-engine. Red Hat, after acquiring the technology, pressed on with it's commitment to open source ideals and released the code. But just releasing code into the wild doesn't build a community or makes a project successful. Further more when building open source software you should aspire to build reusable components instead of monolithic stacks. Saggi, Thanks for sending this out. I've been trying to pull together some thoughts on what else is needed for vdsm as a community. I know that for some time downstream has been the driving force for all of the work and now with a community there are challenges in finding our own way. While we certainly don't want to make downstream efforts harder, I think we need to develop and support our own vision for what vdsm can be come, some what independent of downstream and other exploiters. Revisiting the API is definitely a much needed endeavor and I think adding some use-cases or sample applications would be useful in demonstrating whether or not we're evolving the API into something easier to use for applications beyond engine. We would like to expose a stable, documented, well supported API. This gives us a chance to rethink the VDSM API from the ground up. There is already work in progress of making the internal logic of VDSM separate enough from the API layer so we could continue feature development and bug fixing while designing the API of the future. In order to achieve this though we need to do several things: 1. Declare API supportability guidelines 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) 3. Make the API easily consumable (e.g. proper docs, example code, extending the API, etc) 4. Implement the API itself In the earlier we'd discussed working to have similarities in the modeling between the oVirt API and VDSM but that seems to have dropped off the radar. Yes, the current REST API has attempted to be compatible with the current ovirt-engine API. Going forward, I am not sure how easy this will be to maintain given than engine is built on Java and vdsm is built on Python. Could you elaborate why the language difference is an issue? Isn't this what APIs are supposed to solve? The main language issue is that ovirt-engine has built their API using a set of Java-specific frameworks (JAXB and its dependents). It's true, if you google for 'python jaxb' you will find some sourceforge projects that attempt to bring the jaxb interface to python but I don't think that's the right approach. If you're writing a java project, do things the java way. If you're writing a python project, do them the python way. Right now I am focused on defining the current API (API.py/xmlrpc) mechanically (creating a schema and API documentation). XSD is not the correct language for that task (which is why I forsee a divergence at least at first). I want to take a stab at defining the API in a beneficial, long-term manner. Adam, Can you explain why you think XSD is not the correct language? Is it because of the lacking of full python language code generator? Is it possible to modify the existing code generator to address that issue? What is the benefit to introduce a new schema/code generator to oVirt instead of changing the existing code generator? XSD is
