Need to follow the new PTI for document build
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
Akihiro Motoki
parent
28f2a4357b
commit
c95726bbf0
|
|
@ -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
|
||||
|
|
@ -35,10 +35,15 @@ extensions = ['sphinx.ext.autodoc',
|
|||
'sphinxcontrib.actdiag',
|
||||
'sphinxcontrib.seqdiag',
|
||||
'sphinxcontrib.nwdiag',
|
||||
'oslosphinx',
|
||||
'yasfb',
|
||||
'openstackdocstheme'
|
||||
]
|
||||
|
||||
# config for openstackdocstheme
|
||||
repository_name = 'openstack/neutron-specs'
|
||||
bug_project = 'neutron'
|
||||
bug_tag = ''
|
||||
|
||||
# Feed configuration for yasfb
|
||||
feed_base_url = 'http://specs.openstack.org/openstack/neutron-specs'
|
||||
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
|
||||
# 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
|
||||
# further. For a list of options available for each theme, see the
|
||||
|
|
|
|||
|
|
@ -2,17 +2,6 @@
|
|||
# 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.
|
||||
actdiag
|
||||
blockdiag
|
||||
nwdiag
|
||||
oslosphinx>=4.7.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
|
||||
testtools>=1.4.0 # MIT
|
||||
yasfb>=0.5.1
|
||||
|
|
|
|||
|
|
@ -17,8 +17,5 @@ build-dir = doc/build
|
|||
source-dir = doc/source
|
||||
warning-is-error = 1
|
||||
|
||||
[pbr]
|
||||
warnerrors = True
|
||||
|
||||
[wheel]
|
||||
universal = 1
|
||||
|
|
|
|||
|
|
@ -18,25 +18,26 @@ Different Neutron projects, services, features and related projects have
|
|||
different traffic classifiers or classification APIs.
|
||||
They differ on both syntax and semantics. A few examples are:
|
||||
|
||||
- Security group rules [6]
|
||||
- openstack/neutron-fwaas [7]
|
||||
- openstack/networking-sfc (Flow Classifier) [8]
|
||||
- openstack/neutron-classifier [2]
|
||||
- openstack/networking-bgpvpn [12]
|
||||
- openstack/tap-as-a-service [13]
|
||||
- Neutron QoS [10]
|
||||
- Security group rules [6]_
|
||||
- openstack/neutron-fwaas [7]_
|
||||
- openstack/networking-sfc (Flow Classifier) [8]_
|
||||
- openstack/neutron-classifier [2]_
|
||||
- openstack/networking-bgpvpn [12]_
|
||||
- openstack/tap-as-a-service [13]_
|
||||
- Neutron QoS [10]_
|
||||
|
||||
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
|
||||
and fragmenting the language used in the OpenStack ecosystem when it comes
|
||||
to defining traffic classifications.
|
||||
|
||||
This spec introduces the Neutron Common Classification Framework (CCF),
|
||||
a culmination of previous efforts: Common Classifier [0],
|
||||
openstack/neutron-classifier [2] and Common Flow Classifier [11].
|
||||
a culmination of previous efforts: Common Classifier [1]_,
|
||||
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
|
||||
|
|
@ -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
|
||||
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.
|
||||
|
||||
|
||||
|
|
@ -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,
|
||||
thanks to versioning. Thus, this approach follows a modular, rather than
|
||||
a monolithic way of defining classifications. Looking at the existing
|
||||
neutron-classifier project [2], which was decided as the repo to keep the
|
||||
Common Classifier [3] (during the Tokyo Summit 2015), there are hints of an
|
||||
architecture like the one proposed here, as can be seen in [4]. As such, this
|
||||
framework is partially based on the neutron-classifier with the major
|
||||
difference that it presents a REST API for Users to define classifications.
|
||||
neutron-classifier project [2]_, which was decided as the repo to keep
|
||||
the Common Classifier [3]_ (during the Tokyo Summit 2015), there are
|
||||
hints of an architecture like the one proposed here, as can be seen
|
||||
in [4]_. As such, this framework is partially based on the
|
||||
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
|
||||
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,
|
||||
not created or deleted. They need to have been previously
|
||||
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:
|
||||
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
|
||||
==============
|
||||
|
||||
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
|
||||
continue towards the goals outlined in this spec.
|
||||
|
||||
|
|
@ -621,8 +623,7 @@ Work Items
|
|||
References
|
||||
==========
|
||||
|
||||
.. [0] Add common classifier resource (neutron-specs): https://review.openstack.org/#/c/190463/
|
||||
.. [1] Data Model: http://i.imgur.com/MPuOAvv.png
|
||||
.. [1] Add common classifier resource (neutron-specs): https://review.openstack.org/#/c/190463/
|
||||
.. [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
|
||||
.. [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
|
||||
.. [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/
|
||||
|
||||
Related Information
|
||||
-------------------
|
||||
|
||||
- Data Model:
|
||||
http://i.imgur.com/MPuOAvv.png
|
||||
|
|
|
|||
|
|
@ -350,4 +350,8 @@ References
|
|||
.. [3] https://github.com/openstack/python-don
|
||||
.. [4] https://github.com/openstack/vmware-nsx/blob/master/vmware_nsx/shell/admin/README.rst
|
||||
.. [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
|
||||
|
|
|
|||
|
|
@ -355,9 +355,9 @@ References
|
|||
|
||||
.. [2] `Linux HTB Queuing <http://www.linuxjournal.com/article/7562>`_
|
||||
|
||||
.. [3] `[WIP] Floating IP rate limit <https://review.openstack.org/#/c/424466/>`_
|
||||
|
||||
.. [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/>`_
|
||||
Related Information
|
||||
-------------------
|
||||
|
||||
- `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/>`_
|
||||
|
|
|
|||
|
|
@ -209,6 +209,10 @@ API semantic changes need to be documented.
|
|||
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_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/>`_
|
||||
|
|
|
|||
|
|
@ -350,13 +350,6 @@ References
|
|||
.. [port_security_extension_db] port security extension db part
|
||||
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]
|
||||
Describes design of router service plugin for Cisco devices
|
||||
https://review.openstack.org/#/c/91071/
|
||||
|
|
@ -364,43 +357,50 @@ References
|
|||
.. [vyatta_l3_plugin] Design Spec For Brocade Vyatta L3 Plugin
|
||||
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
|
||||
https://blueprints.launchpad.net/neutron/+spec/port-security-api-base-class
|
||||
|
||||
.. [quantum_port_security] Quantum Port Security
|
||||
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]
|
||||
Neutron firewall anti-spoofing does not prevent ARP poisoning
|
||||
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
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ Problem Description
|
|||
SLAAC vs. DHCPv6 stateful/stateless address mode when the subnet is
|
||||
created by setting the "ipv6_ra_mode" and "ipv6_address_mode" attributes
|
||||
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"
|
||||
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)
|
||||
<https://datatracker.ietf.org/doc/rfc4861>`_
|
||||
|
||||
.. [Ref-4] DevStack Blueprint: `Add IPv6 support
|
||||
<https://blueprints.launchpad.net/devstack/+spec/ipv6-support>`_
|
||||
|
||||
.. [Ref-5] Neutron Blueprint: `Two Attributes Proposal to Control IPv6 RA
|
||||
.. [Ref-4] Neutron Blueprint: `Two Attributes Proposal to Control IPv6 RA
|
||||
Announcement and Address Assignment
|
||||
<https://blueprints.launchpad.net/neutron/+spec/ipv6-two-attributes>`_
|
||||
|
||||
.. [Ref-6] Neutron Blueprint: `Provider Networking - upstream SLAAC support
|
||||
<https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac>`_
|
||||
|
||||
.. [Ref-7] `OpenStack Neutron IPv6 Address Mode Attributes Table
|
||||
.. [Ref-5] `OpenStack Neutron IPv6 Address Mode Attributes Table
|
||||
<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>`_
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ pool of routable prefixes.
|
|||
|
||||
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
|
||||
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
|
||||
separate blueprint.
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ Workflow
|
|||
* Initial Setup
|
||||
|
||||
* 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
|
||||
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
|
||||
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
|
||||
(because of the configuration described in the Initial Setup section),
|
||||
allocation for the default IPv6 allocation pool needs to be done
|
||||
|
|
@ -227,7 +227,7 @@ Data Model 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
|
||||
prefix and subnet pool ID. Normally, this indicates to Neutron (and the
|
||||
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
|
||||
[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
|
||||
underlying implementation for the IPv6 portion of the IPAM Subnet
|
||||
Allocation.
|
||||
|
|
@ -357,7 +357,7 @@ Dependencies
|
|||
|
||||
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
|
||||
Subnet Allocation [4]_.
|
||||
Subnet Allocation [3]_.
|
||||
|
||||
|
||||
Testing
|
||||
|
|
@ -431,18 +431,15 @@ References
|
|||
Protocol (DHCP) version 6
|
||||
<http://tools.ietf.org/html/rfc3633>`_
|
||||
|
||||
.. [3] RFC 4862: `IPv6 Stateless Address Autoconfiguration
|
||||
<http://tools.ietf.org/html/rfc4862>`_
|
||||
|
||||
.. [4] Neutron Blueprint: `Add support for subnet allocation
|
||||
.. [3] Neutron Blueprint: `Add support for subnet allocation
|
||||
<https://blueprints.launchpad.net/neutron/+spec/subnet-allocation>`_
|
||||
|
||||
.. [5] RFC 4862: `IPv6 Stateless Address Autoconfiguration
|
||||
<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>`_
|
||||
Related Information
|
||||
-------------------
|
||||
|
||||
- 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>`_
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ Problem Description
|
|||
===================
|
||||
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...),
|
||||
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.
|
||||
|
||||
|
||||
|
|
@ -167,7 +167,7 @@ None
|
|||
Developer Documentation
|
||||
-----------------------
|
||||
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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -645,21 +645,15 @@ Usage of autogenerate along with expand/contract workflow can be documented.
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#] Alembic's Branching Model
|
||||
http://alembic.readthedocs.org/en/latest/branches.html
|
||||
|
||||
.. [#] Online Schema Migrations in Nova
|
||||
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
|
||||
https://bitbucket.org/zzzeek/alembic/issue/302/operations-as-objects
|
||||
|
||||
.. [#] 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
|
||||
- Alembic's Branching Model
|
||||
http://alembic.readthedocs.org/en/latest/branches.html
|
||||
- Online Schema Migrations in Nova
|
||||
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
|
||||
https://bitbucket.org/zzzeek/alembic/issue/302/operations-as-objects
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -483,7 +483,7 @@ Alternatives
|
|||
segmentation packets to prioritize traffic at L2/L3 level.
|
||||
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
|
||||
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
|
||||
|
|
@ -576,7 +576,11 @@ Developer Documentation
|
|||
References
|
||||
==========
|
||||
.. [1] ML2/OVS spec: https://review.openstack.org/#/c/182349/
|
||||
.. [2] https://review.openstack.org/#/c/132661/
|
||||
.. [3] https://lwn.net/Articles/640101/
|
||||
.. [4] http://specs.openstack.org/openstack/neutron-specs/specs/liberty/neutron-flavor-framework-templates.html
|
||||
.. [5] https://wiki.openstack.org/wiki/InstanceResourceQuota#Bandwidth_limits
|
||||
.. [2] https://wiki.openstack.org/wiki/InstanceResourceQuota#Bandwidth_limits
|
||||
|
||||
Related Information
|
||||
-------------------
|
||||
|
||||
- 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
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ Problem Description
|
|||
===================
|
||||
|
||||
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
|
||||
|
|
@ -39,7 +39,7 @@ tenant's network).
|
|||
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:
|
||||
|
||||
|
|
@ -223,7 +223,7 @@ Documentation Impact
|
|||
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
|
||||
|
|
|
|||
|
|
@ -255,6 +255,9 @@ Existing `QoS API documentation
|
|||
References
|
||||
==========
|
||||
|
||||
.. [#qos_api_spec] https://review.openstack.org/#/c/88599/
|
||||
.. [#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/
|
||||
- `QoS API spec
|
||||
<https://review.openstack.org/#/c/88599/>`_
|
||||
- `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/>`_
|
||||
|
|
|
|||
|
|
@ -232,12 +232,14 @@ None
|
|||
References
|
||||
==========
|
||||
|
||||
.. [nfv-unaddressed-interface] NFV unaddressed interfaces
|
||||
https://review.openstack.org/#/c/97715/
|
||||
|
||||
.. [nova-l2-net-without-subnet]
|
||||
Creating Neutron L2 networks (without subnets) doesn't work as expected
|
||||
https://bugs.launchpad.net/nova/+bug/1039665
|
||||
|
||||
.. Make libvirt use the new network model datastructures
|
||||
https://review.openstack.org/#/c/11923/
|
||||
Related Information
|
||||
-------------------
|
||||
|
||||
- Make libvirt use the new network model datastructures
|
||||
https://review.openstack.org/#/c/11923/
|
||||
- NFV unaddressed interfaces
|
||||
https://review.openstack.org/#/c/97715/
|
||||
|
|
|
|||
|
|
@ -20,14 +20,14 @@ that end.
|
|||
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.
|
||||
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
|
||||
enable port status changes to be received and managed by mechanism drivers.
|
||||
|
||||
This spec provides the plumbing to address bug #1575146 [2_] in subsequent
|
||||
work. Specifically, and argued by the Neutron driver team in [3_]:
|
||||
This spec provides the plumbing to address bug #1575146 [2]_ in subsequent
|
||||
work. Specifically, and argued by the Neutron driver team in [3]_:
|
||||
|
||||
* Neutron should not shut down the port completely upon detection of underlay
|
||||
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.
|
||||
|
||||
|
||||
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
|
||||
===============
|
||||
|
||||
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.
|
||||
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
|
||||
|
|
@ -184,11 +184,13 @@ References
|
|||
.. [3] Neutron Drivers meeting, July 21, 2016
|
||||
http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-07-21-22.00.html
|
||||
|
||||
.. [4] Neutron v2 API
|
||||
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
|
||||
.. [4] Demo: OpenStack and OPNFV - Keeping Your Mobile Phone Calls Connected
|
||||
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
13
tox.ini
|
|
@ -7,11 +7,20 @@ skipsdist = True
|
|||
usedevelop = True
|
||||
setenv = VIRTUAL_ENV={envdir}
|
||||
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}'
|
||||
|
||||
[testenv:venv]
|
||||
commands = {posargs}
|
||||
|
||||
[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
|
||||
|
|
|
|||
Loading…
Reference in New Issue