* 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

Reply via email to