> 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev