[Engine-devel] Proposed next-generation vdsm API

[Ayal Baron]

----- Original Message -----
> * Geert Jansen <gjansen at 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.

+1
The REST-API should be exactly this.
For multi-node environments where things are already complex we can raise the bar of demands, but for single node it has to be simple and straight-forward with very few requirements (i.e. requiring amqp in single-node use case is too complicated).

> 
> --
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh at us.ibm.com
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel
>