1. 27 May, 2019 29 commits
  2. 25 May, 2019 1 commit
    • Tom Gundersen's avatar
      Merge commit 'e23b3c9c' as 'shared/n-dhcp4' · e43b1791
      Tom Gundersen authored
      Imported n-dhcp4 code with command:
        git subtree add --prefix shared/n-dhcp4/ git@github.com:nettools/n-dhcp4.git master --squash
      To update the library use:
        git subtree pull --prefix shared/n-dhcp4/ git@github.com:nettools/n-dhcp4.git master --squash
  3. 23 May, 2019 10 commits
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm/keyfile: don't parse JSON config in keyfile reader twice · 30455ab1
      Thomas Haller authored
      Commit d6ec009a ('team: normalize invalid configuration during
      load') let's keyfile reader ignore JSON configs that cannot be parsed.
      Keep doing that, but don't parse the JSON twice for that.
      Just set the JSON, and if the setting afterwards does not verify, reset
      it to NULL. We also get a better error message and in most cases we
      don't need to parse twice.
    • Thomas Haller's avatar
      nmcli: don't validate team config in nmcli · 74d0a5bf
      Thomas Haller authored
      nm_connection_verify() can already validate team settings just fine.
      No need to duplicate this.
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm: implement team's _link_watcher_from_variant() reusing meta data · cfcc4ff7
      Thomas Haller authored
      - re-use the existing meta-data. That is, don't duplicate the
      dbus-names, the types, or the default value. Instead, parse the
      settings according to these flags.
      - notice and return if there are any suspicious/wrong keys in the
      variant. For strict parsing, we should not silently ignore them.
      - previously, the code used g_variant_lookup() to search for the
      expected keys. As the number of keys that we look up is fixed, this
      still had O(n). But if we want to detect and reject invalid keys,
      we cannot use g_variant_lookup() but need to iterate the entire variant
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      libnm: rework team handling of JSON config · 13f6f3a4
      Thomas Haller authored
      Completely refactor the team/JSON handling in libnm's NMSettingTeam and
      - team handling was added as rh#1398925. The goal is to have a more
        convenient way to set properties than constructing JSON. This requires
        libnm to implement the hard task of parsing JSON (and exposing well-understood
        properties) and generating JSON (based on these "artificial" properties).
        But not only libnm. In particular nmcli and the D-Bus API must make this
        "simpler" API accessible.
      - since NMSettingTeam and NMSettingTeamPort are conceptually the same,
        add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
        handle the similar code side-by-sdie.
        The setting classes now just delegate for everything to NMTeamSetting.
      - Previously, there was a very fuzzy understanding of the provided
        JSON config. Tighten that up, when setting a JSON config it
        regenerates/parses all other properties and tries to make the
        best of it. When modifying any abstraction property, the entire
        JSON config gets regenerated. In particular, don't try to merge
        existing JSON config with the new fields. If the user uses the
        abstraction API, then the entire JSON gets replaced.
        For example note that nm_setting_team_add_link_watcher() would not
        be reflected in the JSON config (a bug). That only accidentally worked
        because client would serializing the changed link watcher to
        GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
        which would renerate the JSON, and finally persist it to disk. But
        as far as libnm is concerned, nm_setting_team_add_link_watcher() would
        bring the settings instance in an inconsistent state where JSON and
        the link watcher property disagree. Setting any property must
        immediately update both the JSON and the abstraction API.
      - when constucting a team setting from D-Bus, we would previously parse
        both "config" and abstraction properties. That is wrong. Since our
        settings plugins only support JSON, all information must be present
        in the JSON config anyway. So, when "config" is present, only the JSON
        must be parsed. In the best case, the other information is redudant and
        contributes nothing. In the worse case, they information differs
        (which might happen if the client version differs from the server
        version). As the settings plugin only supports JSON, it's wrong to
        consider redundant, differing information from D-Bus.
      - we now only convert string to JSON or back when needed. Previously,
        setting a property resulted in parsing several JSON multiple times
        (per property). All operations should now scale well and be reasonably
      - also the property-changed signals are now handled correctly. Since
        NMTeamSetting knows the current state of all attributes, it can emit
        the exact property changed signals for what changed.
      - we no longer use libjansson to generate the JSON. JSON is supposed
        to be a machine readable exchange format, hence a major goal is
        to be easily handled by applications. While parsing JSON is not so
        trivial, writing a well-known set of values to JSON is.
        The advantage is that when you build libnm without libjansson support,
        then we still can convert the artificial properties to JSON.
      - Requiring libjansson in libnm is a burden, because most of the time
        it is not needed (as most users don't create team configurations). With
        this change we only require it to parse the team settings (no longer to
        write them). It should be reasonably simple to use a more minimalistic
        JSON parser that is sufficient for us, so that we can get rid of the
        libjansson dependency (for libnm). This also avoids the pain that we have
        due to the symbol collision of libjansson and libjson-glib.
    • Thomas Haller's avatar
      libnm: add "libnm-core/nm-team-utils.h" · 539dfbcc
      Thomas Haller authored