----- Original Message ----- > * Geert Jansen <gjan...@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 > ry...@us.ibm.com > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel@lists.fedorahosted.org > https://fedorahosted.org/mailman/listinfo/vdsm-devel > _______________________________________________ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/vdsm-devel