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




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

Reply via email to