I'm sorry, but I don't really understand the drawing
----- Original Message -----
From: "Shu Ming" <shuming(a)linux.vnet.ibm.com>
To: "Adam Litke" <agl(a)us.ibm.com>
Cc: vdsm-devel(a)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" <agl(a)us.ibm.com>
>>>>>> To: "Saggi Mizrahi" <smizrahi(a)redhat.com>
>>>>>> Cc: "Anthony Liguori" <anthony(a)codemonkey.ws>,
"VDSM Project
>>>>>> Development" <vdsm-devel(a)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(a)lists.fedorahosted.org
>>>
https://fedorahosted.org/mailman/listinfo/vdsm-devel
>>
>> _______________________________________________
>> vdsm-devel mailing list
>> vdsm-devel(a)lists.fedorahosted.org
>>
https://fedorahosted.org/mailman/listinfo/vdsm-devel
--
Shu Ming <shuming(a)linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory
_______________________________________________
vdsm-devel mailing list
vdsm-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel