In [1] the concept of "connectivity" was introduced for the ML2 drivers.
This parameter defines the mech driver connectivity type (layer 2, layer
3 only or legacy - not defined).
The spec defined in the blueprint allows to spawn a VM with ports
without IP addresses. As commented in the Nova spec [2], those ports can
be bound only to "l2" drivers.
[1] https://review.opendev.org/#/c/645645/
[2] https://review.opendev.org/#/c/641670/
bp boot-vm-with-unaddressed-port
Related-Bug: #1821058
Change-Id: I438cbab43b45b5f7afc820b77fcf5a0e823d0eff
Implements Conntrack Helper service plugin for conntrack
helper resources. Supports create, update and delete
conntrack helper for l3 routers.
A new configuration option:
[l3-conntrack-helpers]/allowed_conntrack_helpers
introduced to allow the operator to configure CT
helpers, and the helper protocol constraints.
Related-Bug: #1823633
Depends-On: https://review.opendev.org/663446
Change-Id: I58193955261f50b18b1946261fe662da6b20f0f5
The NetworkSegmentRange entry point in the setup.cfg references an
invalid package path to the corresponding OVO class. This patch fixes
the package name to reflect the proper path.
Change-Id: I228a159a9d3eca7021e3ba08d9ad40f9ff8329df
This patch adds an ironic notifier that sends notifications
to ironic endpoint /v1/events. The events are triggered by
port updates and deletions. Only ports with vnic_type
baremetal are honored.
Story: 1304673
Task: 22263
Closes-Bug: #1828367
Implements: blueprint event-notifier-ironic
Authored-By: Vasyl Saienko <vsaienko@mirantis.com>
Co-Authored-By: Harald Jensås <hjensas@redhat.com>
Co-Authored-By: Julia Kreger <juliaashleykreger@gmail.com>
Change-Id: I0bb3187a88a7f20adb8c60e24945db159afb83f1
Implements the conntrack helper OVO and db layer code.
- New object 'ConntrackHelper'
- New db model
- migration db script
Related-Bug: #1823633
Change-Id: I0d9c039b260845b6544eccf63f5a2ffaa929120b
This goal is to implement the process set out in the 2018-10-24 Python
Update Process TC resolution[1], for the Train cycle to ensure unit
testing is in place for all of the Tested Runtimes for Train[2].
In practice, this generally means adding unit tests for Python 3.7 and
dropping unit tests for Python 3.5.
For Neutron, which already runs py36 and py37 unit tests it generally
means switch to use the Zuul template openstack-python3-train-jobs
for Train.
Using this template will ensure that all projects that support Python3
will be tested against the agreed runtime versions, and make it easier
to update them in future.
[1]https://governance.openstack.org/tc/resolutions/20181024-python-update-process.html
[2]https://governance.openstack.org/tc/reference/runtimes/train.html
Change-Id: I41d232a10a40d97347566e189457d8044e3639db
Depends-On: https://review.opendev.org/#/c/641878/
Drive the choice of mechanism driver during binding as inferred from
the resource provider allocated by nova and as told to neutron via the
port's binding:profile.
As discussed on a neutron qos irc meeting some time ago
this patch introduces a new assumption on bind_port() implementations.
That is an implementation of bind_port() in any mech driver supporting
Guaranteed Minimum Bandwidth bind_port() must not have a non-idempotent
side effect. Because the last binding level will be redone for a 2nd
time with a narrowed down list of mechanism drivers. And if the 2nd call
does not give the same result as the first all kind of weird things can
happen.
Change-Id: I2b7573ec6795170ce45a13d5d0ad7844fb85182d
Depends-On: https://review.openstack.org/574781
Depends-On: https://review.openstack.org/635160
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
This patch adds the support for network segment range CRUD. Subsequent
patches will be added to use this network segment range on segment
allocation if this extension is loaded.
Changes include:
- an API extension which exposes the segment range to be administered;
- standard attributes with tagging support for the new resource;
- a new service plugin "network_segment_range" for the feature
enabling/disabling;
- a new network segment range DB table model along with operation
logic;
- Oslo Versioned Objects for network segment range data model;
- policy-in-code support for network segment range.
Co-authored-by: Allain Legacy <Allain.legacy@windriver.com>
Partially-implements: blueprint network-segment-range-management
Change-Id: I75814e50b2c9402fe6776229d469745d7a72290b
This service plugin synchronizes ML2 mechanism driver agents' resource
information to Placement. To use this service an agent must add
'resource_provider_bandwidths' to the 'configurations' field of its
RPC heartbeat. It also may add 'resource_provider_inventory_defaults'
to fine tune Placement inventory parameters. Again to use this service a
mechanism driver must implement get_standrd_device_mappings() and allocate
a UUID as mechanism driver property 'resource_provider_uuid5_namespace'.
The synchronization is triggered by:
* any new agent object in the DB
* restart of an agent (via 'start_flag' in the RPC heartbeat)
* if an agent's 'resources_synced' attribute is not True (None/False)
The latter should autoheal transient errors of the synchronization
process. That is if a sync attemp fails then we store
resources_synced=False which triggers a sync retry at each new heartbeat
message until a sync attempt finally succeeds and we can set
resources_synced=True.
Since this code functionally depends on ML2 we can also consider making
it part of ML2, but at the moment it is a service plugin for better
decoupling. Even if you load the service plugin the logic gracefully
degrades for heartbeat messages not containing resource provider info.
If needed the sync can be forced in multiple ways. First, if you restart
an agent then the RPs belonging to that agent will be re-synced. You may
also delete the agent by 'openstack network agent delete' and let the
next heartbeat message re-create the agent object. On re-creation the
RPs belonging to that agent will be re-synced. On the other hand a
neutron-server restart does not trigger a re-sync in any way. Depending
on the trade-off between the admin's needs to force re-syncs and the
performance of (not absolutely necessary) Placement updates re-sync
conditions may be further fine tuned.
Example config for neutron-server:
neutron.conf:
[DEFAULT]
service_plugins = placement
Change-Id: Ia1ff6f7559ab77913ddb9c3b134420a401b8eb43
Co-Authored-By: Lajos Katona <lajos.katona@ericsson.com>
Depends-On: https://review.openstack.org/586567
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
CLI command "neutron-status upgrade check" now can load
checks from 3rd party and stadium projects using entry_points.
Such additional checks should be available under
"neutron.status.upgrade.checks" namespace in entry_points.
Change-Id: I416abbcdd7b397ec6acd2827129d7a56095ea63d
Story: 2003657
This commit introduces a framework for policy-in-code support
in the neutron stadium and converts the existing policy.json
in the neutron repository into the policy-in-code style.
NOTES:
1) This commit tries not to change the existing policy behavior
provided by the neutron repository even if there are some stale policies
or policies to be defined in a neutron-related project.
They should be clean up later in Stein release.
2) 'default' policy should be dropped from the default policies
as all default policies should be defined in the code (as many projects
which already completed policy-in-code do). However, dropping 'default'
policy potentially affects policy behavior in neutron-related projects,
so it needs to be visit carefully. Considering this, this commit decides
to keep the 'default' policy.
Partially Implements: blueprint neutron-policy-in-code
Change-Id: I6a61079da4d4f5080ee32d640144e6bdb14735fa
openstack-dev was decomissioned this night in https://review.openstack.org/621258
Update openstack-dev to openstack-discuss
Change-Id: I739ec6a4984df396b11b29f2d55f0d24fecab6eb
This patch implements the L3 agent side router gateway IP rate
limit. For routers in centralized snat node (network node),
the tc rules will be set on the corresponding device in router
namespace:
1. Legacy and HA router, qrouter-namespace and qg-device
2. Dvr (edge) router, snat namespace and qg-device
If gateway IP rate limit was set, then under the same router,
all the VMs without floating IP will share the bandwidth.
Partially-Implements blueprint: router-gateway-ip-qos
Closes-Bug: #1757044
Change-Id: Ie92ff0d4df0e85ce71c7d50f34ea6ff973812af8
This patch enables to bind a QoS policy to the router gateway,
then in L3 agent side SNAT traffic for the VMs without floating
IPs can be limited under the policy bandwidth rules. This is
suit for all kinds of L3 routers: DVR, DVR with SNAT HA, L3 HA
and Legacy.
API update router gateway json:
{
router": {
"external_gateway_info": {
...
"qos_policy_id": "policy-uuid"
}
}
}
Depends-On: https://review.openstack.org/#/c/567497/
Partially-Implements blueprint: router-gateway-ip-qos
Closes-Bug: #1757044
Related-Bug: #1596611
Change-Id: I26e22bce7edd1f93b2ac0048b61b14f858938537
This adds basic framework for neutron-status upgrade check commands.
For now it has only "check_nothing" check implemented.
Real checks can be added to this tool in the future.
Depends-On: https://review.openstack.org/#/c/610061/
Change-Id: Ib08119e1bb8de80856edb6a39769d4bc9d98c587
Story: 2003657
Task: 26144
This patch introduces SNAT logging extension for Neutron Packet Logging
framework.
Co-Authored-By: Kim Bao Long <longkb@vn.fujitsu.com>
Partial-Bug: #1752290
Change-Id: I882b8e75525f51ef8b5b032fc89843ae904844e7
This patch contains the l3 agent extension and agent part code.
This patch introduce a new l3 agent extension named "port_forwarding",
to process the binding of the port forwarding resources, manage its own
floatingip configuration on router interface and floatingip status.
Currrently, we support all Neutron Router reference implementations.
This extension uses the period router sync task and PortForwarding OVO
rpc.
* The main idea about this new extension is using the generic router sync
rpc to maintain the host port forwarding resources,
* For a single port forwarding create/update/delete, process it one by one
in smaller scope for forbidding refresh the iptables with a larger
scope frequently.
Partially-Implements: blueprint port-forwarding
Partial-Bug: #1491317
Change-Id: Ic56e67d428f6177099c285a9d1bccabc1e710f2b
This patch implements the plugin.
This patch introduces an new service plugin for port forwarding resources,
named 'pf_plugin', and supports create/update/delete port forwarding
operation towards a free Floating IP.
This patch including some works below:
* Introduces portforwarding extension and the base class of plugin
* Introduces portforwarding plugin, support CRUD port forwarding
resources
* Add the policy of portforwarding
The race issue fix in:
https://review.openstack.org/#/c/574673/
Fip extend port forwarding field addition in:
https://review.openstack.org/#/c/575326/
Partially-Implements: blueprint port-forwarding
Change-Id: Ibc446f8234bff80d5b16c988f900d3940245ba89
Partial-Bug: #1491317
We've already added support for pluggable (via entry points) object
loading in neutron-lib with [1]
This patch exposes the neutron.objects in setup.cfg using entry points
so that consumers can start to use them via the API in [1] rather than
directly import them from neutron.
[1] https://review.openstack.org/#/c/553838/
Change-Id: I25ddd77c55f48997ff6131f232addb4c2e629804
Move the l3 qos extensions to a separated folder,
then we can move a following up router gateway IP
QoS extension to it.
And also extract some common code to a base class.
Related-Bug: #1757044
Change-Id: I63cc9506caa80f889ad817444281a0ac31bc9418
This patch implements the L3 agent side floating IP rate limit.
For all routers, if floating IP has qos rules, the corresponding
TC filters will be added to:
1. for legacy/HA router, the device is qg-device of qrouter-namespace,
aka router gateway in network node.
2. for dvr (HA) router in compute node, the device is rfp-device, the
namespace is qrouter-namespace.
3. for dvr (HA) router in network node, the device is qg-device in
snat-namespace.
Partially-Implements blueprint: floating-ip-rate-limit
Change-Id: Ie8a5fe4ebaeccfb3998732dd972663c54542b5bf
The name ('logapi') seems redundant 'api' and it looks inconsistent
with entry point name of logging agent extension ('log') and
LoggingPlugin class[1]. So this patch change 'logapi' to 'log' to
make it look consistent.
[1] https://github.com/openstack/neutron/blob/master/neutron/services/logapi/logging_plugin.py#L27
Change-Id: I57d0b86823670a1dc5d116d98059993c802ef86c
Partially-implements: blueprint security-group-logging
Related-Bug: #1468366
The plugin has been split into its own repository[1] in accordance with
Queens Goal "Split Tempest Plugins into Separate Repos/Projects[2]".
This patch removes the local copy as well as the setuptools entry point.
We can also now remove the autodoc_tree_excludes pbr option since
there's no more plugin to exclude and it defaults to [setup.py].
The patch leaves still in-tree base classes and constants in order to
avoid breakage of projects depending on such code. In the future, we
will deprecate those and gradually move affected subprojects to the new
repo.
List of affected repositories:
- neutron-vpnaas
- openstack-ansible-os_neutron
- tripleo-quickstart-extras
- networking-midonet
- networking-l2gw
- neutron-dynamic-routing
- networking-vsphere
- networking-plumgrid
- networking-zvm
[1] http://git.openstack.org/cgit/openstack/neutron-tempest-plugin
[2] https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html
Depends-On: I371aa4d5f043f695df04b98b0f485c8f0548f2b3
Change-Id: Ia21aad29d0bbf779583964db6f1665c9b3b83161
The current method of specifying each rootwrap filter
in the file list is prone to errors when adding or
removing filters. Instead of relying on a manually
maintained list this patch just includes all the files
of the correct naming convention from the applicable
folder. This is simpler and easier to maintain.
Closes-Bug: #1718356
Change-Id: I7f8c55f63d1c5a85a6a92062e918426f7d2d3c35
* Update the URLs affected by the doc-migration
(/developer/<project>/ to <project>/latest/)
* Follow content rearrangement
* Convert links to local documents into :doc: or :ref:
* Use https instead of http for the updated links on docs.openstack.org.
Part of the doc-migration work.
Change-Id: I62e317d9198f175a43d73bbfd419b6878de90d5a
This change adds a dns_domain attribute to ports in the API.
This patchset belongs to a series that adds dns_domain attribute
functionality to ports.
Change-Id: Ied1f2f0c1e96ae21c309b6e6fed9e3c602b0450b
Partial-Bug: #1650678
This patch introduces the logging api definition and initial
implementation of LoggingApiPlugin. The api definition code will
be removed after [1] has been merged on neutron lib.
[1]https://review.openstack.org/#/c/415817/
Co-Authored-By: Yushiro FURUKAWA <y.furukawa_2@jp.fujitsu.com>
Partially-implements: blueprint security-group-logging
Related-Bug: #1468366
Change-Id: Iace31506502de25da9dce5fcfdbfe2c726bea27f
In Ocata, notification_drivers were deprecated in favor of
the new QoSDriver architecture.
This patch removes backwards compatible support for notification
drivers along with its testing.
Change-Id: I5f747635be3fd66b70326d9f94c85a6736286bd2
This can then be loaded into a wsgi compatible web server like
apache2/httpd or nginx.
DocImpact A new neutron-api script is installed, and can be used to
start either a standalone wsgi server (calling the script directly),
or as a wsgi script loaded by a web server (e.g. by httpd/mod_wsgi).
Change-Id: Ie9bb8b33f6e1335219e574d832ac264b043d90e6
Partial-Bug: #1666779
Co-Authored-By: Brandon Logan <brandon.logan@rackspace.com>
Co-Authored-By: Ihar Hrachyshka <ihrachys@redhat.com>
Implements the port data plane status extension. Third parties
can report via Neutron API issues in the underlying data plane
affecting connectivity from/to Neutron ports.
Supported statuses:
- None: no status being reported; default value
- ACTIVE: all is up and running
- DOWN: no traffic can flow from/to the Neutron port
Setting attribute available to admin or any user with specific role
(default role: data_plane_integrator).
ML2 extension driver loaded on request via configuration:
[ml2]
extension_drivers = data_plane_status
Related-Bug: #1598081
Related-Bug: #1575146
DocImpact: users can get status of the underlying port data plane;
attribute writable by admin users and users granted the
'data-plane-integrator' role.
APIImpact: port now has data_plane_status attr, set on port update
Implements: blueprint port-data-plane-status
Depends-On: I04eef902b3310f799b1ce7ea44ed7cf77c74da04
Change-Id: Ic9e1e3ed9e3d4b88a4292114f4cb4192ac4b3502
By using the on_missing_entrypoints_callback and
on_load_failure_callback options[1] we can call a handler for the
missing driver error properly.
As the bug states, I logged it as a critical failure and terminated
the neutron server.
I used SystemExit, I wasn't sure if there was a more graceful way
of exiting.
[1] http://docs.openstack.org/developer/stevedore/managers.html
Change-Id: Id18afd159d0b0ada0cc36964dd9c1ebe7a1cd94b
Closes-Bug: #1659290