The decision to declare the current API as supported or not, or opening ourselves to more then one API transport is directly related to how we decide to handle deprecation (if any), API versioning and forward\backward compatibility.
If we discover we clear path to evolve the API or support multiple transports and adhere to the (soon to be) agreed upon supportability guidelines we might choose the easy way of supporting the current API. This is why deciding how we are going to support things is the first step in the process. As a side note, having the XML-RPC operational for a version or two until the engine starts to use the new API is a non issue IMHO. ----- Original Message ----- > From: "Anthony Liguori" <anth...@codemonkey.ws> > To: "Saggi Mizrahi" <smizr...@redhat.com> > Cc: "VDSM Project Development" <vdsm-devel@lists.fedorahosted.org>, "Daniel > P. Berrange" <berra...@redhat.com>, > "Daniel Veillard" <veill...@redhat.com> > Sent: Monday, June 18, 2012 4:14:15 PM > Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager > > On 06/18/2012 10:02 AM, Saggi Mizrahi wrote: > > 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. > > > > 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 > > Adding danpb and DV as I think they can provide good advice here. > > Practically speaking, I think the most important thing to do is > clearly declare > what's supported and not supported in more detail than you probably > want to. > Realistically, you have to just support whatever you have. I don't > know that > designing a "supportable" interface can be really successful unless > you start > with that tomorrow. > > So basically, unless you plan on removing the XML-RPC interface in > the next > release, you should plan on supporting it forever... > > > 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) > > We spent so much time trying to find the best transport in QEMU with > the > resulting being something I'm ultimately unhappy with. > > The best decision we've made recently on this front is to move to a > schema-based > RPC mechanism where the transport code is all autogenerated. Python > has an > advantage in that it supports introspection although a disadvantage > in that it's > easy to end up with an ad-hoc interface by relying on passing around > dictionaries. > > > 3. Make the API easily consumable (e.g. proper docs, example > > code, extending > > the API, etc) > > Documentation is by far the most important thing IMHO. I actually > think that > simply taking the existing XML-RPC interface and adding documentation > ought to > be the first step even.. > > > 4. Implement the API itself > > I think the biggest risk in an effort like this is letting perfect > become the > enemy of good. If the goal is to open VDSM up to other applications, > you can > start today but just documenting what you have with plans to > deprecate and > improve later. > > Honestly, worrying about XML-RPC vs. REST vs. AMQP is likely going to > result in > a lot of bike shedding and grand plans. > > Regards, > > Anthony Liguori > > > All of these are dependent on one another and the permutations are > > endless. > > This is why I think we should try and work on each one separately. > > All > > discussions will be done openly on the mailing list and until the > > final version > > comes out nothing is set in stone. > > > > If you think you have anything to contribute to this process, > > please do so > > either by commenting on the discussions or by sending > > code/docs/whatever > > patches. Once the API solidifies it will be quite difficult to > > change > > fundamental things, so speak now or forever hold your peace. Note > > that this is > > just an introductory email. There will be a quick follow up email > > to kick start > > the discussions. > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel@lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/vdsm-devel > > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel
