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? _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
