- Move specification for Neutron-Neutron Interconnections RFE for
implementation in Stein release,
- Remove redundant states from lifecycle FSM,
- Add remote_interconnection_id attribute to interconnection resource,
- Minor update in API exchange example.
Signed-off-by: Thomas Morin <thomas.morin@orange.com>
Submitted on behalf of a third-party: Orange
Change-Id: I30a886813cdca4ed47507bbff38aff2d4137b434
Related-Bug: 1750368
Currently, most plugin implementations releated L3 override the
L3NatAgent class itself for their own logic since there is no proper
interface to extend RouterInfo class. This adds unnecessary complexity
for developers who just want to extend agent mechanism instead of
whole RPC related to L3 functinalities.
This spec introduces RouterFactory class which acts on the factory for
creating RouterInfo class, and add new l3 extension API which enable to
dynamically add RouterInfo to the factory. Now plugin developers can
use new extension API for their own specific router.
Change-Id: Ic3486830e449f6ee8dbe19db614179b2077bcf7b
Related-Bug: #1804634
Implements: blueprint router-factory-with-l3-extension
In the context of a live datacenter, sometimes the network teams re-organize
their VLANs by changing VLAN IDs. This is pretty straightforward in the
context of network configuration and physical servers, but when using ML2
VLAN provider networks, those IDs cannot be updated. The only possible
solution here would be to delete those networks and recreate them with a
different segmentation ID which might be a problem when you have 1000 VMs
and 2000 ports.
For this reason it would be good if we could change the segmentation ID of
an existing network.
Change-Id: I71b5b4ff2ba7ace3a8523de2ae6e4dc6a1c110c2
Related-Bug: #1806052
This spec is the Neutron side changes to support
smart NICs with Neutron OVS ML2 mechanism driver
and Neutron OVS Agent.
Related-Bug: #1785608
Change-Id: I658754f7f8c74087b0aabfdef222a2c0b5698541
JSON regulates key type to be string.
Co-Authored-By: Matt Peters <matt.peters@windriver.com>
Partially-implements: blueprint network-segment-range-management
Change-Id: I946a6ee14cef4f6b2e7e29ac644b31e1c340e83b
The proposed `shared` attribute in the resource extension table should
have a default value `True` to align with the definition in the
RESOURCE_ATTRIBUTE_MAPS.
Co-Authored-By: Matt Peters <matt.peters@windriver.com>
Partially-implements: blueprint network-segment-range-management
Change-Id: Ic7f98a71bcfe289754438f9c3d1eed2d3ed4bfdc
This patch is a follow-up to [1] to propose adding a new `read-only`
attribute `default` to the network segment range resource. It tracks
whether this is a range that is managed/loaded from the host ML2 config
file [2].
The attribute is proposed based on the following considerations:
1. We prefer the underlying network segment ranges to be exposed so that
an admin can base on the info to make per-tenant range assignment;
2. We want the backward compatibility to be maintained, i.e. no work
flow change with and without the extension is loaded;
3. We need to handle the range DB refresh/config repopulation when a
Neutron server starts/restarts.
[1] https://review.openstack.org/599980
[2] /etc/neutron/plugins/ml2/ml2_conf.ini
Co-Authored-By: Matt Peters <matt.peters@windriver.com>
Partially-implements: blueprint network-segment-range-management
Change-Id: I8cc0ed77603a5d430c6d7b2b503c7b5a80ed0051
Add SRIOV mirroring support to Tap as a Service.
Allows Vlans to VF mirror.
Allows VF to VF mirror.
Spec for new tap agent for sriov and driver for Intel i40e nic.
Added the two implementation approaches to API.
Change-Id: If2e4e2bf70f11ab0136482cb86acad3a3eded649
Currently, network segment ranges are configured as an entry in ML2
config file [1]_ that is statically defined for tenant network
allocation and therefore must be managed as part of the host deployment
and management. When a normal tenant user creates a network, Neutron
assigns the next free segmentation ID (VLAN ID, VNI etc.) from the
configured segment ranges; only an administrator can assign a specific
segment ID via the provider extension.
This spec introduces an extension which exposes the segment range
management to be administered via the Neutron API. In addition, it
introduces the ability for the administrator to control the segment
ranges globally or on a per-tenant basis.
[1] /etc/neutron/plugins/ml2/ml2_conf.ini
Co-Authored-By: Matt Peters <matt.peters@windriver.com>
Implements: blueprint network-segment-range-management
Change-Id: I2e586bb6d51d32c0ac2a28b2429512cea036f363
Before the final merge of the minimum bandwidth resource classes
they got renamed in Nova and Placement. So we have to adapt.
This change retroactively updates the spec.
Change-Id: Ia347c71381ec2fd82a1b197f5d0fbed69a70ad70
Partial-Bug: #1578989
See-Also: I996bf705b14b564106426a2e57299638fb178750
See-Also: https://review.openstack.org/616194
The commands used by constraints need at least tox 2.0. Update to
reflect reality, which should help with local running of constraints
targets.
Change-Id: Ie69f0a6fa56fd1fceaa7893bece8b2735095216c
Related-Bug: 1801465
We want to default to running all tox environments under python 3, so
set the basepython value in each environment.
We do not want to specify a minor version number, because we do not
want to have to update the file every time we upgrade python.
We do not want to set the override once in testenv, because that
breaks the more specific versions used in default environments like
py35 and py36.
Change-Id: I6e18dd70a74694ba2e7aad535f487498a26d05bb
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The py27 test ensures that all specs are following a specific format.
The default py27 tests have an irrelevant-files list that ignores
running if especially only .rst files get updated. Override the
irrelevant files list so that it runs for nearly all changes,
only skip for release-notes (even if they do not exist here).
Change-Id: Iffb6345ddf490820ca7495f0e4a0e722acfba898
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I482073ef15154dff754839ffd161fe08211ebc89
Story: #2002586
Task: #24314
The QoS DSCP spec is not terribly specific about what DSCP marks are
valid. This change makes it explicit.
This spec is quite old. But since there has been no other place in the
documentation that explicitly lists what the valid DSCP marks are,
updating this in case people use it as documentation.
Change-Id: Ieec3e238b8d404e46c49b5a1a0fdaf695fff4252
Related-Bug: #1781915
According to Openstack summit session [1] stestr is
maintained project to which all Openstack projects
should migrate.
Let's switch it then.
[1] https://etherpad.openstack.org/p/YVR-python-pti
Change-Id: Idd7629f2a051aadaf53b04a1b331b20d7fa690de
This spec provides details on a enhancement to Firewall as
a Service(FWaaS) API 2.0 for supporting address groups.
Change-Id: I7472f9611e2f5794c46f37fbbacadf38e0320a6f
In py27 job index.rst file was checked as any other file if it
contains required headers and sections.
But index.rst file has different format so this file should be
skipped in this test.
After that there was also issue with unexpected "Footnotes"
section in neutron-inter.rst specs so this was also fixed.
Change-Id: If2baf887c49025a5481e97b2fb3500736b8668b6
This change includes:
* a follow-up to [1] to fix the typos pointed out during review
* title fixes for two specs having the same title in the TOC
* two other typos
[1] https://review.openstack.org/545826
I3860a62420ab4983e2b741dff04498fbb0432d00
Change-Id: I4ebb090de53370708e871c75c789b62bc5e71010
This spec describes how to model, from Neutron, a new resource provider
in the Placement API to describe the bandwidth allocation.
Based on a Rocky PTG discussion this is a re-work of the spec.
Co-Authored-By: Rodolfo Alonso Hernandez <rodolfo.alonso.hernandez@intel.com>
Co-Authored-By: Bence Romsics <bence.romsics@ericsson.com>
Co-Authored-By: Balazs Gibizer <balazs.gibizer@ericsson.com>
Related-Bug: #1578989
Change-Id: Ib995837f6161bcceb09735a5601d8b79a25a7354
See-Also: Ie7be551f4f03957ade9beb64457736f400560486
- Update outdated links in README
- Remove skeleton.rst, this file is unnecessary.
- Add Stein Specifications dir.
- Move placeholder.rst to stein dir, because there
is a blueprint accepted in rocky dir.
Change-Id: I5fd436db02517404d3aca3114498206f164bca44
This is the spec for the VPN Qos.
Paritial-Bug: #1727578
Change-Id: I5f94b89d2e11734385b58e5e5edf55d149b9f38a
Depends-On: If40305044c9dfe0024b64bd3921232bb0a6c9372
This spec provides details on how we can break consumer dependencies
on neutron's database model as well as object imports by
exposing neutron objects as entry points that are discoverable and
loadable from neutron-lib. This spec is part of a set of specs related
to decoupling the db for neutron-lib (see patch topic).
Change-Id: I079d06502e6e7b1e20aea882979b0ecd9106eaeb
This spec provides details on how we can break consumer dependencies
on neutron's db API and utilities by rehoming respective generic
functionality into neutron-lib. It's 1 spec in a set related to
decoupling sub-projects from neutron's db logic/layer.
Change-Id: I7b04e202321e1422e53c59c2bab0c85946fcb704