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 Harper"<ry...@us.ibm.com>
To: "Adam Litke"<a...@us.ibm.com>
Cc: "Anthony Liguori"<aligu...@redhat.com>, "VDSM Project
Development"<vdsm-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 Litke<a...@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 Shetty"<deepa...@linux.vnet.ibm.com>
To: "Ryan Harper"<ry...@us.ibm.com>
Cc: "Saggi Mizrahi"<smizr...@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 Mizrahi<smizr...@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 designed to specify a schema for XML documents. The vdsm API doesn't use
XML documents. It is currently basic python types over RPC and we want to add
language bindings for C and Java too. The QAPI schema language already exists
in the qemu project and there is existing generator code that we can reuse. I
think it will be easier and better in the long run to use the proper schema for
the job rather than trying to contort the xsd schema stuff to fit our needs.
my understanding was providing an XSD for a REST API is kind of a standard?
as for the C bindings - having C bindings is one thing. making them part
of the core arch requires consideration on the complexity it introduces
to VDSM having multiple languages, as well as developing the transport
layers in C as well.
1) Completely define the current XMLRPC API including all functions, parameters,
and return values. Complex data structures can be broken down into their basic
types. These are: int, str, bool, list, dict, typed-dict, enum. I have already
started this process and am using Qemu's QAPI schema language. You can see that
here [1]. For an example of what that looks like describing the vdsm API see
this snippet [2].
2) Import the parser/generator code from qemu for the above schema. Vdsm will
require a few extensions such as typed-dictionaries, tuples, and type aliases.
Adapt the generator so that it can produce a libvdsm which provides API language
bindings for python, c, and java.
3) Implement a vdsm shell in terms of libvdsm. In fact, this can be largely
auto-generated from the schema and accompanying documentation. This can serve
to model how new transports can be written. For example, an AMQP implementation
can be implemented entirely outside of the vdsm project if we wished. It only
needs to talk to vdsm via libvdsm.
Maybe API layer can load API interface definition from this schema.
Then we only define the api interface at one place. :)
I am not sure now. still thinking.
I think the code for vdsm-shell can be auto-generated from the schema at build
time. I prefer this over dynamic discovery because it is much simpler.`
Easy as 1,2,3 :)
[1]
http://git.qemu.org/?p=qemu.git;a=blob;f=qapi-schema.json;h=3b6e3468b440b4b681f321c9525a3d83bea2137a;hb=HEAD
[2] http://fpaste.org/rt96/
Probably more than you bargained for when asking for more info... :)
--
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
