Open Stack

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/77d1fce1/attachment.pgp>