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. > > > >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... :) > > > > -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
