openstack/neutron-specs
Code Issues Proposed changes

Need to follow the new PTI for document build

Browse Source 
For compliance with the Project Testing Interface as described in:
https://governance.openstack.org/tc/reference/project-testing-interface.html

For more detials information, please refer to:
http://lists.openstack.org/pipermail/openstack-dev/2017-December/125710.html

To handle this, this commit changes:

- Introduce doc/requirements.txt
- Update tox.ini [docs] target for developer convenience
- Fixes a lot of warnings caused by a newer sphinx 1.6.5 because
  sphinx specified in upper-constraints.txt is used in the new PTI.
- Drop unnecessary [pbrp] warnerrors in favor of warning-is-error.

Change-Id: If40305044c9dfe0024b64bd3921232bb0a6c9372
This commit is contained in:
ZhaoBo 2017-12-19 19:06:18 +08:00 committed by Akihiro Motoki
parent 28f2a4357b
commit c95726bbf0
19 changed files with 193 additions and 160 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/requirements.txt Normal file
View File

@ -0,0 +1,15 @@
# NOTE(armax): requirements to the specs repo is kept out of sync
# with g-r on purpose, as g-r is just for projects affecting the
# integrated gate. Any sync must happen manually as recommended by
# the openstack release team.
sphinx>=1.6.2 # BSD
actdiag
blockdiag
nwdiag
openstackdocstheme>=1.17.0 # Apache-2.0
seqdiag
sphinxcontrib-actdiag
sphinxcontrib-blockdiag # BSD
sphinxcontrib-nwdiag
sphinxcontrib-seqdiag # BSD
yasfb>=0.5.1

9
doc/source/conf.py
View File

@ -35,10 +35,15 @@ extensions = ['sphinx.ext.autodoc',
'sphinxcontrib.actdiag', 'sphinxcontrib.actdiag',
'sphinxcontrib.seqdiag', 'sphinxcontrib.seqdiag',
'sphinxcontrib.nwdiag', 'sphinxcontrib.nwdiag',
'oslosphinx',
'yasfb', 'yasfb',
'openstackdocstheme'
] ]
# config for openstackdocstheme
repository_name = 'openstack/neutron-specs'
bug_project = 'neutron'
bug_tag = ''
# Feed configuration for yasfb # Feed configuration for yasfb
feed_base_url = 'http://specs.openstack.org/openstack/neutron-specs' feed_base_url = 'http://specs.openstack.org/openstack/neutron-specs'
feed_author = 'OpenStack Neutron Team' feed_author = 'OpenStack Neutron Team'
@ -105,7 +110,7 @@ modindex_common_prefix = ['neutron-specs.']
# The theme to use for HTML and HTML Help pages. See the documentation for # The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes. # a list of builtin themes.
html_theme = 'nature' html_theme = 'openstackdocs'
# Theme options are theme-specific and customize the look and feel of a theme # Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the # further. For a list of options available for each theme, see the

11
requirements.txt
View File

@ -2,17 +2,6 @@
# with g-r on purpose, as g-r is just for projects affecting the # with g-r on purpose, as g-r is just for projects affecting the
# integrated gate. Any sync must happen manually as recommended by # integrated gate. Any sync must happen manually as recommended by
# the openstack release team. # the openstack release team.
actdiag
blockdiag
nwdiag
oslosphinx>=4.7.0 # Apache-2.0
pbr>=2.0.0,!=2.1.0 # Apache-2.0 pbr>=2.0.0,!=2.1.0 # Apache-2.0
seqdiag
sphinx>=1.5.1,<1.6.1 # BSD
sphinxcontrib-actdiag
sphinxcontrib-blockdiag # BSD
sphinxcontrib-nwdiag
sphinxcontrib-seqdiag # BSD
testrepository>=0.0.18 # Apache-2.0/BSD testrepository>=0.0.18 # Apache-2.0/BSD
testtools>=1.4.0 # MIT testtools>=1.4.0 # MIT
yasfb>=0.5.1

3
setup.cfg
View File

@ -17,8 +17,5 @@ build-dir = doc/build
source-dir = doc/source source-dir = doc/source
warning-is-error = 1 warning-is-error = 1
[pbr]
warnerrors = True
[wheel] [wheel]
universal = 1 universal = 1

49
specs/backlog/pike/common-classification-framework.rst
View File

