> If we're going to do that, then we should be consistent. eg there is > a volume_drivers parameter that serves the same purpose as > vif_driver
There are lots of them. We've had a bit of a background task running to remove them when possible/convenient and try to avoid adding new ones. I'm not opposed to aggressively removing them for sure, but it wouldn't be super high on my priority list. However, I definitely don't want to slide backwards when we have one already marked for removal :) > What is our story for people who are developing new network or > storage drivers for Neutron / Cinder and wish to test Nova ? Removing > vif_driver and volume_drivers config parameters would mean that they > would have to directly modify the existing Nova libvirt > vif.py/volume.py codefiles. > > This isn't neccessarily bad because they'll have to do this anyway > if they want to actually submit it to Nova. I don't think there's any reason not to do that in nova itself, is there? Virt drivers are large, so maybe making an exception for that plug point makes sense purely for our own test efforts. However, for something smaller like you mention, I don't see why we need to keep them, especially given what it advertises (IMHO) to people. > This could be a pain if they wish to provide the custom driver to > users/customers of the previous stable Nova release while waiting for > official support in next Nova release. It sounds like you're > explicitly saying we don't want to support that use case though. I can't really speak for "we", but certainly _I_ don't want to support that model. I think it leads to people thinking they can develop drivers for things like this out of tree permanently, which I'd really like to avoid. --Dan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
