Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
Basically, my understanding is that we can generate two versions of libvdsm from the schema file for both the node and the management application. First, the transportation protocols(XMLRPC, REST-API) will depend on libvdsm(node version) to export the APIs to remote management application. Secondly, the management application can use libvdsm(application version ) to emit the remote call to the node. Also, transportation protocols like REST API and XML RPC API can also be generated automatically by the schema file with C, Java, Python bindings. On 2012-7-12 2:29, Saggi Mizrahi wrote: I'm sorry, but I don't really understand the drawing - Original Message - From: "Shu Ming" To: "Adam Litke" Cc: vdsm-devel@lists.fedorahosted.org Sent: Wednesday, July 11, 2012 10:24:49 AM Subject: Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm Adam, Maybe, I don't fully understand your proposal. Here is my understanding of libvdsm in the picture. Please check the following link for the picture. http://www.ovirt.org/wiki/File:Libvdsm.JPG http://www.ovirt.org/wiki/File:Libvdsm.JPG On 2012-7-9 21:56, Adam Litke wrote: On Fri, Jul 06, 2012 at 03:53:08PM +0300, Itamar Heim wrote: On 07/06/2012 01:15 AM, Robert Middleswarth wrote: On 07/05/2012 04:45 PM, Adam Litke wrote: On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote: - Original Message - From: "Adam Litke" To: "Saggi Mizrahi" Cc: "Anthony Liguori" , "VDSM Project Development" Sent: Thursday, July 5, 2012 2:34:50 PM Subject: Re: [RFC] An alternative way to provide a supported interface -- libvdsm On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote: 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 I want to disect this a bit to find out exactly where there might be agreement and disagreement. C API is a good thing to implement - Agreed. I also want to use gobject introspection but I don't agree that using glib precludes the use of a formalized schema. My proposal is that we write a schema definition and generate the glib C code from that schema. I agree that the _current_ xmlrpc API makes a pretty bad base from which to start a supportable API. XMLRPC is a perfectly reasonable remote/wire protocol and I think we should continue using it as a base for the next generation API. Using a schema will ensure that the new API is well-structured. There major problems with XML-RPC (and to some extent with REST as well) are high call overhead and no two way communication (push events). Basing on XML-RPC means that we will never be able to solve these issues. I am not sure I am ready to conceed that XML-RPC is too slow for our needs. Can you provide some more detail around this point and possibly suggest an alternative that has even lower overhead without sacrificing the ubiquity and usability of XML-RPC? As far as the two-way communication point, what are the options besides AMQP/ZeroMQ? Aren't these even worse from an overhead perspective than XML-RPC? Regarding two-way communication: you can write AMQP brokers based on the C API and run one on each vdsm host. Assuming the C API supports events, what else would you need? I personally think that using something like AMQP for inter-node communication and engine - node would be optimal. With a rest interface that just send messages though something like AMQP. I would also not dismiss AMQP so soon we want a bug with more than a single listener at engine side (engine, history db, maybe event correlation service). collectd as a means for statistics already supports it as well. I'm for having REST as well, but not sure as main one for a consumer like ovirt engine. I agree that a message bus could be a very useful model of communication between ovirt-engine components and multiple vdsm instances. But the complexities and dependencies of AMQP do not make it suitable for use as a low-level API. AMQP will repel new adopters. Why not establish a libvdsm that is more minimalist and can be easily used by everyone? Then AMQP brokers can be built on top of the stable API with ease. All AMQP should require of the low-level API are standard function calls and an events mechanism. Thanks Robert 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 am proposing that AMQP brokers and REST APIs could be written against the public API. In fact, they need not even live in the vdsm tree anymore if that is what we choose. Core vdsm would only be responsible for providing libvdsm and whatever language bindings
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
I'm sorry, but I don't really understand the drawing - Original Message - > From: "Shu Ming" > To: "Adam Litke" > Cc: vdsm-devel@lists.fedorahosted.org > Sent: Wednesday, July 11, 2012 10:24:49 AM > Subject: Re: [vdsm] [RFC] An alternative way to provide a supported interface > -- libvdsm > > Adam, > > Maybe, I don't fully understand your proposal. Here is my > understanding of libvdsm in the picture. Please check the following > link > for the picture. > > http://www.ovirt.org/wiki/File:Libvdsm.JPG > > > http://www.ovirt.org/wiki/File:Libvdsm.JPG > > On 2012-7-9 21:56, Adam Litke wrote: > > On Fri, Jul 06, 2012 at 03:53:08PM +0300, Itamar Heim wrote: > >> On 07/06/2012 01:15 AM, Robert Middleswarth wrote: > >>> On 07/05/2012 04:45 PM, Adam Litke wrote: > On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote: > > - Original Message - > >> From: "Adam Litke" > >> To: "Saggi Mizrahi" > >> Cc: "Anthony Liguori" , "VDSM Project > >> Development" > >> Sent: Thursday, July 5, 2012 2:34:50 PM > >> Subject: Re: [RFC] An alternative way to provide a supported > >> interface -- libvdsm > >> > >> On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote: > >>> 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 > >> I want to disect this a bit to find out exactly where there > >> might be > >> agreement > >> and disagreement. > >> > >> C API is a good thing to implement - Agreed. > >> > >> I also want to use gobject introspection but I don't agree > >> that using > >> glib > >> precludes the use of a formalized schema. My proposal is that > >> we > >> write a schema > >> definition and generate the glib C code from that schema. > >> > >> I agree that the _current_ xmlrpc API makes a pretty bad base > >> from > >> which to > >> start a supportable API. XMLRPC is a perfectly reasonable > >> remote/wire protocol > >> and I think we should continue using it as a base for the next > >> generation API. > >> Using a schema will ensure that the new API is > >> well-structured. > > There major problems with XML-RPC (and to some extent with REST > > as > > well) are high call overhead and no two way communication (push > > events). Basing on XML-RPC means that we will never be able to > > solve > > these issues. > I am not sure I am ready to conceed that XML-RPC is too slow for > our > needs. Can > you provide some more detail around this point and possibly > suggest an > alternative that has even lower overhead without sacrificing the > ubiquity and > usability of XML-RPC? As far as the two-way communication > point, what > are the > options besides AMQP/ZeroMQ? Aren't these even worse from an > overhead > perspective than XML-RPC? Regarding two-way communication: you > can > write AMQP > brokers based on the C API and run one on each vdsm host. > Assuming > the C API > supports events, what else would you need? > >>> I personally think that using something like AMQP for inter-node > >>> communication and engine - node would be optimal. With a rest > >>> interface > >>> that just send messages though something like AMQP. > >> I would also not dismiss AMQP so soon > >> we want a bug with more than a single listener at engine side > >> (engine, history db, maybe event correlation service). > >> collectd as a means for statistics already supports it as well. > >> I'm for having REST as well, but not sure as main one for a > >> consumer > >> like ovirt engine. > > I agree that a message bus could be a very useful model of > > communication between > > ovirt-engine components and multiple vdsm instances. But the > > complexities and > > dependencies of AMQP do not make it suitable for use as a low-level > > API. AMQP > > will repel new adopters. Why not establish a libvdsm that is more > > minimalist > > and can be easily used by everyone? Then AMQP brokers can be built > > on top of > > the stable API with ease. All AMQP should require of the low-level > > API are > > standard function calls and an events mechanism. > > > >>> Thanks > >>> Robert > >>> 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 am proposing that AMQP br
Re: [vdsm] [RFC] An alternative way to provide a supported interface -- libvdsm
Adam, Maybe, I don't fully understand your proposal. Here is my understanding of libvdsm in the picture. Please check the following link for the picture. http://www.ovirt.org/wiki/File:Libvdsm.JPG http://www.ovirt.org/wiki/File:Libvdsm.JPG On 2012-7-9 21:56, Adam Litke wrote: On Fri, Jul 06, 2012 at 03:53:08PM +0300, Itamar Heim wrote: On 07/06/2012 01:15 AM, Robert Middleswarth wrote: On 07/05/2012 04:45 PM, Adam Litke wrote: On Thu, Jul 05, 2012 at 03:47:42PM -0400, Saggi Mizrahi wrote: - Original Message - From: "Adam Litke" To: "Saggi Mizrahi" Cc: "Anthony Liguori" , "VDSM Project Development" Sent: Thursday, July 5, 2012 2:34:50 PM Subject: Re: [RFC] An alternative way to provide a supported interface -- libvdsm On Wed, Jun 27, 2012 at 02:50:02PM -0400, Saggi Mizrahi wrote: 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 I want to disect this a bit to find out exactly where there might be agreement and disagreement. C API is a good thing to implement - Agreed. I also want to use gobject introspection but I don't agree that using glib precludes the use of a formalized schema. My proposal is that we write a schema definition and generate the glib C code from that schema. I agree that the _current_ xmlrpc API makes a pretty bad base from which to start a supportable API. XMLRPC is a perfectly reasonable remote/wire protocol and I think we should continue using it as a base for the next generation API. Using a schema will ensure that the new API is well-structured. There major problems with XML-RPC (and to some extent with REST as well) are high call overhead and no two way communication (push events). Basing on XML-RPC means that we will never be able to solve these issues. I am not sure I am ready to conceed that XML-RPC is too slow for our needs. Can you provide some more detail around this point and possibly suggest an alternative that has even lower overhead without sacrificing the ubiquity and usability of XML-RPC? As far as the two-way communication point, what are the options besides AMQP/ZeroMQ? Aren't these even worse from an overhead perspective than XML-RPC? Regarding two-way communication: you can write AMQP brokers based on the C API and run one on each vdsm host. Assuming the C API supports events, what else would you need? I personally think that using something like AMQP for inter-node communication and engine - node would be optimal. With a rest interface that just send messages though something like AMQP. I would also not dismiss AMQP so soon we want a bug with more than a single listener at engine side (engine, history db, maybe event correlation service). collectd as a means for statistics already supports it as well. I'm for having REST as well, but not sure as main one for a consumer like ovirt engine. I agree that a message bus could be a very useful model of communication between ovirt-engine components and multiple vdsm instances. But the complexities and dependencies of AMQP do not make it suitable for use as a low-level API. AMQP will repel new adopters. Why not establish a libvdsm that is more minimalist and can be easily used by everyone? Then AMQP brokers can be built on top of the stable API with ease. All AMQP should require of the low-level API are standard function calls and an events mechanism. Thanks Robert 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 am proposing that AMQP brokers and REST APIs could be written against the public API. In fact, they need not even live in the vdsm tree anymore if that is what we choose. Core vdsm would only be responsible for providing libvdsm and whatever language bindings we want to support. If we take the libvdsm route, the only reason to even have a REST bridge is only to support OSes other then Linux which is something I'm not sure we care about at the moment. That might be true regarding the current in-tree implementation. However, I can almost guarantee that someone wanting to write a web GUI on top of standalone vdsm would want a REST API to talk to. But libvdsm makes this use case of no concern to the core vdsm developers. 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. Let's _start_ with a schema document that describes today's API and then clean it up. I think that will work better than starting from scratch. Once my schema is written I will post it and we can 'patch' it as a community until we arrive at a 1.0 version we are all happy with. +1 Ok. Redoubling
Re: [vdsm] Creating a new VM with a template
On 07/11/2012 09:08 AM, Shu Ming wrote: Hi, I created a VM with from existing template and found that the image of the new VM actually copied the image from the template instead of sharing a base from the template. I am wondering why the new VM doesn't use a new cow image as its image pointing to the base image in template. By that way, all the new VMs will share a common parent image in template and save the space in the storage domain. Is there any other concern not to do this? Under Resource Allocation did you use Thin or Clone when creating the VM from template? Thin will share the base and just use a cow image. Clone will copy the VM. Thanks Robert ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Creating a new VM with a template
Hi, I created a VM with from existing template and found that the image of the new VM actually copied the image from the template instead of sharing a base from the template. I am wondering why the new VM doesn't use a new cow image as its image pointing to the base image in template. By that way, all the new VMs will share a common parent image in template and save the space in the storage domain. Is there any other concern not to do this? -- Shu Ming IBM China Systems and Technology Laboratory ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel