Open Stack

> While it's true that there won't be an in-tree driver that supports
> the API for this release cycle, we have a commercial driver that
> supports it ( https://github.com/gridcentric/cobalt).

IMHO, out of tree virt drivers are completely out of scope here. We
change the virt driver API at will, adding, removing, and changing
things without any concern for what it may do to anything outside of
our tree. Until we commit to a stable virt driver API, the above
argument holds no weight for me.
 
> Having the API standardized in Havana would ensure that client
> support is immediately available for our users as well as for the
> other hypervisor vendors should they release a supporting driver in
> the next 9 months. I believe there is precedent for publishing a nova
> API for those purposes.

Having an API codified (and committed-to) before we have a working
implementation that uses it in Nova is asking for trouble, IMHO.

Personally, I think the hardest bit is already in the tree, which is
the piece that allows the API to communicate with a fictional
live-snapshot-supporting virt driver. Backporting the API and writing a
virt driver to the interface that is there is cake compared to what it
would take to bolt on the plumbing part.

IIRC, the plumbing was speculatively merged ahead of the libvirt and
API pieces, but perhaps the safest (and least confusing) thing for us
to do would be to yank it out prior to Havana?

--Dan