Re: [Engine-devel] Proposed next-generation vdsm API
* Geert Jansen <gjansen(a)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.
--
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh(a)us.ibm.com