The user can set "$NMTST_LIBTOOL" to empty or the path to libtool.
If unset, we want to detect it. However, previously we would always
use "$SCRIPT_PATH/../libtool", even if that file doesn't exit. Improve
that.
For example, when running on Ubuntu with the ".gitlab-ci/debian-install.sh"
script, we don't have libtool. Entering such a container and running the
"run-nm-test.sh" script will fail as "$SCRIPT_PATH/../libtool" doesn't
exist.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1800
- If ".git/nm-in-container-host" exists, bind mount all of "/" to
"/Host".
- also honor all ".git/nm-data-link-*" files for additional
directories to bind mount.
- as before, honor ".git/NetworkManager-ci" symlink.
Note that directories also get symlinked from "/". Like
"/NetworkManager-ci" which symlinks links to the bind mount location.
Gtkdoc comments are used, among other things, to generate the various
nm-setting-* manual pages. When a constant is referenced in a gtkdoc
comment (i.e. `%NM_IP_TUNNEL_MODE_IPIP`) it is expanded to show the C name
and the value (i.e. `NM_IP_TUNNEL_MODE_IPIP (1)`). To generate the
nm-setting-* manual pages, we don't use gtkdoc, but we process this data
with the custom script tools/generate-docs-nm-settings-docs-gir.py.
This script was expanding the constants in the same way than gtkdoc.
Showing the constants in that way in nm-setting-* manual pages makes
little sense, because users are not going to use the C identifiers.
Let's show them with a more appropriate format.
Additionally, the different nm-setting-* pages might require different
formats than the other. For example, for nm-setting-nmcli a format like
`"ipip" (1)` is prefered, but for nm-setting-dbus it's better
`1 (ipip)`. Let's generate different nm-settings-docs-gir-*.xml files for
nmcli, dbus, keyfile and ifcfg-rh, using the right format for each one.
In some cases, properties documentation might require to provide an
explanation of each of the possible values that the property accepts.
If the possible values are the variants of an enum, we can use the
introspection data to get all the possible values for that enum and
their descriptions. With that info, we can automatically generate the
documentation with an always up to date list of accepted values.
Add a new "expand enumvals" feature: it will convert a token with the
format `#EnumName:*` to a list of all the possible values. For the
docbook (description-docbook field in the XML), it is expanded to a
bulleted list of all the values and their respective documentations.
This feature is limited to the "property-infos" comments (those like
---nmcli---, ---dbus---, etc). This comments are used only to generate
the nm-settings-* manual pages. For the documentation under the doc/
folder this is not needed: it's not supported by gtkdoc and, anyway,
it's better to use just `#EnumName` that will generate an HTML link.
Additionally, expansion of `%ENUM_VALUE` is now supported in the
property-infos comments. Instead of expanding them in the same style
than gtkdoc "ENUM_VALUE (num)", it is expanded in a format more suitable
for the nm-setting-* manual pages:
- for nmcli: value_nick (num)
- others: num (value_nick)
Also, fix typo in meson build file propery -> property.
If there are properties that accept special values apart from the
normally accepted values, or any of those values has an special meaning,
it can be shown as "Special value", indicating the nicknames and numbers
that can be used to select it.
Show a new field called "Valid values" in those properties that only
accept a limited set of values, like enums, ints with a valid range of
values, etc.
As there is some complex logic behind getting this information, this
logic has been put in nm-meta-setting-desc and nm-enum-utils so they can
be re-used, avoiding duplicity and errors. Some refactor has been done
in nm-meta-setting-desc in this direction, too.
Message of the day was shown twice because the same bashrc.my file than
for containers was used. That file contained some code to show motd in
the container, where it is not shown by default. But in the VM, the motd
is shown by default, so it was shown twice.
Move the code to show motd to a file used only by nm-in-container and
not by nm-in-vm.
Also, modify the explanation about using prepare-for-system.sh because
it's only valid for Fedora but nm-in-vm can be used with other SOs too.
The $VM name is used also as hostname in the guest so ssh connection can
be made to root@$VM. However, valid hostnames can only contain letters,
numbers and '-'. If other characters are used, they are removed from the
hostname so you cannot connect to root@$VM. Fix it by not allowing
invalid hostnames in $VM at VM creation.
Also, fix some incorrect bash regexes.
Install missing repositories required to install all the packages.
Unluckily, it doesn't support 9P filesystem shares, and virtiofs is not
supported for non-root hosts. Emit a warning about that.
Images of qcow2 format dynamically grow up to the maximum size that they
have been configured at creation time. Because of this, higher size can
be selected without wasting unnecesary space in the host. Rise image
size to 20G.
Also, allow to set an empty value to IMAGE_SIZE, and don't resize in
that case. This is useful because virt-resize fails with some guest
partition layouts (like with ubuntu-20.04).
Using more than one VM can be a quite common use case. Insteado of
having to do VM=vm_name ./nm-in-vm, allow the more common way of passing
options ./nm-in-vm --vm vm_name.
Also, in build command, accept one positional argument to set OS_VERSION.
The connectivity with the host depends on getting a DHCP lease from the
host. With the latest commit's customizations, the virtual NIC is not
managed by NM so it is not configured.
Keep it unmanaged so debuging NetworkManager doesn't affect to this
virtual NIC. Use dhclient to get a DHCP lease from the host. Assign a
fixed interface name (host_net) to match it from NM and dhclient config
files.
The script was generating the data-* files that later copies to the
container.
In order to the files being reusable for nm-in-vm, put them as separate
files inside the data directory.
However, some of the files need the full path to NetworkManager project,
which varies for each user. Instead, make a sed replacement on them and
generate the actual files that will be copied. Replacement:
{{BASEDIR_NM}} -> $BASEDIR_NM
Also, rename the files to more descriptive names, using some prefixes
that give a hint of where those files will be put, and the .in extension
to indicate that they will be processed.
nm-in-vm can use the same generated files than nm-in-container, so let's
move them to a place common for both: tools/nm-guest-data.
With this change, it is not worth it to have the nm-in-container
directory, so move the script to tools and delete the subdirectory.
Script to download, configure and install a virtual machine to build and
test NetworkManager. This is useful because there are some things that
doesn't work properly on containers so a VM is needed to test.
It works almost the same way than nm-in-container.
Configurations specific to NetworkManager such as installing the required
packages are not implemented yet.
When updating NetworkManager to a new version, normally the service is
not restarted by the installer to avoid interrupting networking.
However, next nmcli invocation will use the updated version, but against
the older version of the daemon that is still running. Although this is
suposed to work, it is advisable that nmcli and daemon's versions are
the same. Emit a warning recommending restarting the daemon.
Add nmcli test to check the new feature. To avoid breaking the existing
tests, test-networkmanager-service now reports the same version than the
running nmcli except if it's instructed to report a different one.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1703
network-online.target should not be reached before nm-cloud-setup
completes configuring the network, which may make user service get
started before the network is fully configured.
Setting nm-cloud-setup.service as "Before=network-online.target" would
maybe have already achieved that. However, also use a pre-up dispatcher
script, so that the device activation in NetworkManager is also waiting
for nm-cloud-setup to complete.
https://bugzilla.redhat.com/show_bug.cgi?id=2151040https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1653
Seen in NM 1.42.6 where there is now a ipv4.dns-data key which
have as signature:
dbus.Array([dbus.String('a.b.c.d')], signature=dbus.Signature('s'), variant_level=1)
This lead to the following exception:
Cannot convert array element to type 's': Must be string, not Variant
Moreover, the exception TypeError has no message field so it raised
another expcetion which gave me trouble to find what's going on.
Hence the addition of a log file from the previous commit
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
"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>.
This reworks the cloud metadata mock server in a significant way.
Most importantly this makes it possible for the client to add and
modify the resources for later retrieval using the PUT method.
This allows the test to create the fixture for itself.
The default set of resources is still provided, so that the too remains
useful as a development aid. If that is not desirable, the --empty
parameter might be passed to cause the server to start with no
resources.
