> +1 - I think we really want to have a strong preference for a stable > api if we start separating parts out
So, as someone who is about to break the driver API all to hell over the next six months (er, I mean, make some significant changes), I can tell you that making it stable is the best way to kill velocity right now. We are a young project with a lot of work yet to do. Making the driver API stable at this point in the process, especially because just one driver wants to be out of tree, is going to be a huge problem. > Otherwise we either end up with lots of pain in making > infrastructure changes or asymmetric gating which is to be avoided > wherever possible. AFAICT, this is pain that would be experienced by the out-of-tree driver and pain which has been called out specifically by the authors as "better than the alternative". Seriously, putting the brakes on the virt api right now because one driver wants to be out of tree is a huge problem. I fully support the hyper-v taking itself out-of-tree if it wants, but I don't think that means we can or should eject the others and move to a stable virt api. At least not anytime soon. --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
