On 2012-6-19 22:19, Saggi Mizrahi wrote:

----- Original Message -----
From: "Ryan Harper" <ry...@us.ibm.com>
To: "Saggi Mizrahi" <smizr...@redhat.com>
Cc: "Ryan Harper" <ry...@us.ibm.com>, "VDSM Project Development" 
<vdsm-devel@lists.fedorahosted.org>, "Anthony
Liguori" <aligu...@redhat.com>
Sent: Tuesday, June 19, 2012 9:30:08 AM
Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt host manager

* Saggi Mizrahi <smizr...@redhat.com> [2012-06-18 16:09]:
Ryan, thanks for commenting.

Sadly I feel that your points, though important, are a bit of a
digression from the main discussion.  Internal architectural
changes
to VDSM are out of the scope as this should be done on a very tight
schedual.
I don't think I was suggesting internal architectural changes.  I may
not yet be familiar enough with to code to understand that modifying
the
exist API will result in architectural changes.

I do worry about what we expect to accomplish here if we have a tight
schedule and also include the idea of "general purpose virt host
manager".  Maybe your opening was too wide for the specific purpose
you
were intending (your numbered list).

If you're strictly focused on something around Fedora18 timeline
wise, I
would agree that there isn't much runway to make big changes.

With that in mind, I'd say we need to add a topic to your list:

5. API versioning and deprecation
This is part of the supportability discussion. Please join in if you have 
something to add. The supportability email was sent to the list as well.

Now, VDSM version was highly bound with oVirt Engine version. In order to make oVirt to work, both VDSM and ovirt engine should be synced with the latest binary, no back compatibility yet. If we want to break this binding out, we should classify the level of the VDSM APIs like these:

1) public stable
2) public evolving
3) undocumented volatile

And the we should make sure public stable interface should be supported in a very long time as possible as we can. public evolving interfaces should keep the compatibility in the same major release(ie, 4.x.x). undocumented volatile is not recommended to the application and it is the responsibility of the application to take the risk.

I believe you've got a number of questions in this space on your
other
thread so I'll move over there.  This is going to be a critical
dicussion on how we move forward.

Seeing as this is a pretty good list of things that need to be
done\discussed in VDSM anyway. I took the liberty of putting them
in a
wiki page [1] so we don't forget and others can add\comment on the
ideas.
Thanks.

In any case you can feel free to raise those issues on the list
separately. Specifically, 3rd party plugins might be very topical
with the undergoing gluster integration work.

[1] http://www.ovirt.org/wiki/VDSM_Potential_Features

----- Original Message -----
From: "Ryan Harper" <ry...@us.ibm.com>
To: "Saggi Mizrahi" <smizr...@redhat.com>
Cc: "VDSM Project Development"
<vdsm-devel@lists.fedorahosted.org>, "Anthony Liguori"
<aligu...@redhat.com>
Sent: Monday, June 18, 2012 3:43:42 PM
Subject: Re: [vdsm] [virt-node] VDSM as a general purpose virt
host manager

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

     - 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
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ry...@us.ibm.com


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


--
Shu Ming <shum...@linux.vnet.ibm.com>
IBM China Systems and Technology Laboratory


_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to