Open Stack

On Dec 9, 2014, at 7:04 AM, Daniel P. Berrange <berrange at redhat.com> wrote:

> On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
>> I have also proposed a blueprint to have a new plugin mechanism in
>> nova to load external vif driver. (nova-specs:
>> https://review.openstack.org/#/c/136827/ and nova (rfc patch):
>> https://review.openstack.org/#/c/136857/)
>> 
>> From my point-of-view of a developer having a plugin framework for
>> internal/external vif driver seems to be a good thing.
>> It makes the code more modular and introduce a clear api for vif driver classes.
>> 
>> So far, it raises legitimate questions concerning API stability and
>> public API that request a wider discussion on the ML (as asking by
>> John Garbut).
>> 
>> I think having a plugin mechanism and a clear api for vif driver is
>> not going against this policy:
>> http://docs.openstack.org/developer/nova/devref/policies.html#out-of-tree-support.
>> 
>> There is no needs to have a stable API. It is up to the owner of the
>> external VIF driver to ensure that its driver is supported by the
>> latest API. And not the nova community to manage a stable API for this
>> external VIF driver. Does it make senses ?
> 
> Experiance has shown that even if it is documented as unsupported, once
> the extension point exists, vendors & users will ignore the small print
> about support status. There will be complaints raised every time it gets
> broken until we end up being forced to maintain it as stable API whether
> we want to or not. That's not a route we want to go down.

Is the support contract for a given API have to be binary - ‘supported’ vs ‘unsupported’?  The stability requirements for REST API’s that end users and all kinds of tooling consume are arguably different from those of an internal API, and recognizing this difference could be useful.


> 
>> Considering the network V2 API, L2/ML2 mechanism driver and VIF driver
>> need to exchange information such as: binding:vif_type and
>> binding:vif_details.
>> 
>> From my understanding, 'binding:vif_type' and 'binding:vif_details' as
>> a field part of the public network api. There is no validation
>> constraints for these fields (see
>> http://docs.openstack.org/api/openstack-network/2.0/content/binding_ext_ports.html),
>> it means that any value is accepted by the API. So, the values set in
>> 'binding:vif_type' and 'binding:vif_details' are not part of the
>> public API. Is my understanding correct ?
> 
> The VIF parameters are mapped into the nova.network.model.VIF class
> which is doing some crude validation. I would anticipate that this
> validation will be increasing over time, because any functional data
> flowing over the API and so needs to be carefully managed for upgrade
> reasons.
> 
> Even if the Neutron impl is out of tree, I would still expect both
> Nova and Neutron core to sign off on any new VIF type name and its
> associated details (if any).
> 
>> What other reasons am I missing to not have VIF driver classes as a
>> public extension point ?
> 
> Having to find & install VIF driver classes from countless different
> vendors, each hiding their code away in their own obsecure website,
> will lead to awful end user experiance when deploying Nova. Users are
> better served by having it all provided when they deploy Nova IMHO

Shipping drivers in-tree makes sense for a purely open source solution for the reasons you mention.  The logic doesn’t necessarily extend to deployment of a proprietary solution, though.  If a given OpenStack deployment is intended to integrate with such a solution, it is likely that the distro/operator/deployer will have a direct relationship with the solution provider and the required software (including VIF driver(s), if necessary) is likely to have a well-defined distribution channel.


> 
> If every vendor goes off & works in their own isolated world we also
> loose the scope to align the implementations, so that common concepts
> work the same way in all cases and allow us to minimize the number of
> new VIF types required. The proposed vhostuser VIF type is a good
> example of this - it allows a single Nova VIF driver to be capable of
> potentially supporting multiple different impls on the Neutron side.
> If every vendor worked in their own world, we would have ended up with
> multiple VIF drivers doing the same thing in Nova, each with their own
> set of bugs & quirks.

I’m not sure the suggestion is that every vendor go off and do their own thing.  Rather, the option for out-of-tree drivers could be made available to those that are pursuing initiatives that aren’t found to be in-keeping with Nova’s current priorities.  I believe that allowing out-of-tree extensions is essential to ensuring the long-term viability of OpenStack.  There is only so much experimental work that is going to be acceptable in core OpenStack projects, if only to ensure stability.  Yes, there is the potential for duplicative effort with results of varying quality, but that’s the price of competitive innovation whether in the field of ideas or open source software, and it’s arguably a price worth paying.  There is always the option of pulling a winning option into the tree and stabilizing it, after all.

> 
> I expect the quality of the code the operator receives will be lower
> if it is never reviewed by anyone except the vendor who writes it in
> the first place.

Code review by itself can’t guarantee quality, especially where the code in question cannot be executed without proprietary software or hardware.  The Neutron tree includes an awful lot of vendor code that non-vendor contributors cannot provide effective oversight for.  We rely on Tempest scenario testing and 3rd party CI to vet the quality of such efforts, so whether it lives in or out of the tree doesn’t really matter from a quality perspective.  I’m not sure why this would be different for Nova.


Maru