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?

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

Reply via email to