Historically, initscripts' ifup-ib would set the highest bit of
PKEY_ID=. That changed and needs to be restored.
Note that it probably makes little sense to ever configure p-keys
without the highest bit set, because that flag indicates full membership
and kernel will automatically add it. At least, kernel will add the flag
for the p-key, but not for the automatically chosen interface name.
Meaning, writing 0x00f0 to create_child sysctl, results in an interface
"$parent.00f0", but `ip -d link` shows pkey 0x80f0.
As NetworkManager otherwise supports p-keys without the highest bit set,
and since that high bit is honored for the interface name, we cannot
just always add the high bit. NetworkManager always assuming the highest
bit is set, would change the interface names of existing configuration.
With this revert, when a user configures a small p-key and the profile
is stored in ifcfg-rh format, the settings backend will automatically
mangle the profile and set 0x8000. That is different from when the
profile is stored in keyfile format. Since using small p-keys is
probably an odd case, we don't try to workaround that any other way
(like that ifcfg format could represent the orignal value of the profile
and not doing such mangling, or to add the high bit throughout
NetworkManager to the p-key). It's an inconsistency, but given the
existing behaviors it seems best to stick (revert) to it.
This reverts commit a4fe16a426.
Affected versions were 1.42.2+ and 1.40.2+.
See-also: 05333c3602/f/rdma.ifup-ib (_75)https://bugzilla.redhat.com/show_bug.cgi?id=2209164
When a fixed address is assigned by the P2P group owner, then the code
would set the IPv4 configuration method to DISABLED internally. However,
this causes issues, because it means that IPv4 is considered to not have
come up internally which can cause the connection to later time out even
though it was configured properly.
As such, map this method to MANUAL in this case. The AUTO mapping
becomes then:
* MANUAL: If the remote part is the GO and assigned an IP address
* DHCP: If the remote part is the GO and did not assign an address
* SHARED: If we are the GO
This fixes an issue where the connection established by GNOME Network
Displays would fail once IPv6 configuration also times out.
See-also: https://gitlab.gnome.org/GNOME/gnome-network-displays/-/issues/279https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1636
It's obviously a change in behavior. Now accept backslash for escaping
the whitespace+comma separators when setting "connection.secondaries".
Before:
$ nmcli --offline connection add type ethernet con-name x connection.secondaries 'a b'
Error: failed to modify connection.secondaries: the value 'a' is not a valid UUID.
$ nmcli --offline connection add type ethernet con-name x connection.secondaries 'a\ b'
Error: failed to modify connection.secondaries: the value 'a\' is not a valid UUID.
After:
$ nmcli --offline connection add type ethernet con-name x connection.secondaries 'a\ b'
Error: failed to modify connection.secondaries: the value 'a b' is not a valid UUID.
https://bugzilla.redhat.com/show_bug.cgi?id=2177209
Otherwise, the logging output is confusing as it's not clear what happened about
the provider detection.
Also, don't return from _provider_detect() unless all pending callbacks
returned. It is ugly to leave callbacks pending, because they will be
later dispatched when the caller iterates the GMainContext further.
Instead, cancel pending operations bug keep running until we processed
all cancellation callbacks.
In production systems, the associate an interface by their permanate MAC address.
For testing and CI, we may want to hook that. That allows for example to run
nm-cloud-setup on a veth interface, which doesn't have a permanent MAC address.
This is only for testing.
Previously, there was NMCS_ENV_VARIABLE() macro. That macro did nothing,
it merely acted as something to grep for, when searching the source for
which environment variables nm-cloud-setup honors. That is an
interesting thing to know, because nm-cloud-setup is configured via
environment variables.
Change that. Instead add a define for each environment variable. You can
now instead grep for "NMCS_ENV_" to find them all.
"test-cloud-meta-mock.py" needs to be mocked, so it only replies
to stuff that we tell it to. Except for the API token, that is
pushed by the client.
We need to be able to tell the mock whether it supports that API
or not. By default it does, but by setting "/.nmtest/providers"
we can limit that.
The DEFAULT_RESOURCE are now grouped by provider. If a path is not
explicitly mocked, we may fallback to the DEFAULT_RESOURCE, but only if
the respective "/.nmtest/providers" is enabled and if /.nmtest/allow-default"
indicates so (which they do by default).
"generate-docs-nm-settings-docs-merge.py" merges properties from
multiple XMLs. It supported an argument "--only-from-first", to
only select properties that were in the first of the provided XMLs.
The idea is that the first XML would be "src/nmcli/gen-metadata-nm-settings-nmcli.xml"
which is generated from nmcli meta-data and exactly describes the
supported properties. For example, "connection.read-only", "user.data"
or "wireless.tx-power" exist as properties somewhere, but not supported
by nmcli.
Change that, to not tie the selected property to the first XML.
"gen-metadata-nm-settings-nmcli.xml" is the XML that contains which
properties to select from, but "src/libnm-client-impl/nm-property-infos-nmcli.xml"
contains hand crafted descriptions. The latter descriptions are
preferred. As the order of the XML is already relevant for which
description is preferred, the selection is orthogonal to that.
With this, prefer descriptions from "src/libnm-client-impl/nm-property-infos-nmcli.xml"
but still select properties from "src/nmcli/gen-metadata-nm-settings-nmcli.xml".
Note that the argument is only used to generate "man/nm-settings-docs-nmcli.xml",
and with the current input, there is no actual change in behavior.
When we generate the manual page for nm-settings-nmcli, we run:
"/usr/bin/python" \
./tools/generate-docs-nm-settings-docs-merge.py \
--only-from-first \
man/nm-settings-docs-nmcli.xml \
src/nmcli/gen-metadata-nm-settings-nmcli.xml \
src/libnm-client-impl/nm-property-infos-nmcli.xml \
src/libnm-client-impl/nm-settings-docs-gir.xml
If "gen-metadata-nm-settings-nmcli.xml" contains either a <description>
or a <description-docbook>, then we must not continue searching the
other XML documents. The user provided an explicit override, and
fallback (search further) is wrong. Previously, we might take
<description> from the first file, and <description-docbook> from the
second file. As "man/nm-settings-nmcli.xsl" prefers
<description-docbook>, it takes the wrong text. Instead, as we search
the files during merge, we must prefer the first one.
Note that the change doesn't really matter anymore, because each XML
now must also contain both <description> and <description-docbook>.
There is an assertion for that.
Also, stop generating <deprecated-docbook>. First, it lacked the
important "since=" attribute and was necessary. Also, it's redundant and
does not contain anything interesting. So far, we don't need special
formatting for the deprecated message, and we likely never will.
Also, stop accepting or generating the "description=" attribute. This
should always be an XML element now.
The "generate-docs-nm-property-infos.py" script parses the tags like
"---nmcli---" and generates an XML.
Rework it:
- don't put long text descriptions in a "description=" XML attribute.
Instead, use an XML element. That is in line with what
"generate-docs-nm-settings-docs-gir.py" does, which generates
a similar file.
- if there is no <description-docbook> element, generate one based
on <description>. That is important, because we want to create
paragraphs.
It's also important because "generate-docs-nm-settings-docs-gir.py"
tends to generate <description-docbook> from the libnm/gir data.
However, if you specify a "---nmcli---" override, then that should
automatically apply to <description> and <description-docbook>.
"gen-metadata-nm-settings-nmcli" previously printed the <description>.
But that tag is not very useful for further processing.
For the most part it itself comes from "src/libnmc-setting/settings-docs.h",
which is generated (but lost formatting information already to be
suitable for where it's used).
Some parts are original texts from "src/libnmc-setting/nm-meta-setting-desc.c",
like TEAM_DESCRIBE_MESSAGE. However those text are also not really suitable
for any other purpose.
Rename the tag, so that the tools that process "gen-metadata-nm-settings-nmcli.xml"
don't use it.
The file "gen-metadata-nm-settings-nmcli.xml" is currently only used to
generate "man/nm-settings-docs-nmcli.xml", and that file slightly
changes with this patch. However, the manual page which is generated by
"man/nm-settings-docs-nmcli.xml" does not change.
The input always actually has a <description-docbook> field, so the secret-flags
hint was never shown.
Move it. It's indepenent from <description> and <description-docbook> anyway.
With this we see the expected messages
See the section called “Secret flag types:” for flag values.
If we have an override with "description-docbook:", we soon will require that
there is also an accompanying "description:", for plain uses.
The text is copied from what otherwise gets merged (it comes from the gir file).
We want to follow current Fedora, so update to Fedora 38.
Also, we now use clang-format from Fedora 38 release, so the default
image in gitlab-ci must match, because that image is used for the
"check-tree" test.
While at it, add Fedora 39 and move Fedora 36 to tier 3.
Originally, the package was called vala-devel (it still is on CentOS7).
Then it was renamed to libvala-devel, but keeping a Provides.
On Fedora 39, the Provides was dropped. Workaround.
This is the version shipped in Fedora 38. As Fedora 38 is now out, the
core developers switch to it. Our gitlab-ci will also use that as base
image for the check-{patch.tree} tests and to generate the pages. There
is a need that everybody agrees on which clang-format version to use,
and that version should be the one of the currently used Fedora release.
Also update the used Fedora image in "contrib/scripts/nm-code-format-container.sh"
script.
The gitlab-ci still needs update in the following commit. This change
in isolation will break the "check-tree" test.
That is also what autotools does. Keep the behvior in sync.
Also, "contrib/scripts/nm-ci-run.sh" does not explicitly enable
nm-cloud-setup, so we ended up not building it in test. This
solves that, by enabling it by default.
In constructed(), NMDevice starts watching the D-Bus name owner or
monitoring the unix socket, and so it is always aware if teamd is
running. When it is, NMDevice connects to it and initializes
priv->tdc.
It is not useful to try to connect to teamd in update_connection()
because warnings will be generated by NM and by libteam if teamd is
not running. As explained above the connection is always initialized
when teamd is available, and so we can just check priv->tdc.
Fixes: ab586236e3 ('core: implement update_connection() for Team')
https://bugzilla.redhat.com/show_bug.cgi?id=2182029https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1631
This ABI was backported all the way to 1.42.8 and 1.40.20 and to rhel-8.9.
Move the ABI to a separate symbol version, which we have in all those
versions.