@ -18,25 +18,26 @@ Different Neutron projects, services, features and related projects have
different traffic classifiers or classification APIs. different traffic classifiers or classification APIs.
They differ on both syntax and semantics. A few examples are: They differ on both syntax and semantics. A few examples are:
- Security group rules [6] - Security group rules [6]_
- openstack/neutron-fwaas [7] - openstack/neutron-fwaas [7]_
- openstack/networking-sfc (Flow Classifier) [8] - openstack/networking-sfc (Flow Classifier) [8]_
- openstack/neutron-classifier [2] - openstack/neutron-classifier [2]_
- openstack/networking-bgpvpn [12] - openstack/networking-bgpvpn [12]_
- openstack/tap-as-a-service [13] - openstack/tap-as-a-service [13]_
- Neutron QoS [10] - Neutron QoS [10]_
Furthermore, there are other projects with classification APIs, such as Furthermore, there are other projects with classification APIs, such as
openstack/group-based-policy [9] and it's possible that more will want openstack/group-based-policy [9]_ and it's possible that more will want
to support classifications in their own APIs, further reinventing the wheel to support classifications in their own APIs, further reinventing the wheel
and fragmenting the language used in the OpenStack ecosystem when it comes and fragmenting the language used in the OpenStack ecosystem when it comes
to defining traffic classifications. to defining traffic classifications.
This spec introduces the Neutron Common Classification Framework (CCF), This spec introduces the Neutron Common Classification Framework (CCF),
a culmination of previous efforts: Common Classifier [0], a culmination of previous efforts: Common Classifier [1]_,
openstack/neutron-classifier [2] and Common Flow Classifier [11]. openstack/neutron-classifier [2]_ and
Common Flow Classifier [11]_.
The previous spec for this RFE is archived at [0]. The previous spec for this RFE is archived at [1]_.
Proposed Change Proposed Change
@ -122,7 +123,7 @@ Though out of scope, this is a summary of changes needed in Consuming Services:
must be made consistently with the changes made to their own APIs and/or must be made consistently with the changes made to their own APIs and/or
classification-fetching code. classification-fetching code.
The diagram at [5] shows the relationship between Users, the Common The diagram at [5]_ shows the relationship between Users, the Common
Common Classification Framework and the Consuming Services. Common Classification Framework and the Consuming Services.
@ -134,11 +135,12 @@ Types, will allow future types to be added and agreed in the future, while
keeping the remaining ones intact. Existing types can of course be updated, keeping the remaining ones intact. Existing types can of course be updated,
thanks to versioning. Thus, this approach follows a modular, rather than thanks to versioning. Thus, this approach follows a modular, rather than
a monolithic way of defining classifications. Looking at the existing a monolithic way of defining classifications. Looking at the existing
neutron-classifier project [2], which was decided as the repo to keep the neutron-classifier project [2]_, which was decided as the repo to keep
Common Classifier [3] (during the Tokyo Summit 2015), there are hints of an the Common Classifier [3]_ (during the Tokyo Summit 2015), there are
architecture like the one proposed here, as can be seen in [4]. As such, this hints of an architecture like the one proposed here, as can be seen
framework is partially based on the neutron-classifier with the major in [4]_. As such, this framework is partially based on the
difference that it presents a REST API for Users to define classifications. neutron-classifier with the major difference that it presents a REST API for
Users to define classifications.
Before delving into further detail in regards to the data model, API and how Before delving into further detail in regards to the data model, API and how
classifications can be used by interested Neutron subprojects, a few points classifications can be used by interested Neutron subprojects, a few points
@ -170,7 +172,7 @@ need to be clarified:
- From the Consuming Service's point of view, Classifications can only be read, - From the Consuming Service's point of view, Classifications can only be read,
not created or deleted. They need to have been previously not created or deleted. They need to have been previously
created using the User-facing Classifications API. created using the User-facing Classifications API.
Figure [5] attempts to illustrate this. Figure [5]_ attempts to illustrate this.
The initial model of the CCF will includes the following Classification Types: The initial model of the CCF will includes the following Classification Types:
Ethernet, IPv4, IPv6, TCP and UDP, which when combined are sufficient Ethernet, IPv4, IPv6, TCP and UDP, which when combined are sufficient
@ -590,7 +592,7 @@ Possible alternatives to the data model and REST API presented are:
Implementation Implementation
============== ==============
Work has started as an initial Proof of Concept, available at [14]. Work has started as an initial Proof of Concept, available at [14]_.
After an initial merge on the neutron-classifier repository, work will After an initial merge on the neutron-classifier repository, work will
continue towards the goals outlined in this spec. continue towards the goals outlined in this spec.
@ -621,8 +623,7 @@ Work Items
References References
========== ==========
.. [0] Add common classifier resource (neutron-specs): https://review.openstack.org/#/c/190463/ .. [1] Add common classifier resource (neutron-specs): https://review.openstack.org/#/c/190463/
.. [1] Data Model: http://i.imgur.com/MPuOAvv.png
.. [2] The neutron-classifier project: http://git.openstack.org/cgit/openstack/neutron-classifier .. [2] The neutron-classifier project: http://git.openstack.org/cgit/openstack/neutron-classifier
.. [3] The original and current RFE to bring a common classifier to Neutron: https://bugs.launchpad.net/neutron/+bug/1476527 .. [3] The original and current RFE to bring a common classifier to Neutron: https://bugs.launchpad.net/neutron/+bug/1476527
.. [4] neutron-classifier inspiration: https://github.com/openstack/neutron-classifier/blob/10b2eb3127f4809e52e3cf1627c34228bca80101/neutron_classifier/common/constants.py#L17 .. [4] neutron-classifier inspiration: https://github.com/openstack/neutron-classifier/blob/10b2eb3127f4809e52e3cf1627c34228bca80101/neutron_classifier/common/constants.py#L17
@ -636,3 +637,9 @@ References
.. [12] openstack/networking-bgpvpn API reference: https://docs.openstack.org/developer/networking-bgpvpn/api.html#bgpvpn-resource .. [12] openstack/networking-bgpvpn API reference: https://docs.openstack.org/developer/networking-bgpvpn/api.html#bgpvpn-resource
.. [13] openstack/tap-as-a-service API reference: https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst .. [13] openstack/tap-as-a-service API reference: https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst
.. [14] Latest CCF PoC: https://review.openstack.org/#/c/445577/ .. [14] Latest CCF PoC: https://review.openstack.org/#/c/445577/
Related Information
-------------------
- Data Model:
http://i.imgur.com/MPuOAvv.png

