GitLab

Tailored to fit both nmcli and keyfile needs.

The actions are not too useful my themselves, but it will be possible to
embed them into traffic filters in subsequent commits.

What works:

  nmcli c add con-name dum0 ifname dum0 type dummy \
      tc.qdiscs 'ingress, root pfifo_fast'
  nmcli c modify dum0 -tc.qdiscs 'root pfifo_fast'
  nmcli c modify dum0 +tc.qdiscs 'root handle 666: fq_codel'

The format for qdiscs is

  qdisc.<parent>=[handle <handle>] <qdisc> [<options>...]

E.g.:

  [tc]
  qdisc.root=fq_codel handle de4d:
  qdisc.ffff:fff1=ingress

That is pretty much what is supported at this point.

...so that we have an excuse when it breaks.

Tailored to fit both nmcli and keyfile needs.

Currently is only able to hold the queueing disciplines.

Just the most rudimentary tests.

We're going to need that one for TC filter & action support.

<linux/tc_act/tc_defact.h> was moved to user-space API only in 2013
by commit 5bc3db5c9ca8407f52918b6504d3b27230defedc. Our travis CI currently
fails to build due to that.

Re-implement the header.

It only makes sense to call delete() with NMPObjects that
we obtained from the platform cache. Otherwise, if we didn't
get it from the cache in the first place, we wouldn't know
what to delete.

Hence, the input argument is (almost) always an NMPObject
in the first place. That is different from add(), where
we might create a new specific NMPlatform* instance on the
stack. For add() it makes slightly more sense to have different
functions depending on the type. For delete(), it doesn't.

Will be useful for tc qdiscs.

It's going to be useful for other objects that have a type (of course)
and an ifindex.

"no_value" indicates that the the attribute is a single word, not a
key=value pair. If the type is BOOLEAN then the attribute is considered
true, if it's a STRING then the key is used instead of a value.

"consumes_rest" indicates that the particular key takes the unparseable
tail of the string for a value.

This allows parsing tc-style strings. Consider this filter:

              ,------ regular key/value pair
       ,-----'----.
  root handle 1234: matchall action simple foo bar baz
    |                  |     `-----------.-----------'
    |                  |                 `- "", STRING, consumes_rest
    |                  `------------------- "kind", STRING, no_value
    `-------------------------------------- "root', BOOLEAN, no_value

Allows doing a nm_utils_parse_variant_attributes(..., ' ', ' ').

Perhaps a cargo cult leftover.

Fixes: c3dd5d8d

Make use of NMUtilsNamedValue in nm_utils_format_variant_attributes().
This avoids creating a GList and sorting it.

Also, reuse nm_utils_named_values_from_str_dict() in
nm_setting_bond_get_option().

NMUtilsNamedValue's purpose is precisely to create
a list and sort by entires.

Add nm_utils_named_values_from_str_dict() as helper
function to do that.

The num/i variables are initialized from libnm API and used
back at them. The integer types should match.

The team API was backported to nm-1-10 branch.
It will be released both as 1.12.0 and 1.10.2.

To ensure the upgrade path from 1.10.2+ to 1.12+ works, the symbols
in libnm must be present on both versions.

Usually, we would duplicate the symbols on master via
NM_BACKPORT_SYMBOL() macro.

However, as we are sure that we will release 1.10.2 before 1.12.0,
we can just update the linker version of these symbols. So, although
the symbols will be first released on major release 1.12.0, their linker
version tag is libnm_1_10_2, to ease upgrade and to avoid duplicating the
symbols.

Fixes: cb9facdf

Also, don't add the CFLAGS for libjansson to dflt_cppflags_libnm_core.
dflt_cppflags_libnm_core is used also by core and libnm. But those
components do not (directly) link against libjansson. The cannot use
these flags.

I don't think we should do this.

- renamining/dropping configure options is still an annoyance,
  because it requires to different ./configure options depending
  on the version. The rename from --enable-teamctl to --enable-team
  might be theoretically nice, but more annoying then helpful.

- There is no strict dependency between --enable-team and
  --enable-json-validation. At most, one could argue that
  when enabling the team plugin (--enable-teamctl), then
  libnm must also be build with --enable-json-validation.
  But in fact, the team plugin will happily work with a
  libnm that doesn't link against libjansson.
  That is --enable-teamctl --disable-json-validation will work
  in practice just fine.
  On the other hand, libnm is a client library to create connection
  profiles, fully supporting team profiles also makes sense if the
  actual plugin is not installed (or build). Thus, --disable-teamctl
  --enable-json-validation certainly makes sense.

At this point, one might ask whether libnm is even still complete without
libjansson. Maybe libnm should *require* --enable-json-validation.
But that is not what the patch was doing, and it would also need
some careful consideration before doing so.

This reverts commit 9d5cd7ea.

Although removed, they show up whenever switching to an
old branch. Keep ignoring them.

We don't properly coordinate reading the team properties from keyfile.
They must be ignored, at least for now.

https://bugzilla.redhat.com/show_bug.cgi?id=1398925

Rename the team functionality enablement from 'teamdctl' to 'team'.
Force jansson lib requirement for team functionality: NetworkManager
requires the teamd daemon to manage team. As teamd depends upon jansson
lib, adding jansson requirement for teaming support in NetworkManager
seems reasonable.
Remove the jansson_validation flag, as the only generic json function in
nmcli (not related to team) was the one to check if a string was in json
format. Anyway, that function is used for team checks only. So, move
also json validation functions under the WITH_TEAM flag.