Open Stack

> My only request here is that we can make sure that new driver
> features can land for other drivers without necessarilky having them
> implemented for libvirt/KVM first.

We've got lots of things supported by the XenAPI drivers that aren't
supported by libvirt, so I don't think this is a problem even today.

> I personally don't agree with this option, as it would create a "A"
> class version of the driver supposely mature and a "B" version
> supposely experimental which would just confuse users.

If you're expecting that there would be two copies of the driver, one in
the main tree and one in the "extra drivers" tree, that's not what I was
suggesting.

> The best option for us, is to have a separate project
> (nova-driver-hyperv would be perfect) where we can handle blueprints,
> commit bug fixes independently with no intention to merge it back
> into the Nova tree as much as I guess there's no reason to merge,
> say, python-nova-client.

So if that's really the desire, why not go John's route and just push
your official version of the driver to a github repo and be done with it?

--Dan