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.
With the unit test framework, we define special methods, like setUp()
and test_*(). This is documented, but not obvious.
Previously, TestNmClient was the base class for our tests classes, and
it provided some functionality (and state). It was utterly confusing how
pieces fit together.
Instead, move the state to a new class NMTestContext(). That contains
most of the code from TestNmClient. Drop TestNmClient and let the test
classes directly descend from unittest.TestCase.
The difference is, when you now look at a certain test (test_001()), you
can easier understand which code runs when. First, the test class has a
setUp() method which runs, but that method is now trivial without extra
context. Second, there is the @nm_test attribute that wraps the
function. But that's it. It's all at one place, and we delegate instead
of inherit.
