* Saggi Mizrahi smizrahi@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 deprication
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" ryanh@us.ibm.com To: "Saggi Mizrahi" smizrahi@redhat.com Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org, "Anthony Liguori" aliguori@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 smizrahi@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:
- Declare API supportability guidelines
- Decide on an API transport (e.g. REST, ZMQ, AMQP)
- 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 ryanh@us.ibm.com