6
specs/backlog/pike/diagnostics.rst
View File

@ -350,4 +350,8 @@ References
.. [3] https://github.com/openstack/python-don .. [3] https://github.com/openstack/python-don
.. [4] https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/shell/admin/README.rst .. [4] https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/shell/admin/README.rst
.. [5] https://wiki.openstack.org/wiki/Nova_VM_Diagnostics .. [5] https://wiki.openstack.org/wiki/Nova_VM_Diagnostics
.. [6] https://bugs.launchpad.net/neutron/+bug/1563538
Related Information
-------------------
- https://bugs.launchpad.net/neutron/+bug/1563538

10
specs/backlog/pike/layer-3-rate-limit.rst
View File

@ -355,9 +355,9 @@ References
.. [2] `Linux HTB Queuing <http://www.linuxjournal.com/article/7562>`_ .. [2] `Linux HTB Queuing <http://www.linuxjournal.com/article/7562>`_
.. [3] `[WIP] Floating IP rate limit <https://review.openstack.org/#/c/424466/>`_ Related Information
-------------------
.. [4] `[WIP] Router gateway rate limit (abandoned) <https://review.openstack.org/#/c/424468/>`_
.. [5] `[WIP] Adding L3 rate limit TC lib <https://review.openstack.org/#/c/453458/>`_
- `Floating IP rate limit <https://review.openstack.org/#/c/424466/>`_
- `Router gateway rate limit (abandoned) <https://review.openstack.org/#/c/424468/>`_
- `Adding L3 rate limit TC lib <https://review.openstack.org/#/c/453458/>`_

6
specs/kilo/ipv6-router.rst
View File

@ -209,6 +209,10 @@ API semantic changes need to be documented.
References References
========== ==========
.. [REFAC_L3] `Kilo refactoring and restructuring the l3 agent <https://review.openstack.org/#/c/131535/>`_
.. [IPV6_ADDR] `IP Version 6 Addressing Architecture <https://tools.ietf.org/html/rfc4291>`_ .. [IPV6_ADDR] `IP Version 6 Addressing Architecture <https://tools.ietf.org/html/rfc4291>`_
.. [IPV6_FIP] `IPv6 Floating IP Support <https://review.openstack.org/#/c/139731/>`_ .. [IPV6_FIP] `IPv6 Floating IP Support <https://review.openstack.org/#/c/139731/>`_
Related Information
-------------------
- `Kilo refactoring and restructuring the l3 agent <https://review.openstack.org/#/c/131535/>`_

76
specs/kilo/ml2-ovs-portsecurity.rst
View File

