> I think that all drivers that are officially supported must be > treated in the same way.
Well, we already have multiple classes of support due to the various states of testing that the drivers have. > If we are going to split out drivers into a separate but still > official repository then we should do so for all drivers. This would > allow Nova core developers to focus on the architectural side rather > than how each individual driver implements the API that is > presented. I really don't want to see KVM and XenAPI pulled out of the main tree, FWIW. I think we need a critical mass of the (currently) most used drivers there to be the reference platform. Going the route of kicking everything out of tree means the virt driver API is necessarily needs to be a stable thing that the others can depend on and I definitely don't want to see that happen at this point. The other thing is, this is driven mostly by the desire of some driver maintainers to be able to innovate in their driver without the restrictions of being in the main tree. That's not to say that once they reach a level of completeness that they might want back into the main tree as other new drivers continue to be cultivated in the faster-moving "extra drivers" tree. > Perhaps one approach would be to re-use the incubation approach we > have; if drivers want to have the fast-development cycles uncoupled > from core reviewers then they can be moved into an incubation > project. When there is a suitable level of integration (and > automated testing to maintain it of course) then they can graduate. Yeah, I think this makes sense. New drivers from here on out start in the "extra drivers" tree and graduate to the main tree. It sounds like Hyper-V will move back there to achieve a fast pace of development for a while, which I think is fine. It will bring with it some additional review overhead when the time comes to bring it back into the main nova tree, but hopefully we can plan for that and make it happen swiftly. Also, we have a looming deadline of required CI integration for the drivers, so having an "extra drivers" tree gives us a very good landing spot and answer to the question of "what if we can't satisfy the CI requirements?" --Dan _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
