* Geert Jansen gjansen@redhat.com [2011-11-30 17:38]:
Hi,
i think this makes sense, but i'm not a VDSM expert. I did want to point out one other point, below:
On 11/30/2011 11:40 PM, Adam Litke wrote:
Recently we've had some very productive discussions concerning the VDSM API. I want to attempt to refocus the discussion around an emerging proposal and see if we can agree on a sensible path forward.
Based on the discussion, I have identified the following requirements that a new API for vdsm should have:
1.) Single API that can be consumed by ovirt-engine and ISVs
- We don't want to maintain multiple parallel APIs
- To develop a vendor ecosystem, we must have a robust external API to vdsm
I have doubts around how useful the VDSM API will be for creating an ecosystem. If you look at most virtualization ISVs today, they want to integrate with a multi-node API and not a single-node API. The only use case that i know where integrating with a single node API is requested is when you're basically creating a virtualization management platform like oVirt itself.
Without a first-class node level API, we're precluding the very case you're aware of. If we're building a community and ecosystem around KVM management then we need to be open to someone building that management platform and doing it in a way that keeps things compatible.
There are existing products (IBM has a number in this space) which utilize libvirt as a node-level API which won't be able to (easily) integrate all of oVirt just to obtain access to the nodes.
Further, if the only way to consume VDSM is via the multi-node solution, then price of entry is a much larger, more complex stack with more dependencies. This raises the barrier of entry and participation. IMHO, not ideal when we're attempting to grow a community.
Alternatively, if we enable a common node API, not only do we support single node deployments (think virtual appliances, or hardware appliances; IBM has a few of these) but allowing competing (but compatible) multi-node/cluster solutions; and it even supports the single node solutions to be managed by different kvm-based management platforms because they're all working with the same node-level API.
Having a first-class node API is a critical starting point for building our larger kvm management community since it allows for easier integration of existing products. I cannot stress that point enough; if we're committed to being an open community then we need design our interfaces to encourage participation. Lowing the cost of participation and integrate is great way to enable an ecosystem.