@ -350,13 +350,6 @@ References
.. [port_security_extension_db] port security extension db part .. [port_security_extension_db] port security extension db part
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/portsecurity_db.py http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/portsecurity_db.py
.. [ml2_extension_driver] Support for extensions in ML2 Mechanism Drivers
* spec review: https://review.openstack.org/#/c/89208/
* etherpad: https://etherpad.openstack.org/p/ML2_MD_extensions
.. [modular_l2_agent] Modular L2 agent
spec review: https://review.openstack.org/#/c/99187/
.. [router_plugin_cisco] .. [router_plugin_cisco]
Describes design of router service plugin for Cisco devices Describes design of router service plugin for Cisco devices
https://review.openstack.org/#/c/91071/ https://review.openstack.org/#/c/91071/
@ -364,43 +357,50 @@ References
.. [vyatta_l3_plugin] Design Spec For Brocade Vyatta L3 Plugin .. [vyatta_l3_plugin] Design Spec For Brocade Vyatta L3 Plugin
https://review.openstack.org/#/c/101052/ https://review.openstack.org/#/c/101052/
.. [dvr] Neturon Distributed Virtual Router for OVS
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
.. [ovs_firewall_driver]
Open vSwitch-based Security Groups: Open vSwitch Implementation of
FirewallDriver
https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver
https://review.openstack.org/#/c/89712/
.. [port_security_base_class] Port Security API base class .. [port_security_base_class] Port Security API base class
https://blueprints.launchpad.net/neutron/+spec/port-security-api-base-class https://blueprints.launchpad.net/neutron/+spec/port-security-api-base-class
.. [quantum_port_security] Quantum Port Security .. [quantum_port_security] Quantum Port Security
https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit?pli=1 https://docs.google.com/document/d/18trYtq3wb0eJK2CapktN415FRIVasr7UkTpWn9mLq5M/edit?pli=1
.. [ml2_extensions] Support for extensions in ML2 Mechanism Drivers
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
.. [port_security_ml2] Add Port Security Implementation in ML2 Plugin
duplicated proposal. consolidated to this one.
* blueprint https://blueprints.launchpad.net/neutron/+spec/port-security-ml2
* spec review https://review.openstack.org/#/c/106222/
.. [nfv_unaddressed_interfaces]
NFV unaddressed interfaces
* blueprint https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces
* spec review https://review.openstack.org/#/c/97715/
.. [port_security_ml2_patch] Add portsecurity extension support
patch for ovs firewall driver
https://review.openstack.org/#/c/126552/
.. [related_bugs]
related bugs: creating network without subnet and port without subnet
* https://bugs.launchpad.net/bugs/1039665
* https://bugs.launchpad.net/bugs/1175464
.. [bug1274034] .. [bug1274034]
Neutron firewall anti-spoofing does not prevent ARP poisoning Neutron firewall anti-spoofing does not prevent ARP poisoning
https://bugs.launchpad.net/neutron/+bug/1274034 https://bugs.launchpad.net/neutron/+bug/1274034
Related Information
-------------------
- Support for extensions in ML2 Mechanism Drivers
spec review: https://review.openstack.org/#/c/89208/
etherpad: https://etherpad.openstack.org/p/ML2_MD_extensions
- Modular L2 agent
spec review: https://review.openstack.org/#/c/99187/
- Neturon Distributed Virtual Router for OVS
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
- Open vSwitch-based Security Groups: Open vSwitch Implementation of
FirewallDriver
https://blueprints.launchpad.net/neutron/+spec/ovs-firewall-driver
https://review.openstack.org/#/c/89712/
- Support for extensions in ML2 Mechanism Drivers
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
- Add Port Security Implementation in ML2 Plugin
duplicated proposal. consolidated to this one.
blueprint https://blueprints.launchpad.net/neutron/+spec/port-security-ml2
spec review https://review.openstack.org/#/c/106222/
- NFV unaddressed interfaces
blueprint https://blueprints.launchpad.net/neutron/+spec/nfv-unaddressed-interfaces
spec review https://review.openstack.org/#/c/97715/
- Add portsecurity extension support
patch for ovs firewall driver
https://review.openstack.org/#/c/126552/
- related bugs: creating network without subnet and port without subnet
https://bugs.launchpad.net/bugs/1039665
https://bugs.launchpad.net/bugs/1175464

21
specs/kilo/multiple-ipv6-prefixes.rst
View File

