Remove B303 (md5, sha1 for python<3.9) and
remove B311 (Standard pseudo-random generators are
not suitable for security/cryptographic purpose) from
the skip list of bandit execution.
Change-Id: I6e9e61e7f94dc9ca339942529af8997adef45e38
If the Nova metadata service is unavailable, the requests.request()
function may raise a ConnectionError. This results in the upper code
returning a 500 HTTP status code to the user along with a traceback.
Let's handle this scenario and instead return a 503 HTTP status code
(service unavailable).
If the Nova service is down and is behind another proxy (such as
Nginx), then instead of a ConnectionError, the request may result in
receiving a 502 or 503 HTTP status code. Let's also consider this
situation and add support for an additional 504 code.
Closes-Bug: #2059032
Change-Id: I16be18c46a6796224b0793dc385b0ddec01739c4
Previously, the code used to clean up old DHCP processes for a network
before creating new ones supporting multiple segments per network
could potentially not be executed first. Since disabling applies to
cleaning the namespace, this could have led to the network setup being
destroyed after being done.
This change moves the part that cleans up the old DHCP setup to ensure
it is executed first.
Closes-bug: #2049615
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Iecdb2d81ee077c9b9057d0708c5c88e159970039
This change enhances the IptablesFirewallDriver with support for remote
address groups. Previously, this feature was only available in the
OVSFirewallDriver. This commit harmonizes the capabilities across both
firewall drivers, and by inheritance also to OVSHybridIptablesFirewallDriver.
Background -
The Neutron API allows operators to configure remote address groups [1],
however the OVSHybridIptablesFirewallDriver and IptablesFirewallDriver do
not implement these remote group restrictions. When configuring security
group rules with remote address groups, connections get enabled
based on other rule parameters, ignoring the configured remote address
group restrictions.
This behaviour undocumented, and may lead to more-open-than-configured network
access.
Closes-Bug: #2058138
Change-Id: I76b3cb46ee603fa5e829537af41316bb42a6f30f
Change Id62bf18067d0b144c3e8825c7603cc1e51dca052 removes explicit
PID files clean up for keepalived and brings regression as
there is no 'process enable' for VRRP.
Always delete stale PID file if exists
Related-Bug: 1561046
Change-Id: I95a004a3acbe6a9160a19053a37fc0dd2b1875a5
iptables-save uses a system-dependent value, usually that
found in /etc/protocols, when 'ipip' is given as the
security group protocol. The intent is to always use the
string value for IP protocol '4', as iptables-save has no
'-n' flag to print values numerically.
This updates a previous change (793dfb04d) that hard-coded
that string to 'ipencap', which broke CentOS/Fedora, which
uses 'ipv4'.
For this reason we cannot hard-code anything in neutron-lib,
this needs to be added dynamically, so this one-line change
needs to stay here, and effectively closes the bug.
Closes-bug: #2054324
Change-Id: Ic40b539c9ef5cfa4cbbd6575e19e653342e8342b
This patch is implementing the OVN agent metadata extension, by reusing
the OVN metadata class. The class ``MetadataAgent`` is inherited in the
``MetadataExtension`` class. The goal is to use the same code in both
implementations (until the OVN metadata agent is deprecated).
The OVN agent metadata extension has a different initialization
process. The OVN and OVS IDL connections are created during the
extension initialization but are not accessible. The ``start`` method
is used to load the configuration, execute the sync process and
register the metadata extension.
This extension will replace the need of the OVN metadata agent. The
deprecation of this agent will imply the refactor of the existing code
that now is shared between both agents.
This new OVN agent will be tested in the "neutron-tempest-plugin-ovn"
CI job, after the change done in the following patch.
Needed-By: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/909860
Partial-Bug: #2017871
Change-Id: I4381a67648a9b6198a8d936db784964d74dc87a1
Map 'ipip' to use the string 'ipencap' so the
IptablesFirewallDriver class in neutron works correctly.
Once neutron-lib is bumped this can be removed.
Add tests for IP protocol 'ipip', '4' and '94' to make
sure the IptablesFirewallDriver class in neutron treats
them correctly.
Long description below.
This is one of those confusing edge cases and I think
Linux is conspiring against us. Let me explain.
1) neutron-lib does correctly define the protocol name 'ipip' as 4.
2) The linux kernel uses the same in in.h:
IPPROTO_IPIP = 4
IPPROTO_BEETPH = 94 (?)
3) iptables maps 'ipip' to 94 and 'ipencap' to 4.
# for num in {0..255}; do iptables -A INPUT -p $num; done
# iptables-save | grep -E 'ipip|ipencap'
-A INPUT -p ipencap
-A INPUT -p ipip
4) /etc/protocols does the same as iptables:
grep -E 'ipencap|ipip' /etc/protocols
ipencap 4 IP-ENCAP # IP encapsulated in IP (officially ``IP'')
ipip 94 IPIP # IP-within-IP Encapsulation Protocol
5) getprotoby{name|number} does what /etc/protocols does:
$ getprotobyname ipip
struct protoent: (0x7fbbbcca9c60)
p_name ipip
p_aliases IPIP
p_proto 94
$ getprotobynumber 4
struct protoent: (0x7fc51ad86be0)
p_name ipencap
p_aliases IP-ENCAP
p_proto 4
Neutron actually builds a mapping based on the getprotoby*
calls, so in the iptables case it winds-up doing the wrong
thing.
Partial-bug: #2054324
Change-Id: Icc84b54be07d39059723d6c233c03aa130102423
The ML2 and OVN metadata agents have almost identical
code, as the former was copied to the latter and modified.
Instead, combine all the common parts and just have
each do any driver-specific operations separately.
Change-Id: Iff8bc8de16a8afc7c0195bf301d1b0643e17d7c6
The VETH pair between the metadata namespace and the local OVS now
has the same MTU as the network associated to this metadata service.
The "LSP.external_ids" field has a new key defined: "neutron:mtu".
This is the value of the network MTU.
This patch does not update the previous metadata datapaths nor the
existing LSP. This change will affect only to new created ports
and the corresponding metadata datapaths.
Closes-Bug: #2053274
Change-Id: I7ff300e9634e5e3fc68d70540392109fd8b9babc
In both neutron-metadata and neutron-ovn-metadata agents we should
ensure that haproxy service spawned for network/router is actually
active before moving on.
This patch adds that check and this is similar to what was already
implemented some time ago for the dnsmasq process spawned by the dhcp
agent.
Related-Bug: #2052787
Change-Id: Ic58640d89952fa03bd1059608ee6c9072fbaabf5
The input parameter "is_ovs_port" is no longer needed in the method
``IpLinkCommand.set_netns`` since [1].
[1]https://review.opendev.org/c/openstack/neutron/+/905836
Trivial-Fix
Change-Id: I0e36cf8afe76904997e14eca415a0e978f05c55a
This function is private. This commit also adds missing unit tests.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I6d3e75fb61a90358cf7afbe165181d3da6363bfb
Usage of the helper function which retrieves the name of the process
based on the usage of the segments was missing for unregister which
leads an issue when disabling dhcp agent for a network.
Closes-Bug: #2051690
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic6e999214210383f17c29982bf5673eea1bb55c0
All of these exceptions and constants have been in
neutron-lib for a while, start using them.
While looking for other things to consume found an old
neutron-lib TODO that did not apply anymore, so removed.
TrivialFix
Change-Id: I9431075a50ba05be872db422125e6af6266ccb99
Each OVN agent extension can implement a start method. It is called
after the extension manager initialization, at the end of the
``OVNNeutronAgent.start`` call.
Related-Bug: #2017871
Change-Id: I334027f061fa963c1cf24540b27c1ff76145b977
Now the ``OVNNeutronAgent.load_config`` method is public and accessible
by the OVN agent extensions.
This patch also makes use of the property ``ovs_idl``, that implicitly
loads the OVS IDL if it is not done previously.
Related-Bug: #2017871
Change-Id: I356c16d753b524736673a665a6590ae903be5682
If the ``IpLinkCommand.set_netns`` fails, the method restores the
previous device namespace before raising the exception.
Closes-Bug: #2049590
Change-Id: I73b36ef161441b52922d888c11a144eafe8a7ed0
This patch is the initial implementation on the suggestion
from this patch[1].
The DHCP agent can query the existing `get_ports` RPC method because
this method is already exposed in the MetadataRpcCallback(server side)
which runs under the same topic(PLUGIN) and namespace(None). The benefit
here is that there is no change needed to the API, however it does
go against how we historically setup the RPC layer between a server and client.
[1] https://review.opendev.org/c/openstack/neutron/+/903572/comments/3d4e0453_4b4d2ab6
Related-Bug: #1982569
Change-Id: Icd7c55d2a5103bdbd90907b1dbfb9ccfe34c020a
Same as in ML2/OVS, the ML2/OVN mechanism driver adds to the port
VIF details dictionary the OVS bridge the port is connected to
and the integration bridge datapath type.
Closes-Bug: #2045889
Change-Id: Ifda46c42b9506449a58fbaf312cc71c72d9cf2df
Process of cleaning stale devices is now logged at an informational
level, not just for debugging as operator should be aware of any
action on its platform. Also, the removal of stale devices which
should never occur, is marked as a warning. This change aids operators
in identifying unusual behavior on their platform.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I8f878e50983cf0664a80ff8dbdfb0b6db68b6cd3
normal network namespaces are bind-mounted to files under
/var/run/netns. If a process deleting a network namespace gets killed
during that operation there is the chance that the bind mount to the
netns has been removed, but the file under /var/run/netns still exists.
When the neutron-ovn-metadata-agent tries to clean up such network
namespaces it first tires to validate that the network namespace is
empty. For the cases described above this fails, as this network
namespace no longer really exists, but is just a stray file laying
around.
To fix this we treat network namespaces where we get an `OSError` with
errno 22 (Invalid Argument) as empty. The calls to pyroute2 to delete
the namespace will then clean up the file.
Additionally we add a guard to teardown_datapath to continue even if
this fails. failing to remove a datapath is not critical and leaves in
the worst case a process and a network namespace running, however
previously it would have also prevented the creation of new datapaths
which is critical for VM startup.
Closes-Bug: #2037102
Change-Id: I7c43812fed5903f98a2e491076c24a8d926a59b4
This is a followup patch for Iec8854749a1df81eb6a7154d3f951e176c69156d
that left some other unused code in tree. This patch attempts to remove
the remaining pieces.
Related-Bug: 2002839
Change-Id: Ie297dfba17deb79b38cf9f6eccf4f1a8e9e5060a
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Now the ``OVNAgentExtension`` class do not clear the agent API during
the extension initialization.
This patch also passes the agent object to the OVN agent extensions
as agent API. Any method required will be implemented directly on the
OVN agent class.
Closes-Bug: #2046939
Change-Id: Ia635ca1ff97c3db43a34d3dec6a7f9df154dfe28
Now the OVN agent implements a method ``__getitem__`` that retrieves,
from ``self.ext_manager``, a loaded extension by its name. The method
returns the instantiated extension object.
Closes-Bug: #2046892
Change-Id: Ibb6dc7c9150bf99639d5b6180356963998dc4e49
Zuul