The metadata_rate_limiting options were added during the previous
cycles[1] but these options were not added to the oslo.config entry
points thus are still missing from the example config files.
This change adds these options to the appropriate entry points so that
the options are picked up by oslo-config-generator.
These options were previously registered by metadata-agent which are
not using these options really. This change also removes that useless
registration.
[1] 5f4a41326d
Closes-Bug: #2044896
Change-Id: Ib4bea51e24063c275737cdd769ad07c621a845f6
Host haproxy configurations will be rendered by jinja2
template. And a process monitor will be used to manage
the host metadata haproxy, which takes care of the
lifecycle of the host metadata haproxy.
Partially-Implements: blueprint distributed-metadata-datapath
Change-Id: Ie7be84d503f5d60d3c50d3ac3aaaf55c13adf7af
This change ensures the [designate] options, which is used by
the designate external DNS driver, are rendered into neutron.conf
generated by oslo-config-generator.
Change-Id: I56a1079fbfc044532aee64f4fbdec50d9524a580
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
some of them, about 10%.
Feel free to reject if we think it will cause too much
trouble with cherry-picks, else I'll slowly work my way
through the rest of the tree.
Trivialfix
Change-Id: I3d484d11e273cb8ee617f9445a069887e7b2b89f
During the Zed PTG it was decided to handle unsupported features in
Neutron as experimental. See section titled "When we say something is
not supported?", day 2 in [1]. The agreement was:
"We keep existing jobs for linuxbridge driver for example, but when the
tests start to fail we skip them and finally we stop the job also.
To make it clear for operators we add warning logs highlighting that the
given feature/driver is experimental, and introduce cfg option to enable
such features explicitly."
This commit implements this agreement, initially with Linuxbridge
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/845646
[1] https://lists.openstack.org/pipermail/openstack-discuss/2022-April/028164.html
Change-Id: Ib18efa3f472736b58c8967847b1061da0e3897d7
Only 'DEFAULT' is an allowable all-caps option group name,
else a warning is generated:
WARNING:oslo_config.generator:normalizing group name 'DHCP' to 'dhcp'
Can see this in the 'tox -e docs' job.
Trivialfix
Change-Id: Ic2dbb1c91220f84cdcb73c9e3559728d54c21a25
Neutorn uses oslo.cache library for caching. This change ensures that
options of the library are included in neutron.conf generated by
oslo-config-generator.
This change also removes cache_utils module from neutron.opts because
the module is not used in that file.
Closes-Bug: #1940790
Change-Id: I9ccd145d5ea1a1e0033eb43b609cc6428ea95f23
The rpc_response_max_timeout parameter is used in comminucation over
messaging queue, thus should be available for sriov-agent which
communicate with neutron-server over messaging queue.
Change-Id: Ie6ae31e40488fd8f3d43e83b25e536a7dd9d938c
Closes-Bug: #1930996
To assist with automated configuration validation, we need entry points
for oslo.config.opts for placement auth options.
Change-Id: Ibaaa1600e6a14f3308024c4e22e3489ee21e7244
This change cleans up the configuration options for Xen API support,
which was deprecated during the Wallaby cycle[1] and have been
ineffective.
[1] a6dbf97242
Change-Id: I89f304f767b2ec645ac7bb216890b6ac470fd875
The rpc_response_max_timeout parameter is used in comminucation over
messaging queue, thus should be available for metadata-agent which
communicate with neutron-server over messaging queue.
Change-Id: I4826edf16bbdf338af6e050b15b4ecce9f8ca6ae
Closes-Bug: #1920842
Options for XenAPI support are supposed to have been deprecated, but
actually they were removed by the deprecation patch[1]. This change is
a partial revert of that patch[1], and ensures that these options are
loaded, so that warning messages about these deprecated options appear
in logs.
This change also removes these deprecated options from the example
rootwrap conf file.
[1] a6dbf97242
Change-Id: Id024dabf276e492268e723e526d7a787156eb9c1
Both the neutron.base.agent and neutron.l3.agent
option templates contain RPC_EXTRA_OPTS, leading to
a warning during doc builds:
doc/source/configuration/l3-agent.rst:3:
WARNING: Duplicate ID: "DEFAULT.rpc_response_max_timeout".
It also leads to the rpc_response_max_timeout option
showing up twice in the resultant l3-agent.ini sample
file. For example, when running 'tox -e genconfig'.
Remove it from the list of l3-agent specific options as
it's unnecessary.
Trivial-fix
Change-Id: I70e626dbf9de4bd43952836f8c4d01a693ddac7f
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
When configuring fwaas_v2 log, we can specify rate_limit, burst_limit
and local_output_log_base options in nework_log section.
Change-Id: Iba061c399599cf601c22054b3924b9a74f0f4fa0
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
The configuration variable "rpc_response_max_timeout" is not defined
in the OVS agent configuration. When the agent is stopped (SIGTERM),
the exception is raised. This error can be seen in the fullstack tests.
Change-Id: Ieedb6e87a4e98efef0f895566f7d4d88c3cd9336
Closes-Bug: #1815797
Now supported_vnic_types is hardcoded to the mechanism drivers, but that
can depend on several factors, like type of the NIC, admin decision,
etc.
With this patch we put the right to decide which vnic types are
supported for ovs agent into the hands of the admin, by allowing
blacklisting items from the mechanism driver specific list.
Background: http://eavesdrop.openstack.org/meetings/neutron_qos/2018/
neutron_qos.2018-07-31-15.00.log.html#l-58
Change-Id: Iad9e2e966df53b4164d2a56a93215c69825b5241
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
Now supported_vnic_types is hardcoded to the mechanism drivers, but that
can depend on several factors, like type of the NIC, admin decision,
etc.
With this patch we put the right to decide which vnic types are
supported for ovs agent into the hands of the admin, by allowing
blacklisting items from the mechanism driver specific list.
Background: http://eavesdrop.openstack.org/meetings/neutron_qos/2018/
neutron_qos.2018-07-31-15.00.log.html#l-58
Change-Id: I63e562e2eccc5b02c1c767d6a2c28cb803131e99
Partial-Bug: #1578989
See-Also: https://review.openstack.org/502306 (nova spec)
See-Also: https://review.openstack.org/508149 (neutron spec)
It's not specific to cli implementation of ovsdb interface.
Also moved the option under [agent] section.
Change-Id: Ic5e38d0c36ae29a9fef23038a9262d14ef1ede90
Refactoring neutron db config opts to be in neutron/conf/db/ and
neutron/conf/agent/database/ so that all the configuration options
reside in a centralized location. This simplifies the process of
looking up the config opts and provides an easy way to import.
Change-Id: I4da9bb48d49b99e8c2b34a5c1b83e7eb95b70b82
Partial-Bug: #1563069
The l2pop ML2 mechanism driver's configuration options are no longer
being generated during the docs build. This patch adds the l2pop
config options back into the ml2 sample config generation and also
fixes a link to them in the admin docs.
This fix is a candidate for backport to pike.
Change-Id: Ia26b4d1995690e7291b6476dc683271e12de09ab
Closes-Bug: #1714528
Refactoring neutron ml2 config opts to be in neutron/conf/plugins/ml2.
This would allow centralization of all configuration options and
provides an easy way to import.
NeutronLibImpact
Change-Id: Ibc5a9ab268578c243ef13f7e0041bacd6c0c410b
Partial-Bug: #1563069
Needed-By: Id0a97dda7718f06e33b2d30ce01cdcb3e9a46f7d
Refactoring neutron agent linux and ovsdb config opts
to be in neutron/conf/agent so that all the config options
reside in a centralized location. This simplifies the
process of looking up the config opts and provides an easy
way to import.
NeutronLibImpact
Change-Id: Ib1e0e63dec2985c417412d1ecc68e2a74ef87182
Partial-Bug: #1563069
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
Refactoring Neutron configuration options for agent common config to be
in neutron/conf/agent/common. This will allow centralization of all
configuration options and provide an easy way to import.
Partial-Bug: #1563069
Change-Id: Iebac0cdd3bcfd0135349128921b7ad7a1a939ab8
Needed-By: Ib676003bbe909b5a9013a3178b12dbe291d936af
Due to the high memory footprint of current Python ns-metadata-proxy,
it has to be replaced with a lighter process to avoid OOM conditions in
large environments.
This patch spawns haproxy through a process monitor using a pidfile.
This allows tracking the process and respawn it if necessary as it was
done before. Also, it implements an upgrade path which consists of
detecting any running Python instance of ns-metadata-proxy and
replacing them by haproxy. Therefore, upgrades will take place by
simply restarting neutron-l3-agent and neutron-dhcp-agent.
According to /proc/<pid>/smaps, memory footprint goes down from ~50MB
to ~1.5MB.
Also, haproxy is added to bindep in order to ensure that it's installed.
UpgradeImpact
Depends-On: I36a5531cacc21c0d4bb7f20d4bec6da65d04c262
Depends-On: Ia37368a7ff38ea48c683a7bad76f87697e194b04
Closes-Bug: #1524916
Change-Id: I5a75cc582dca48defafb440207d10e2f7b4f218b
For Neutron's compute agent in a XenServer's compute node, the commands
actually need run in Dom0. Currently XenServer only supports rootwrap
for that purpose by invoking a script which invokes XenAPI to execute
commands in dom0. There are much performance overhead due to it requires
parsing on the script and the configuration file every time running
commands.
This change is to support daemon mode with which each agent service will
call XenAPI directly to execute commands in dom0. And it will keep the
single XenAPI session.
DocImpact: Need update the following configuration.
file: /etc/neutron/plugins/ml2/openvswitch_agent.ini
[agent]
root_helper_daemon = xenapi_root_helper
[xenapi]
connection_url = http://169.254.0.1
connection_username = root
connection_password = xenroot
Closes-Bug: #1585510
Change-Id: I684034359fe0571bc92dbcf342a9821553b1da35
This option was added in Newton as part of blueprint l3-agent-extensions
but was not exposed into the sample config file.
Change-Id: Ifdb60032223d37858f41e6c3efc18f0de72912db
Closes-Bug: #1643944
This option may be used by dhcp, l3, metering, and any other agents that
instantiate an OVSBridge, that includes all agents that may use
'openvswitch' interface_driver.
Change-Id: Id05c88bd28ac0f4bf6b9f2956ccfcc98575e1bf9
Refactoring ml2 plugin openvswitch driver configuration options to be
in neutron/conf/plugins/ml2/drivers. This would allow centralization
of all configuration options and provides an easy way to import.
Change-Id: Ie8c6023b2d012eae7ecdb99d5d413956608f4294
Partial-Bug: #1563069
Refactoring neutron ml2 plugin mech_sriov config opts to be in
neutron/conf/plugins/ml2/drivers/mech_sriov so that all the
configuration options for mech_sriov reside in a centralized
location. This simplifies the process of looking up the mech_sriov
config opts and provides an easy way to import.
Change-Id: I64b243f91f2e637279456b3b06c2998cd89dc076
Partial-Bug: #1563069
Though oslo.config should not care about the case, it seems like
oslo-config-generator creates two separate sections with different case
if both are included.
Related-Bug: #1643944
Change-Id: I2f8a737d3c027d57a8a16e80838142a78dbd315d
Takashi Kajinami