@ -71,7 +71,7 @@ Problem Description
SLAAC vs. DHCPv6 stateful/stateless address mode when the subnet is SLAAC vs. DHCPv6 stateful/stateless address mode when the subnet is
created by setting the "ipv6_ra_mode" and "ipv6_address_mode" attributes created by setting the "ipv6_ra_mode" and "ipv6_address_mode" attributes
in a subnet-create API call. These attributes were added with the in a subnet-create API call. These attributes were added with the
blueprint listed in [Ref-5]_. Attribute values are described in [Ref-7]_. blueprint listed in [Ref-4]_. Attribute values are described in [Ref-5]_.
For the purposes of this design specification, the term "SLAAC-enabled" For the purposes of this design specification, the term "SLAAC-enabled"
subnets will be used to refer to subnets that are configured for either subnets will be used to refer to subnets that are configured for either
@ -455,18 +455,19 @@ References
.. [Ref-3] RFC 4861: `Neighbor Discovery for IP version 6 (IPv6) .. [Ref-3] RFC 4861: `Neighbor Discovery for IP version 6 (IPv6)
<https://datatracker.ietf.org/doc/rfc4861>`_ <https://datatracker.ietf.org/doc/rfc4861>`_
.. [Ref-4] DevStack Blueprint: `Add IPv6 support .. [Ref-4] Neutron Blueprint: `Two Attributes Proposal to Control IPv6 RA
<https://blueprints.launchpad.net/devstack/+spec/ipv6-support>`_
.. [Ref-5] Neutron Blueprint: `Two Attributes Proposal to Control IPv6 RA
Announcement and Address Assignment Announcement and Address Assignment
<https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes>`_ <https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes>`_
.. [Ref-6] Neutron Blueprint: `Provider Networking - upstream SLAAC support .. [Ref-5] `OpenStack Neutron IPv6 Address Mode Attributes Table
<https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac>`_
.. [Ref-7] `OpenStack Neutron IPv6 Address Mode Attributes Table
<https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf>`_ <https://www.dropbox.com/s/9bojvv9vywsz8sd/IPv6%20Two%20Modes%20v3.0.pdf>`_
.. [Ref-8] RFC 4291: `IP Version 6 Addressing Architecture Related Information
-------------------
- DevStack Blueprint: `Add IPv6 support
<https://blueprints.launchpad.net/devstack/+spec/ipv6-support>`_
- Neutron Blueprint: `Provider Networking - upstream SLAAC support
<https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac>`_
- RFC 4291: `IP Version 6 Addressing Architecture
<http://tools.ietf.org/html/rfc4291>`_ <http://tools.ietf.org/html/rfc4291>`_

33
specs/liberty/ipv6-prefix-delegation.rst
View File

