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