I'm sorry, but I don't really understand the drawing
----- Original Message ----- > From: "Shu Ming" <shum...@linux.vnet.ibm.com> > To: "Adam Litke" <a...@us.ibm.com> > 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" <a...@us.ibm.com> > >>>>>> To: "Saggi Mizrahi" <smizr...@redhat.com> > >>>>>> Cc: "Anthony Liguori" <anth...@codemonkey.ws>, "VDSM Project > >>>>>> Development" <vdsm-devel@lists.fedorahosted.org> > >>>>>> 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 my efforts to get this done. Describing the > >>>> output of > >>>> list(True) takes awhile :) > >>>> > >>> > >>> _______________________________________________ > >>> 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 > > > -- > Shu Ming <shum...@linux.vnet.ibm.com> > IBM China Systems and Technology Laboratory > > > _______________________________________________ > 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
