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

> 
> 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

Reply via email to