| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Add per port priority support for bond active port re-selection during
failover. A higher number means a higher priority in selection. The
primary port still has the highest priority. This option is only
compatible with active-backup, balance-tlb and balance-alb modes.
|
| | |
|
| |
|
|
|
|
| |
sysfs is deprecated and kernel will not add new bond port options to
sysfs. Netlink is a stable API and therefore is the right method to
communicate with kernel in order to set the link options.
|
| |
|
|
| |
The correct variable for queue-id in ifcfg is BOND_PORT_QUEUE_ID.
|
| | |
|
| |
|
|
| |
To be consistent with other defines.
|
| |
|
|
|
|
|
|
| |
With a large number of interfaces, it can take longer than 45 seconds
before NetworkManager is started (and the D-Bus name acquired). Increase
the start timeout.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1612
|
| |
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1275
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1611
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1597
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Before commit a42682d44fe2 ('device: take reference to device object
before 'delete_on_deactivate''), we used a weak pointer to track the
idle action.
As we now use a strong reference, we can store all data about the idle
action in NMDevice itself. Drop DeleteOnDeactivateData.
|
| | |
| |
| |
| |
| |
| |
| | |
NMDevice holds a reference to NMManager, which holds a reference to NMPolicy.
It is not possible that we try to dispose NMPolicy while there are still devices
registered. That would be a bug, that we need to find and solve
differently. Add an assertion instead of trying to handle it.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add an assertion to nm_policy_device_recheck_auto_activate_schedule(),
that the device is currently registered in NMPolicy. Calling it outside
would be odd, and likely a bug.
But if we only register the auto-activate while being registered, we
don't need to take an additional reference. We know that the object must
be be alive (also, we have assertions that in fact it is still alive).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Hook the information for tracking the activation of a device, to the
NMDevice itself. Sure, that slightly couples the NMPolicy closer to
NMDevice, but the result is still simpler code because we don't need a
separate ActivateData.
It also means we can immediately tell whether the auto activation check
for NMDevice is already scheduled and don't need to search through the
list.
|
| | |
| |
| |
| |
| |
| | |
NMPolicy really should be merged into NMManager. It has not a clear responsiblity
so that there are two separate objects only makes things confusing. Anyway. It
is permissible to look up the NMPolicy instance of a NMManager. Add an accessor.
|
| | |
| |
| |
| |
| |
| | |
"nm-manager.c"
No need to call down to the device, to call back up to the NMManager.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_device_recheck_auto_activate_schedule()
It's the better name. Especially since there is no more signal involved,
the term "emit" doesn't match.
Note also how the previous approach using a signal tried to abstract
what is happening. So we were no longer rechecking-autoconnect, instead,
we were emitting-a-signal-to-recheck-autoconnect. Just be plain about
what it is doing and don't go through a layer of signal.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GObject signals don't make the code easier to understand, on the
contrary. They may have their purpose, when objects truly must/should
not be aware of each other, and need to be composed very loosely. That
is not the case here.
There really is only one subscriber to NM_DEVICE_RECHECK_AUTO_ACTIVATE
signal, and it only makes sense this way. Instead of going through a
signal invocation, just call the well known method directly. It becomes
clearer who calls this code (and it has a lower overhead).
When using cscope/ctags it also is easier to follow the code because the
tools understand function calls.
|
| | |
| |
| |
| | |
The numeric source IDs are discouraged. Use a GSource instead.
|
| | |
| |
| |
| | |
The numeric source IDs are discouraged. Use a GSource instead.
|
| | |
| |
| |
| |
| |
| |
| | |
nm_policy_device_recheck_auto_activate_all_schedule()
The "all" variant is strongly related to nm_policy_device_recheck_auto_activate_schedule().
Rename, so that the names express that better.
|
| | |
| |
| |
| | |
Let's simplify this part of the code. This is the first step.
|
| |/
|
|
|
|
|
| |
The delete_on_deactivate_link_delete() handler may be called after the
device was already removed from NMManager. Don't allow that.
Check whether the device is still exported on D-Bus as indication.
|
| |\
| |
| |
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=2152864
Fixes-test: @NM_reboot_openvswitch_vlan_configuration_var2
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1603
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NM_reboot_openvswitch_vlan_configuration_var2 test exposes a race. What
the test does, is to create OVS profiles and repeatedly restart
NetworkManager, checking that those profiles autoconnect and the OVS
configuration gets created.
There is a race, where:
- the OVS interface exists, and an NMDeviceOvsInterface is created
- first ovsdb cleans up old interfaces, sending a json request.
- OVS deletes the interface, and NetworkManager first picks up the
platform signal (there is a race here, usually the ovsdb request
completes first, which will cleanup the NMDeviceOvsInterface in
a different way).
- when the device gets unrealized, we don't schedule a
check-autoactivate, so the device stays down.
See https://bugzilla.redhat.com/show_bug.cgi?id=2152864#c5 for a log
file with more details.
What should instead happen, is to autoactivate the OVS interface, which
then also fully configures the port and bridge interfaces.
Explicitly schedule an autoactivate when unrealizing devices.
Note that there are now several cases, where NetworkManager autoconnects
more eagerly. This even affects some CI tests and user-visible behavior.
But I think relying on "just don't call nm_device_emit_recheck_auto_activate()
to hope that autoconnect doesn't happen is wrong. It must always be
possible to trigger an autoconnect check, and the right thing must
happen. We only don't trigger autoconnect checks *all* the time, because
it would be a waste of CPU resources, but whenever we slightly suspect
that an autoconnect may happen, we must be allowed to trigger a check.
If a device is in a condition where it previously did not autoconnect,
and it also *should* not autoconnect, then we need to fix the code that
evaluates whether an autoconnect may happen (not avoid triggering a
check).
https://bugzilla.redhat.com/show_bug.cgi?id=2152864
Fixes-test: @NM_reboot_openvswitch_vlan_configuration_var2
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, when we delete a device then autoconnect does not kick in
right away. But that is only, because we happen not to schedule a
"autoactivate" recheck.
What should be happen, is that rechecking whether to autoconnect is
always allowed, and that we have the necessary state to know that
autoconnect currently should not work.
Instead, block autoconnect of the involved profile. That makes sense,
because clearly we don't want to autoconnect right again after `nmcli
device delete $iface`.
|
| |/ |
|
| | |
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1610
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "connection.stable-id" supports placeholders like "${CONNECTION}" or
"${DEVICE}".
The stable-id can also be specified in global connection defaults in
NetworkManager.conf, by leaving it unset in the profile. Global
connection defaults always follow the pattern, that they correspond to a
per-profile property, and only when the per-profile value indicates a
special default/unset value, the global connection default is consulted.
Finally, if the global connection default is also not configured in
NetworkManager.conf, a built-in default is used (which may not be
constant either, for example ipv6.ip6-privacy's built-in default depends
on a sysctl value).
In any case, every possible configuration that can be achieved should be
configurable both per-profile and via global connection default. That
was not given for the stable-id, because the built-in default generated
an ID in a way that could not be explicitly expressed otherwise.
So you could not:
- explicitly set the per-profile value to the built-in default, to avoid
that the global-connection-default overwrites it.
- explicitly set the global-connection-default to the built-in default,
to avoid that a lower priority [connection*] section overwrites the
stable-id again.
Fix that inconsistency to make it possible to explicitly set the
built-in default.
Change behavior for literally "default${CONNECTION}" and make it behave
as the built-in default. Also document that the built-in default has that
value.
It's unlikely that this breaks an existing configuration, but of course,
if any user configured "connection.stable-id=default${CONNECTION}", then
the behavior changes for them.
|
| |
|
|
| |
Fixes: e6a33c04ebe1 ('all: make "ipv6.addr-gen-mode" configurable by global default')
|
| |
|
|
|
| |
In ppp 2.5.0 the "patchlevel.h" header file was removed and pkg-config
must be used. Update the detection command to support both ways.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add "BindsTo=dbus.service" to NetworkManager.service so that when the
D-Bus service gets restarted, NM is also restarted instead of staying
stopped.
https://bugzilla.redhat.com/show_bug.cgi?id=2161915
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1605
|
| | |
|
| |
|
|
|
|
| |
The actual formatting depends on the version of clang-format. Print the
used version, which is in particular interesting when we get an error in
our gitlab-ci check (which uses the correct version).
|
| |
|
|
|
|
|
|
| |
Fixes: e1648d0665a0 ('core: commit l3cd asynchronously on DHCP bound event')
Co-authored-by: Thomas Haller <thaller@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=2179537
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1609
|
| |
|
|
|
| |
It contains "getenforce" and "setenforce", which are needed by some
NMCI tests.
|
| |\
| |
| |
| |
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1272
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1558
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1607
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Using the ppp code is rather ugly.
Historically, the pppd headers don't follow a good naming convention,
and define things that cause conflicts with our headers:
/usr/include/pppd/patchlevel.h:#define VERSION "2.4.9"
/usr/include/pppd/pppd.h:typedef unsigned char bool;
Hence we had to include the pppd headers in certain order, and be
careful.
ppp 2.5 changes API and cleans that up. But since we need to support
also old versions, it does not immediately simplify anything.
Only include "pppd" headers in "nm-pppd-compat.c" and expose a wrapper
API from "nm-pppd-compat.h". The purpose is that "nm-pppd-compat.h"
exposes clean names, while all the handling of ppp is in the source
file.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change does the following
* Adding in nm-pppd-compat.h to mask details regarding different
versions of pppd.
* Fix the nm-pppd-plugin.c regarding differences in API between
2.4.9 (current) and latet pppd 2.5.0 in master branch
* Additional fixes to the configure.ac to appropriately set defines used
for compilation
|
| |/
|
|
|
|
|
| |
Ppp 2.5 adds a pkg-config file, so we can detect the version.
Use it.
[thaller@redhat.com: split out patch]
|
| |
|
|
| |
Fixes: 5d28a0dd899b ('doc: replace all (allow-none) annotations by (optional) and/or (nullable)')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The permissions for running CI will be restricted to external
contributors. It will only work for projects that use "detached MR
pipelines" ([1]).
Note that for it to actually work, a member with permission might have
to go to the "pipeline" tab of the merge request and click "run
pipeline". But this snippet is necessary for that.
[1] https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/540#what-it-means-for-me-a-maintainer-of-a-project-part-of-gitlabfreedesktoporg
|
| |\
| |
| |
| |
| |
| | |
Obsoletes: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1595
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1601
|
| | |
| |
| |
| |
| |
| |
| |
| | |
- We need to fetch more entries per page. 100 is the maximum without
pagination, but that is enough for us.
- Previously, we checked all stages. Now, let's skip the "prep" and "tier3" stages.
This change should work both with old and new pipelines.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We want that the tier2+ tests are only run manually. As those tests
depend on the respective prep step, there are 3 possibilities:
1) make prep manual and the tier test automatic. That is what we would
want, because then we can just manually trigger the prep step (one
click). However, in the past this didn't work.
2) make the prep automatic and the test manual. That works, the downside
is that we often run the prep step when its not needed. This is what
we used to do to workaround 1).
3) make prep and the test manual. Then there are no unnecessary tests
run, but triggering a manual test is cumbersome. First click to start
the prep step, then wait, then click again.
Revisit this. It seems 1) is working now. Yeay.
Also rename the prep stages, so that it's clear to which tier they
belong. I guess, I could move them instead to prep1, prep2, prep3
stages, but then there are a lot of columns on the web site.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The distro.name is not just a pretty name, its the name under which we fetch
the container. It is thus a well-known name, that we can rely on.
The "base_type" only depends on the distro name, and it makes no sense
to ever choose a different name. Tracking it in the "distributions"
array is thus redundant.
Move the mapping of distro.name to the base type to a separate place.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The tag we actually use already contains a hash of the input files and
is generated (by `ci-fairy generate-templates`). There is no need for having
this fixed prefix. As also seens by having a date there, which is maintained
badly and meaningless.
Drop it.
|
| | |
| |
| |
| |
| | |
The long name looks verbose and takes away space on the web page.
Shorten the name.
|
