Added a new port extension: device profile (``port_device_profile``).
This extension adds the "device_profile" parameter to the "port" API
and specifies the device profile per port. This parameter is a
string.
This parameter is passed to Nova and Nova retrieves the requested
device profile from Cyborg. Reference:
https://docs.openstack.org/api-ref/accelerator/v2/index.html#
device-profiles
For backwards compatibility, this parameter will be "None" by
default.
Closes-Bug: #1906602
Depends-On: https://review.opendev.org/c/openstack/neutron-lib/+/767586
Change-Id: I1202a8388e64ae4270ef4ca118993504ae7c1731
As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.
Also replace policy.json to policy.yaml ref from doc and tests.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: I0dbb8484e749e645627756e88ec79c1b26a6414a
Added a new port extension: NUMA affinity policy. This extension adds
the "numa_affinity_policy" parameter to the "port" API and specifies
the NUMA affinity policy per port.
This parameter is passed to Nova when a virtual machine is created.
Nova will use this information to schedule the virtual machine.
For backwards compatibility, this parameter will be "None" by default.
Depends-On: https://review.opendev.org/#/c/740058/
Closes-Bug: #1886798
Change-Id: Ie3d68c098ddb727ab8333aa1de4064e67a4f00a7
These translation sections are not needed anymore, Babel can
generate translation files without them.
Change-Id: I102c9ad3804705659d54c537681b525e1f8cc05d
Now that we are running the Victoria tests that include a
voting py38, we can now add the Python 3.8 metadata to the
package information to reflect that support.
Change-Id: I2053adc65b86e6616c3998a3c8d3143a1d0dd28f
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This patch is migrating the OVN migration scripts. At the moment, only
migration from ML2/OVS to ML2/OVN in a TripleO environment is supported.
Co-Authored-By: Miguel Angel Ajo <majopela@redhat.com>
Co-Authored-By: Jakub Libosvar <libosvar@redhat.com>
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Co-Authored-By: Maciej Józefczyk <mjozefcz@redhat.com>
Co-Authored-By: Numan Siddique <nusiddiq@redhat.com>
Co-Authored-By: Roman Safronov <rsafrono@redhat.com>
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Related-Blueprint: neutron-ovn-merge
Change-Id: I925f4b650209b8807290d6a69440c31fd72a1762
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This change proposes a ML2 plugin extension to implement tagging during
bulk port creation.
Change-Id: Ic70f7d282db478c69016ab1c317c5cae786401ce
Related-Bug: #1815933
This patch is migrating the OVN tools and adding its entry points.
Change-Id: Ia1575b2b7fb93b09d8e54f9230ea2f29c1d59c42
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This takes care of the last details for dropping py27 support by adding
a proper min version of python in setup.cfg.
Change-Id: I911469d46fccf13bc7ead7a103a7d6e4e0ede7c3
This patch is migrating the entry points for the OVN metadata agent.
Change-Id: I4062ade1231e29344a38cb69f32c3a0f198a7d03
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Related-Blueprint: neutron-ovn-merge
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
As described in [0] a new attribute ``dns_publish_fixed_ip`` is added
to subnets, allowing to specify directly whether DNS records should be
published for this subnet. This overrides the previous behaviour that
makes this decision based on various properties of the network that
the subnet is contained in, see [1].
[0] https://launchpad.net/bugs/1784879
[1] https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html
Change-Id: I14605ead2694d9e9422b3d7b519aed2e3c340e2a
Partial-Bug: 1784879
Since it's no longer supported past Train, lets stop
running the tests.
Updated docs and made some pep8 code tweaks as well.
Change-Id: I1c171ab906a3b4c66558163ad26947ebf710a276
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