@ -37,7 +37,7 @@ pool of routable prefixes.
Note that it would be possible to have a PD server application that is Note that it would be possible to have a PD server application that is
managed by Neutron that is running within a Neutron router namespace, and managed by Neutron that is running within a Neutron router namespace, and
that is configured using the IPAM Subnet Allocation API [4]_. This that is configured using the IPAM Subnet Allocation API [3]_. This
support is out the scope of this blueprint, and will be covered in a support is out the scope of this blueprint, and will be covered in a
separate blueprint. separate blueprint.
@ -146,7 +146,7 @@ Workflow
* Initial Setup * Initial Setup
* Admin configures the default_ipv6_subnet_pool configuration setting * Admin configures the default_ipv6_subnet_pool configuration setting
(described in the IPAM Subnet Allocation specification, [4]_) (described in the IPAM Subnet Allocation specification, [3]_)
in the neutron.conf configuration file to indicate that prefix in the neutron.conf configuration file to indicate that prefix
delegation should be used for the default subnet pool. delegation should be used for the default subnet pool.
@ -154,7 +154,7 @@ Workflow
* User/tenant creates an IPv6 subnet while supplying neither an address * User/tenant creates an IPv6 subnet while supplying neither an address
pool nor a prefix. Normally, this indicates to the subnet pool allocation pool nor a prefix. Normally, this indicates to the subnet pool allocation
infrastructure [4]_ that the prefix should be automatically infrastructure [3]_ that the prefix should be automatically
allocated from the default IPv6 allocation pool. However, in this case allocated from the default IPv6 allocation pool. However, in this case
(because of the configuration described in the Initial Setup section), (because of the configuration described in the Initial Setup section),
allocation for the default IPv6 allocation pool needs to be done allocation for the default IPv6 allocation pool needs to be done
@ -227,7 +227,7 @@ Data Model Impact
REST API Impact REST API Impact
--------------- ---------------
As described in the Subnet Pool Allocation specification [4]_, the As described in the Subnet Pool Allocation specification [3]_, the
subnet create API will need to allow for the absence of both subnet subnet create API will need to allow for the absence of both subnet
prefix and subnet pool ID. Normally, this indicates to Neutron (and the prefix and subnet pool ID. Normally, this indicates to Neutron (and the
subnet pool allocation infrastructure) that the prefix for this subnet subnet pool allocation infrastructure) that the prefix for this subnet
@ -309,7 +309,7 @@ Community Impact
---------------- ----------------
This feature is complementary to the IPAM Subnet Allocation feature This feature is complementary to the IPAM Subnet Allocation feature
[4]_. This implementation could be expanded in the future to support [3]_. This implementation could be expanded in the future to support
an internal (Neutron-managed) PD server, and thereby used as part of the an internal (Neutron-managed) PD server, and thereby used as part of the
underlying implementation for the IPv6 portion of the IPAM Subnet underlying implementation for the IPv6 portion of the IPAM Subnet
Allocation. Allocation.
@ -357,7 +357,7 @@ Dependencies
The change in behavior for the subnet create API described in this proposal The change in behavior for the subnet create API described in this proposal
will need to build off changes in that API that will be made for IPAM will need to build off changes in that API that will be made for IPAM
Subnet Allocation [4]_. Subnet Allocation [3]_.
Testing Testing
@ -431,18 +431,15 @@ References
Protocol (DHCP) version 6 Protocol (DHCP) version 6
<http://tools.ietf.org/html/rfc3633>`_ <http://tools.ietf.org/html/rfc3633>`_
.. [3] RFC 4862: `IPv6 Stateless Address Autoconfiguration .. [3] Neutron Blueprint: `Add support for subnet allocation
<http://tools.ietf.org/html/rfc4862>`_
.. [4] Neutron Blueprint: `Add support for subnet allocation
<https://blueprints.launchpad.net/neutron/+spec/subnet-allocation>`_ <https://blueprints.launchpad.net/neutron/+spec/subnet-allocation>`_
.. [5] RFC 4862: `IPv6 Stateless Address Autoconfiguration Related Information
<http://tools.ietf.org/html/rfc4862>`_ -------------------
.. [6] RFC 4861: `Neighbor Discovery for IP version 6 (IPv6)
<https://datatracker.ietf.org/doc/rfc4861>`_
.. [7] RFC 4291: `IP Version 6 Addressing Architecture
<http://tools.ietf.org/html/rfc4291>`_
- RFC 4862: `IPv6 Stateless Address Autoconfiguration
<http://tools.ietf.org/html/rfc4862>`_
- RFC 4861: `Neighbor Discovery for IP version 6 (IPv6)
<https://datatracker.ietf.org/doc/rfc4861>`_
- RFC 4291: `IP Version 6 Addressing Architecture
<http://tools.ietf.org/html/rfc4291>`_

4
specs/liberty/neutron-python3.rst
View File

@ -15,7 +15,7 @@ Problem Description
=================== ===================
Neutron currently only works with Python 2.x. As some OpenStack projects now Neutron currently only works with Python 2.x. As some OpenStack projects now
work with Python 3 (most of the Python clients, some of the oslo libraries...), work with Python 3 (most of the Python clients, some of the oslo libraries...),
and since OpenStack should move to Python 3 [1], Neutron shall be ported to and since OpenStack should move to Python 3 [1]_, Neutron shall be ported to
Python 3.4. Python 3.4.
@ -167,7 +167,7 @@ None
Developer Documentation Developer Documentation
----------------------- -----------------------
Developers might be interested in reading the official Python 3 page on the Developers might be interested in reading the official Python 3 page on the
Openstack wiki [2]. It shows the current progress and details some common Openstack wiki [2]_. It shows the current progress and details some common
issues that arise when porting code to Python 3. issues that arise when porting code to Python 3.

30
specs/liberty/online-schema-migrations.rst
View File

@ -645,21 +645,15 @@ Usage of autogenerate along with expand/contract workflow can be documented.
References References
========== ==========
.. [#] Alembic's Branching Model - Alembic's Branching Model
http://alembic.readthedocs.org/en/latest/branches.html http://alembic.readthedocs.org/en/latest/branches.html
- Online Schema Migrations in Nova
.. [#] Online Schema Migrations in Nova http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/online-schema-changes.html
http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/online-schema-changes.html - Nova's Overall Online Upgrade approach
http://docs.openstack.org/developer/nova/devref/upgrade.html
- Operations as Objects
.. [#] Nova's Overall Online Upgrade approach https://bitbucket.org/zzzeek/alembic/issue/302/operations-as-objects
http://docs.openstack.org/developer/nova/devref/upgrade.html - Extensible Revision / Autogenerate strategies
https://bitbucket.org/zzzeek/alembic/issue/301/extensible-revision-autogenerate
.. [#] Operations as Objects - Neutron patch to rearrange migration directory into subtrees
https://bitbucket.org/zzzeek/alembic/issue/302/operations-as-objects https://review.openstack.org/194198
.. [#] Extensible Revision / Autogenerate strategies
https://bitbucket.org/zzzeek/alembic/issue/301/extensible-revision-autogenerate
.. [#] Neutron patch to rearrange migration directory into subtrees
https://review.openstack.org/194198

14
specs/liberty/qos-api-extension.rst
View File

@ -483,7 +483,7 @@ Alternatives
segmentation packets to prioritize traffic at L2/L3 level. segmentation packets to prioritize traffic at L2/L3 level.
Also the tenants could not be trusted to do the right thing. Also the tenants could not be trusted to do the right thing.
- Nova flavors support for QoS [5]_ allows bandwidth limiting settings via - Nova flavors support for QoS [2]_ allows bandwidth limiting settings via
the libvirt interface on the VM tap. This is enough for basic BW limiting the libvirt interface on the VM tap. This is enough for basic BW limiting
on the VMs, but other QoS rules are not supported, and this also lacks on the VMs, but other QoS rules are not supported, and this also lacks
support for service port QoS. User may need to stick to one approach or support for service port QoS. User may need to stick to one approach or
@ -576,7 +576,11 @@ Developer Documentation
References References
========== ==========
.. [1] ML2/OVS spec: https://review.openstack.org/#/c/182349/ .. [1] ML2/OVS spec: https://review.openstack.org/#/c/182349/
.. [2] https://review.openstack.org/#/c/132661/ .. [2] https://wiki.openstack.org/wiki/InstanceResourceQuota#Bandwidth_limits
.. [3] https://lwn.net/Articles/640101/
.. [4] http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework-templates.html Related Information
.. [5] https://wiki.openstack.org/wiki/InstanceResourceQuota#Bandwidth_limits -------------------
- https://review.openstack.org/#/c/132661/
- https://lwn.net/Articles/640101/
- http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework-templates.html

6
specs/mitaka/rbac-qos-policies.rst
View File

@ -17,7 +17,7 @@ Problem Description
=================== ===================
Currently, in neutron QoS policies cannot be shared across subsets of tenants. This proposal Currently, in neutron QoS policies cannot be shared across subsets of tenants. This proposal
talks about using RBAC [1] for QoS policies and making them shareable across tenants. talks about using RBAC [1]_ for QoS policies and making them shareable across tenants.
Proposed Change Proposed Change
@ -39,7 +39,7 @@ tenant's network).
Data Model Impact Data Model Impact
----------------- -----------------
Add a model of RBAC for qos policy, Using the existing RBAC for Data model as reference [2]. Add a model of RBAC for qos policy, Using the existing RBAC for Data model as reference [2]_.
QosPolicyRBAC Table structure: QosPolicyRBAC Table structure:
@ -223,7 +223,7 @@ Documentation Impact
User Documentation User Documentation
------------------ ------------------
The workflow for adding RBAC for qos policy entries will need to be added to [3]. The workflow for adding RBAC for qos policy entries will need to be added to [3]_.
References References

9
specs/newton/ml2-qos-with-dscp.rst
View File

@ -255,6 +255,9 @@ Existing `QoS API documentation
References References
========== ==========
.. [#qos_api_spec] https://review.openstack.org/#/c/88599/ - `QoS API spec
.. [#qos_devref] https://github.com/openstack/neutron/blob/master/doc/source/devref/quality_of_service.rst <https://review.openstack.org/#/c/88599/>`_
.. [#qos_api_doc] https://review.openstack.org/#/c/226834/ - `QoS devref
<https://github.com/openstack/neutron/blob/master/doc/source/devref/quality_of_service.rst>`_
- `QoS API doc
<https://review.openstack.org/#/c/226834/>`_

12
specs/newton/unaddressed-port.rst
View File

@ -232,12 +232,14 @@ None
References References
========== ==========
.. [nfv-unaddressed-interface] NFV unaddressed interfaces
https://review.openstack.org/#/c/97715/
.. [nova-l2-net-without-subnet] .. [nova-l2-net-without-subnet]
Creating Neutron L2 networks (without subnets) doesn't work as expected Creating Neutron L2 networks (without subnets) doesn't work as expected
https://bugs.launchpad.net/nova/+bug/1039665 https://bugs.launchpad.net/nova/+bug/1039665
.. Make libvirt use the new network model datastructures Related Information
https://review.openstack.org/#/c/11923/ -------------------
- Make libvirt use the new network model datastructures
https://review.openstack.org/#/c/11923/
- NFV unaddressed interfaces
https://review.openstack.org/#/c/97715/

26
specs/pike/port-data-plane-status.rst
View File

@ -20,14 +20,14 @@ that end.
Problem Description Problem Description
=================== ===================
An initial description of the problem was introduced in bug #159801 [1_]. This An initial description of the problem was introduced in bug #159801 [1]_. This
spec focuses on capturing one (main) part of the problem there described, i.e. spec focuses on capturing one (main) part of the problem there described, i.e.
extending Neutron's REST API to cover the scenario of allowing external tools extending Neutron's REST API to cover the scenario of allowing external tools
to report network failures to Neutron. Out of scope of this spec are works to to report network failures to Neutron. Out of scope of this spec are works to
enable port status changes to be received and managed by mechanism drivers. enable port status changes to be received and managed by mechanism drivers.
This spec provides the plumbing to address bug #1575146 [2_] in subsequent This spec provides the plumbing to address bug #1575146 [2]_ in subsequent
work. Specifically, and argued by the Neutron driver team in [3_]: work. Specifically, and argued by the Neutron driver team in [3]_:
* Neutron should not shut down the port completely upon detection of underlay * Neutron should not shut down the port completely upon detection of underlay
network failure; connectivity between instances on the same node may still network failure; connectivity between instances on the same node may still
@ -98,13 +98,13 @@ One possible workflow is:
switch-over to a standby instance. switch-over to a standby instance.
A similar workflow was presented at the OpenStack Summit Barcelona keynote demo [6_]. A similar workflow was presented at the OpenStack Summit Barcelona keynote demo [4]_.
Proposed Change Proposed Change
=============== ===============
A couple of possible approaches were proposed in [1_] (comment #3). This spec A couple of possible approaches were proposed in [1]_ (comment #3). This spec
proposes tackling the problem via a new extension API to the port resource. proposes tackling the problem via a new extension API to the port resource.
The extension adds a new attribute ``data_plane_status`` to represent the The extension adds a new attribute ``data_plane_status`` to represent the
status of the underlay data plane. This attribute is to be managed by entities outside status of the underlay data plane. This attribute is to be managed by entities outside
@ -184,11 +184,13 @@ References
.. [3] Neutron Drivers meeting, July 21, 2016 .. [3] Neutron Drivers meeting, July 21, 2016
http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-07-21-22.00.html http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-07-21-22.00.html
.. [4] Neutron v2 API .. [4] Demo: OpenStack and OPNFV - Keeping Your Mobile Phone Calls Connected
https://wiki.openstack.org/wiki/Neutron/APIv2-specification
.. [5] Neutron: resource status & admin state up
https://docs.google.com/presentation/d/1-cex849lLsmRsZ302lqkwvXbexhe6cwuCZ2JSE8Rp2s
.. [6] Demo: OpenStack and OPNFV - Keeping Your Mobile Phone Calls Connected
https://www.youtube.com/watch?v=Dvh8q5m9Ahk https://www.youtube.com/watch?v=Dvh8q5m9Ahk
Related Information
-------------------
- Neutron v2 API
https://wiki.openstack.org/wiki/Neutron/APIv2-specification
- Neutron: resource status & admin state up
https://docs.google.com/presentation/d/1-cex849lLsmRsZ302lqkwvXbexhe6cwuCZ2JSE8Rp2s

13
tox.ini
View File

@ -7,11 +7,20 @@ skipsdist = True
usedevelop = True usedevelop = True
setenv = VIRTUAL_ENV={envdir} setenv = VIRTUAL_ENV={envdir}
install_command = pip install -U {opts} {packages} install_command = pip install -U {opts} {packages}
deps = -r{toxinidir}/requirements.txt # Unit test requires docutils and it is recommended to install docutils via
# sphinx. We use doc/requirements.txt as well to avoid duplicated entries.
deps =
-r{toxinidir}/requirements.txt
-r{toxinidir}/doc/requirements.txt
commands = python setup.py testr --slowest --testr-args='{posargs}' commands = python setup.py testr --slowest --testr-args='{posargs}'
[testenv:venv] [testenv:venv]
commands = {posargs} commands = {posargs}
[testenv:docs] [testenv:docs]
commands = python setup.py build_sphinx deps =
-c{env:UPPER_CONSTRAINTS_FILE:https://git.openstack.org/cgit/openstack/requirements/plain/upper-constraints.txt}
-r{toxinidir}/doc/requirements.txt
commands =
/bin/rm -fr doc/build/
sphinx-build -W -b html doc/source doc/build/html