Open Stack

On Oct 11, 2013, at 18:36 , Dan Smith <dms at danplanet.com>
 wrote:

>> 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.
> 

I see libvirt/KVM treated as the reference driver, so it could make sense to leave it in Nova. 

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. 

> 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.
> 

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.

It's not a matter of stability, as the code is already stable so I really don't see a point in the incubator approach. We already have our forks for experimental features without needing to complicate things more.
The code that we publish in the OpenStack repos is meant to be production ready.

As Dan was pointing out, merging the code back into Nova would require a review at some point in time of a huge patch that would send us straight back into review hell. No thanks!

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. 

Any area that would require additional features in Nova (e.g. our notorious RDP blueprint :-) ) would anyway go through the Nova review process, while blueprints that implement a feature already present in Nova (e.g. live-snapshots) can be handled entirely independently.

This approach would save quite some precious review bandwidths from the Nova reviewers and give us the required headroom to innovate and fix bugs in a timely manner, bringing the best OpenStack experience to our users.


> 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?"
> 

I agree on this point: purgatory -ahem-, I mean, incubation, for the drivers that witll not have a CI ready in time for Icehouse.

Alessandro


> --Dan
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev