* 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 > > >>>I agree with the list, but I'd like to work on the redesign > > >>>discussion so > > >>>that we're not doing all of 1-4 around the existing API that's > > >>>engine-focused. > > >>> > > >>>I'm over due for posting a feature page on vdsm standalone mode, > > >>>and I > > >>>have some other thoughts on various uses. > > >>> > > >>>Some other paths of thought for use-cases I've been mulling over: > > >>> > > >>> - Simplifying using QEMU/KVM > > >>> - consuming qemu via command line > > >>> - can we manage/support developers launching qemu > > >>> directly > > >>> - consuming qemu via libvirt > > >>> - can we integrate with systems that are already using > > >>> libvirt > > >>> > > >>> - Addressing issues with libvirt > > >>> - are there kvm specific features we can exploit that > > >>> libvirt > > >>> doesn't? > > >>> > > >>> - Scale-up/fail-over > > >>> - can we support a single vdsm node, but allow for > > >>> building up > > >>> clusters/groups without bringing in something like > > >>> ovirt-engine > > >>> - can we look at decentralized fail-over for reliability > > >>> without > > >>> a central mgmt server? > > >>> > > >>> - pluggability > > >>> - can we support an API that allows for third-party > > >>> plugins to > > >>> support new features or changes in implementation? > > >> > > >>Pluggability feature would be nice. Even nicer would be the ability > > >>to > > >>introspect and figure whats supported by VDSM. For eg: It would be > > > > That's a good idea. > > I don't see folks editing the wiki page [1] w/ their comments. > > This wiki page doesn't contain all the verb for the api too. > > It would be pity to lose data suggested on the mailing list, please > > add it all to the wiki. > > > > IIRC there was a length suggestion in the past for REST api, can we > > start from it or at least the requirement/verbs it offers? > > I am currently working on producing a human and machine readable schema for > the > current (xmlrpc) API in the same format as Qemu's QAPI schema[1]. I will > post that > here when I have finished (give me a few more days to catalogue this large > API). > > This schema will help us in a number of ways: > - At last the current API will be fully catalogued and documented > - It provides a starting point for evolving the current API into something > supportable > - We can auto-generate basic inputvalidation code for the API > - We should be able to auto-generate some API bindings. > > [1]: > http://git.qemu.org/?p=qemu.git;a=blob_plain;f=qapi-schema.json;h=3b6e3468b440b4b681f321c9525a3d83bea2137a;hb=HEAD
Excellent. Qemu's schema was the first thing that came to mind as I was reading the discussion on the API supportability thread. > > > > > Regards, > > Dor > > > > [1] http://ovirt.org/wiki/VDSM_Stable_API_Plan > > > > >>nice > > >>to query what plugins/capabilities are supported and accordingly the > > >>client can take a decision and/or call the appropriate APIs w/o > > >>worrying > > >>about ENOTSUPP kind of error. > > >>It does becomes blur when we talk about Repository Engines... that > > >>was > > >>also targetted to provide pluggaibility in managing Images.. how will > > >>that co-exist with API level pluggability ? > > >> > > >>IIUC, StorageProvisioning (via libstoragemgmt) can be one such > > >>optional > > >>support that can fit as a plug-in nicely, right ? > > >You will have have an introspective verb to get supported storage engines. > > >Without the engine the hosts will not be able to log in to an image repo > > >but it will not be an API level error. You will get > > >UnsupportedRepoFormatError or something similar no matter which version of > > >VDSM you use. The error is part of the interface and engines will expose > > >their format and parameter in some way. > > >> > > >>> - kvm tool integration into the API > > >>> - there are lots of different kvm virt tools for various > > >>> tasks > > >>> and they are all stand-alone tools. Can we integrate > > >>> their > > >>> use into the node level API. Think libguestfs, > > >>> virt-install, > > >>> p2v/v2v tooling. All of these are available, but there > > >>> isn't an > > >>> easy way to use this tools through an API. > > >>> > > >>> - host management operations > > >>> - vdsm already does some host level configuration (see > > >>> networking e.g.) it would be good to think about > > >>> extending > > >>> the API to cover other areas of configuration and updates > > >>> - hardware enumeration > > >>> - driver level information > > >>> - storage configuration > > >>> (we've got a bit of a discussion going around > > >>> libstoragemgmt here) > > >>> > > >>> - performance monitoring/debugging > > >>> - is the host collecting enough information to do > > >>> debug/perf > > >>> analysis > > >>> - can we support specific configurations of a host that > > >>> optimize > > >>> for specific workloads > > >>> - and can we do this in the API such that > > >>> third-parties can > > >>> supply and maintain specific workload configurations > > >>> > > >>>>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 > > > > > > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-devel@lists.fedorahosted.org > > https://fedorahosted.org/mailman/listinfo/vdsm-devel > > -- > 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 -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ry...@us.ibm.com _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel