The idea is to create a pair of VLAN and MACVLAN with AddAndActivate if
they are not present, and otherwise follow the ordinary (GetApplied &
Reapply) procedure if the devices are already present.
It attempts to modify attributes clearly belong to TestNmcli such as
_skip_test_for_l10n_diff or call methods that are in unittest.TestCase:
======================================================================
ERROR: test_002 (__main__.TestNmcli.test_002)
----------------------------------------------------------------------
Traceback (most recent call last):
File ".../src/tests/client/test-client.py", line 1508, in f
self.ctx.run_post()
~~~~~~~~~~~~~~~~~^^
File ".../src/tests/client/test-client.py", line 1185, in run_post
self.fail(
^^^^^^^^^
AttributeError: 'NMTestContext' object has no attribute 'fail'
It has presumably been moved out of TestNmcli at some point, but that
seems to have been in error, as it's also pretty specific to the nmcli
test cases. Not useful for cloud-init tests that also utilize
NMTestContext. Move it back.
This message is useless for non-interactive use and clobbers over
otherwise very appealing test output.
The callers knows what we're going to listen on, it passed us the file
descriptor.
Right now, on any baremetal only max. 2 physical NICs are available.
This might change in the future, so better to directly accept larger
nicIndex if we receive it. No behaviour change with this, just remove
an artificial limit.
.get_config_data is only alive while the get_config task is running. We
can't reach into it afterwards.
==92303== Invalid read of size 8
==92303== at 0x41247D: _iface_data_free (nmcs-provider.c:228)
==92303== by 0x4CB33C1: ??? (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CB8082: g_hash_table_unref (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x412425: nm_g_hash_table_unref (nm-shared-utils.h:2171)
==92303== by 0x412425: nmcs_provider_get_config_result_free (nmcs-provider.c:133)
==92303== by 0x407871: main (main.c:995)
==92303== Address 0x63b63f8 is 8 bytes inside a block of size 64 free'd
==92303== at 0x4847B4C: free (vg_replace_malloc.c:989)
==92303== by 0x4CCB76C: g_free (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CE81DF: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x411C7B: _get_config_done_cb (nmcs-provider-oci.c:247)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x4AF268A: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x40A91C: _poll_req_done_cb (nm-http-client.c:529)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x4AF268A: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== by 0x415381: _poll_return (nm-shared-utils.c:7174)
==92303== by 0x416D97: _poll_done_cb (nm-shared-utils.c:7201)
==92303== by 0x4AF2489: ??? (in /usr/lib64/libgio-2.0.so.0.6800.4)
==92303== Block was alloc'd at
==92303== at 0x484482F: malloc (vg_replace_malloc.c:446)
==92303== by 0x4CCEB88: g_malloc (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x4CE8C64: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.6800.4)
==92303== by 0x413113: nmcs_provider_get_config (nmcs-provider.c:304)
==92303== by 0x4076BD: _get_config (main.c:359)
==92303== by 0x4076BD: main (main.c:985)
There is no need to avoid including the full header, they are small
headers with some GLib type system stuff and no more. Just include them
where they are needed.
If the connection didn't exist in advance, there's no unrealized device,
and find_device_by_iface() is not going to get us one.
Call system_create_virtual_device() afrer nm_utils_complete_generic()
completes the connection for virtual devices. Make sure we do proper
cleanup if we happen to fail the activation later, so that de device
doesn't end up hanging there.
Make validate_activation_request() only do the validation -- split the
determination of the device into find_device_for_activation().
The point of this is to be able complete the connection and actually
create a virtual device after the validation.
I believe this is also somewhat easier to follow now that the procedure
does what its name says.
The point is to get rid of device/connection type specific arguments, to
eventually be able to complete the connection on AddAndActivate before knowing
which factory is going to take care of creating the device.
Aside from that, the whole thing is pretty awful -- with complicated
macros and variadic argument (ugh). Let's get rid of that.
All of these are wrong asserting that a connection has a particular
setting. On AddAndActivate, the connection can be pretty much empty:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent () <====== *shriek*
nm_device_factory_get_connection_iface ()
find_device_by_iface (iface)
nm_device_complete_connection ()
Remove those assertions.
Some of them are wrong: they assert a connection has a particular
setting even though this can be called on AddAndActivate against a
connection that is not complete or normalized:
impl_manager_add_and_activate_connection ()
validate_activation_request ()
nm_manager_get_best_device_for_connection ()
iface = nm_manager_get_connection_iface ()
find_parent_device_for_connection ()
nm_device_factory_get_connection_parent ()
nm_device_factory_get_connection_iface () <====== here
find_device_by_iface (iface)
nm_device_complete_connection ()
Fix those by removing the assertions.
Some of them are also fall back to just calling
nm_connection_get_interface_name() which is a pretty useless thing to do
because nm_device_factory_get_connection_iface() only calls the
device-specific routine if nm_device_factory_get_connection_iface()
doesn't return anything, to give the factory a chance to make up a name
(like <parent>.<vlan-id> for Vlan) on its own. Drop those.
Old branches tend to be formatted with a different versions of
clang-format, so when patches are backported, they introduce some
differences in formatting, making the check-tree job to fail.
These changes in formatting are normally small, and we don't pay much
attention to them, causing that the pipelines are always red, increasing
the work required to check if there are important failures or not.
Make check-tree optional for branches other than main. This way,
failures will be shown as a "warning", and if a pipeline only shows a
warning we don't need to inspect it.
Previously, the coverity scheduled job seemed to fail
randomly because the image that it expected to use was
not available, due to not depending on the "prep" job.
This commit resolves the problem by making sure
the image is always built when coverity runs.
The current approach is flawed. During a commit of the L3
configuration we do a RTM_GETROUTE to find the next-hop to the DNS
server on the current interface, in order to create the DNS route to
inject into the l3cd. However, we haven't added routes to kernel yet
and so the result of the RTM_GETROUTE is going to be wrong.
In some cases, for example when IPv4 DAD is enabled, the bug can't be
easily noticed because we perform multiple commits for the interface,
and the regular routes are already set in kernel from the 2nd commit
on.
To fix the problem, do the following: during a commit we first add
addresses and routes to platform. Then, we create a list of DNS routes
to configure, we collect the old DNS routes, and do a comparison. If
they changed, we need to add the DNS routes to platform in a 2nd step.
Note that in the previous approach we tracked the routes in the
committed-l3cd object of the l3cfg, and so they were applied to kernel
automatically. Because of the 2-step requirement, that no longer works
and we must apply the DNS routes manually.
Fixes: 5449b18a94 ('core: support automatically adding DNS routes')
Don't try to add the routing rule that points to the table containing
DNS routes at every commit.
Instead, look into the platform cache to see if the rule already
exists and add it only when needed.
Using `n_dhcp4_c_connection_start_request()` will cause staying in
`connection->request`, as a result, it will cause the resending of
DHCPRELEASE and DHCPDECLINE message, thus, use
`n_dhcp4_c_connection_send_request()` directly instead to avoid
unnecessary retransmission timeout, as suggested by
f030927a54 (r1531834009).
We should not send the DHCP release message when udp socket is still in
the PACKET state, this state is typically used during the discovery and
offer phases, where the client broadcasts DHCP packets like DHCPDISCOVER
and receives responses like DHCPOFFER. At this point, the client has no
lease because it has not yet completed the DHCP handshake.
In the scenario for sending the release message, we need to guarantee
that NM only sends the release message when the client received a lease
from the server. However, there is some distinction between the
`l3cd_curr` and `l3cd_next` when ACD is pending, because `l3cd_curr` is
NULL but `l3cd_next` is not NULL when ACD is pending. Regardless of
whether ACD is pending or completed, these are all considered the client
have received the release from the server. Therefore, adapt the function
`nm_dhcp_client_get_lease()` to control whether to get next or current
lease.
Now "fedpkg prep" command is generating a directory with the "-build"
suffix containing the build directory inside. We need to extract it.
Real example:
If the script is used for a branch related to nm-1-46, the "fedpkg prep"
command will generate a NetworkManager-1.46-build/ directory containing
the NetworkManager-1.46/ sources directory. We just need to move the
NetworkManager-1.46/ out.
