From c95726bbf03d3bb41e845627baf31bcfecf42d78 Mon Sep 17 00:00:00 2001 From: ZhaoBo Date: Tue, 19 Dec 2017 19:06:18 +0800 Subject: [PATCH] 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 --- doc/requirements.txt | 15 ++++ doc/source/conf.py | 9 ++- requirements.txt | 11 --- setup.cfg | 3 - .../pike/common-classification-framework.rst | 49 +++++++----- specs/backlog/pike/diagnostics.rst | 6 +- specs/backlog/pike/layer-3-rate-limit.rst | 10 +-- specs/kilo/ipv6-router.rst | 6 +- specs/kilo/ml2-ovs-portsecurity.rst | 76 +++++++++---------- specs/kilo/multiple-ipv6-prefixes.rst | 21 ++--- specs/liberty/ipv6-prefix-delegation.rst | 33 ++++---- specs/liberty/neutron-python3.rst | 4 +- specs/liberty/online-schema-migrations.rst | 30 +++----- specs/liberty/qos-api-extension.rst | 14 ++-- specs/mitaka/rbac-qos-policies.rst | 6 +- specs/newton/ml2-qos-with-dscp.rst | 9 ++- specs/newton/unaddressed-port.rst | 12 +-- specs/pike/port-data-plane-status.rst | 26 ++++--- tox.ini | 13 +++- 19 files changed, 193 insertions(+), 160 deletions(-) create mode 100644 doc/requirements.txt diff --git a/doc/requirements.txt b/doc/requirements.txt new file mode 100644 index 000000000..00618b754 --- /dev/null +++ b/doc/requirements.txt @@ -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 diff --git a/doc/source/conf.py b/doc/source/conf.py index 4983b9c3e..11b54e014 100644 --- a/doc/source/conf.py +++ b/doc/source/conf.py @@ -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 diff --git a/requirements.txt b/requirements.txt index 337ecad63..14787d831 100644 --- a/requirements.txt +++ b/requirements.txt @@ -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 diff --git a/setup.cfg b/setup.cfg index 9c00d5328..2d7ce8388 100644 --- a/setup.cfg +++ b/setup.cfg @@ -17,8 +17,5 @@ build-dir = doc/build source-dir = doc/source warning-is-error = 1 -[pbr] -warnerrors = True - [wheel] universal = 1 diff --git a/specs/backlog/pike/common-classification-framework.rst b/specs/backlog/pike/common-classification-framework.rst index 533e5d2f8..578efb6d4 100644 --- a/specs/backlog/pike/common-classification-framework.rst +++ b/specs/backlog/pike/common-classification-framework.rst @@ -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 diff --git a/specs/backlog/pike/diagnostics.rst b/specs/backlog/pike/diagnostics.rst index 892f75ee4..583f19626 100644 --- a/specs/backlog/pike/diagnostics.rst +++ b/specs/backlog/pike/diagnostics.rst @@ -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 diff --git a/specs/backlog/pike/layer-3-rate-limit.rst b/specs/backlog/pike/layer-3-rate-limit.rst index a5d761650..1d408b884 100644 --- a/specs/backlog/pike/layer-3-rate-limit.rst +++ b/specs/backlog/pike/layer-3-rate-limit.rst @@ -355,9 +355,9 @@ References .. [2] `Linux HTB Queuing `_ -.. [3] `[WIP] Floating IP rate limit `_ - -.. [4] `[WIP] Router gateway rate limit (abandoned) `_ - -.. [5] `[WIP] Adding L3 rate limit TC lib `_ +Related Information +------------------- +- `Floating IP rate limit `_ +- `Router gateway rate limit (abandoned) `_ +- `Adding L3 rate limit TC lib `_ diff --git a/specs/kilo/ipv6-router.rst b/specs/kilo/ipv6-router.rst index 816794b4d..22ead71e3 100644 --- a/specs/kilo/ipv6-router.rst +++ b/specs/kilo/ipv6-router.rst @@ -209,6 +209,10 @@ API semantic changes need to be documented. References ========== -.. [REFAC_L3] `Kilo refactoring and restructuring the l3 agent `_ .. [IPV6_ADDR] `IP Version 6 Addressing Architecture `_ .. [IPV6_FIP] `IPv6 Floating IP Support `_ + +Related Information +------------------- + +- `Kilo refactoring and restructuring the l3 agent `_ diff --git a/specs/kilo/ml2-ovs-portsecurity.rst b/specs/kilo/ml2-ovs-portsecurity.rst index 5e862b0a0..8634f4917 100644 --- a/specs/kilo/ml2-ovs-portsecurity.rst +++ b/specs/kilo/ml2-ovs-portsecurity.rst @@ -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 diff --git a/specs/kilo/multiple-ipv6-prefixes.rst b/specs/kilo/multiple-ipv6-prefixes.rst index 3e85848dd..73e13eb61 100644 --- a/specs/kilo/multiple-ipv6-prefixes.rst +++ b/specs/kilo/multiple-ipv6-prefixes.rst @@ -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) `_ -.. [Ref-4] DevStack Blueprint: `Add 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 `_ -.. [Ref-6] Neutron Blueprint: `Provider Networking - upstream SLAAC support - `_ - -.. [Ref-7] `OpenStack Neutron IPv6 Address Mode Attributes Table +.. [Ref-5] `OpenStack Neutron IPv6 Address Mode Attributes Table `_ -.. [Ref-8] RFC 4291: `IP Version 6 Addressing Architecture +Related Information +------------------- + +- DevStack Blueprint: `Add IPv6 support + `_ +- Neutron Blueprint: `Provider Networking - upstream SLAAC support + `_ +- RFC 4291: `IP Version 6 Addressing Architecture `_ diff --git a/specs/liberty/ipv6-prefix-delegation.rst b/specs/liberty/ipv6-prefix-delegation.rst index 8ee526822..0d32b9f2a 100644 --- a/specs/liberty/ipv6-prefix-delegation.rst +++ b/specs/liberty/ipv6-prefix-delegation.rst @@ -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 `_ -.. [3] RFC 4862: `IPv6 Stateless Address Autoconfiguration - `_ - -.. [4] Neutron Blueprint: `Add support for subnet allocation +.. [3] Neutron Blueprint: `Add support for subnet allocation `_ -.. [5] RFC 4862: `IPv6 Stateless Address Autoconfiguration - `_ - -.. [6] RFC 4861: `Neighbor Discovery for IP version 6 (IPv6) - `_ - -.. [7] RFC 4291: `IP Version 6 Addressing Architecture - `_ +Related Information +------------------- +- RFC 4862: `IPv6 Stateless Address Autoconfiguration + `_ +- RFC 4861: `Neighbor Discovery for IP version 6 (IPv6) + `_ +- RFC 4291: `IP Version 6 Addressing Architecture + `_ diff --git a/specs/liberty/neutron-python3.rst b/specs/liberty/neutron-python3.rst index 8a2578469..130b72369 100644 --- a/specs/liberty/neutron-python3.rst +++ b/specs/liberty/neutron-python3.rst @@ -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. diff --git a/specs/liberty/online-schema-migrations.rst b/specs/liberty/online-schema-migrations.rst index 9c900f598..fa2c36d10 100644 --- a/specs/liberty/online-schema-migrations.rst +++ b/specs/liberty/online-schema-migrations.rst @@ -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 diff --git a/specs/liberty/qos-api-extension.rst b/specs/liberty/qos-api-extension.rst index ae18820a1..b0a9e2c1e 100644 --- a/specs/liberty/qos-api-extension.rst +++ b/specs/liberty/qos-api-extension.rst @@ -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 diff --git a/specs/mitaka/rbac-qos-policies.rst b/specs/mitaka/rbac-qos-policies.rst index d746abd5a..51550ef72 100644 --- a/specs/mitaka/rbac-qos-policies.rst +++ b/specs/mitaka/rbac-qos-policies.rst @@ -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 diff --git a/specs/newton/ml2-qos-with-dscp.rst b/specs/newton/ml2-qos-with-dscp.rst index a3cc70a75..437731e4f 100644 --- a/specs/newton/ml2-qos-with-dscp.rst +++ b/specs/newton/ml2-qos-with-dscp.rst @@ -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 + `_ +- `QoS devref + `_ +- `QoS API doc + `_ diff --git a/specs/newton/unaddressed-port.rst b/specs/newton/unaddressed-port.rst index 3c08585f9..3d82cafdd 100644 --- a/specs/newton/unaddressed-port.rst +++ b/specs/newton/unaddressed-port.rst @@ -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/ diff --git a/specs/pike/port-data-plane-status.rst b/specs/pike/port-data-plane-status.rst index cc29cee4e..560887af3 100644 --- a/specs/pike/port-data-plane-status.rst +++ b/specs/pike/port-data-plane-status.rst @@ -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 diff --git a/tox.ini b/tox.ini index b92724b3d..29bb0081f 100644 --- a/tox.ini +++ b/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