Revision as of 23:30, 17 February 2013

Move Provider Networks APIs into Quantum core

Scope

The goal of this blueprint is to make the provider networks API extension part of the official 'core' Quantum API, as agreed durin the Grizzly summit.

From the user perspective, there will be little to no changes (see 'API' section). Plugin implementors should be aware of the changes in the DB model discussed in the 'Data Model Changes' section.

Adapting the code of all existing plugins to data model changes or other refactoring activities is definitely within the scope of this blueprint.

Use Cases

This blueprint does not introduce any new use case.

Implementation Overview

For many aspects, this blueprint is pretty much about code refactoring; apart from refactoring, the most important changes, pertain to the API and the data model.

At the API layer, we are planning to:

• Remove the provider prefix from provider network attributes (all of them currently extend the network resource); this is consistent with the fact that the 'provider' extension alias is being removed as the code is now in the core API.
• Plan whether bump API to 2.1 or not (see Open Questions for more info)

 This would require us to maintain both 2.0 and 2.1 APIs, as well as doing the appropriate changes into the API layer for handling multiple versions.
 2.0 API would be the 'Folsom' API, whereas version 2.1 would be the 'Grizzly' API. 2.1 will not break backward compatibility.

At the DB layer, this blueprint proposes to move data model classes for support provider extension into the 'base' model classes (ie: those defined in quantum.db package). Model classes for provider networks, as well as db logic, are now provided as part of the plugin implementation. As a positive side effect, this will allow us to shrink the code base by removing some boilerplate code repeated across all plugins.

Refactoring activities

• Move provider networks extension's extended attributes, exceptions, and validators into the quantum/api/v2 package
• Remove the extension and adjust all plugins accordingly (removing 'provider' from supported_extension_aliases)
• Refactor db and plugin classes so that L2 methods which required explicit awareness of the provider networks extension can now be made simpler.
• Merging 'ad-hoc' auth checks for provider extension into the main policy engine
• Adjusting db logic according to proposed data model changes

Data Model Changes

The following class will be removed from plugin data models and added to the base model classes: The code below is from the OVS plugin. The tablename attribute will be removed as no more necessary

class NetworkBinding(model_base.BASEV2):
    """Represents binding of virtual network to physical realization"""
    __tablename__ = 'ovs_network_bindings'

    network_id = Column(String(36),
                        ForeignKey('networks.id', ondelete="CASCADE"),
                        primary_key=True)
    network_type = Column(String(32), nullable=False)
    physical_network = Column(String(64))
    segmentation_id = Column(Integer)  # tunnel_id or vlan_id

It is still to be decided whether, from an implementation perspective it is better to have provider network attributes as attributes of the Network model or as a distinct model as depicted above.

Also, migration scripts for each plugin will be provided. Such migration scripts will basically remove the plugin specific model class, and then either create a new, generic model class, or add the attributes to the Network resource. The migration script must also take care of migrating existing data.

Configuration variables

No changes within the scope of this blueprint.

API

The 'provider' prefix should be removed, as this alias won't exist anymore. As this will generate an incompatible change for Folsom users, use of the attribute prefixed with 'provider' should still be allowed through an aliasing mechanism/

Use of the prefix should be deprecated in the Grizzly API reference.

Test Cases

As this blueprint is not going to significantly change functionalities offered by the Quantum service, we do not anticipate new test cases or test modules. However, for routines and methods which should be added during the implementation, appropriate unit tests will be provided.

Open Questions

Should this change bump the API version to 2.1, or shall we keep using 2.0? Bumping to 2.1 will allow us to keep using 'provider' prefix when requests are sent to /v2.0/networks and either prefixed or non-prefixed attribues when requests are sent to /v2.1, as discussed in the API changes section.

On the other hand it will add the burden of maintaining both 2.0 and 2.1 releases of the Quantum API. As we currently we do not have a plan for phasing out old, backward compatible releases, and adding new ones, this might constitute a problem in the long run. Community feedback is solicited in order to reach a consensus here. Should the community be unable to reach a consensus, API version should stay to 2.0