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.
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