1. 05 Jun, 2019 10 commits
  2. 04 Jun, 2019 7 commits
    • Lubomir Rintel's avatar
      release: bump version to 1.19.3-dev · f51548f8
      Lubomir Rintel authored
      f51548f8
    • Beniamino Galvani's avatar
      team: merge branch 'th/team-fix' · 96fd188c
      Beniamino Galvani authored
      !169
      96fd188c
    • Thomas Haller's avatar
      libnm/team: strict validate team settings by libnm clients not sending the JSON · cd74fc28
      Thomas Haller authored
      When parsing a NMSettingTeam/NMSettingTeamPort from GVariant, the JSON
      "config" is always preferred. If that field is present, all other
      attributes are ignored (aside from validating that the individual fields
      are as expected).
      
      The idea is that the JSON config anyway must contain everything that artificial
      properties could. In this mode, also no validation is performed and the setting is
      always accepted (regardless whether libnm thinks the setting verifies).
      
      When a libnm client created the setting via the artificial properties,
      only send them via D-Bus and exclude the JSON config. This turns on
      strict validation server side.
      
      Now we actually get validation of the settings:
      
        $ nmcli connection add type team team.runner-tx-hash l3
        Error: Failed to add 'team' connection: team.runner: runner-tx-hash is only allowed for runners loadbalance,lacp
      
      this is obviously a change in behavior as previously all settings
      would have been accepted, regardless whether they made sense.
      cd74fc28
    • Thomas Haller's avatar
      cli: remove unnecessary workaround for clearing team link watchers and runner-tx-hash · dfa8ecda
      Thomas Haller authored
      This is fixed in libnm. Resetting the GObject property clears the list
      of watchers and tx-hashes.
      
      Since nmcli requires a libnm version >= itself, this workaround
      is no longer necessary.
      dfa8ecda
    • Thomas Haller's avatar
      libnm/team: fix handling default values and stricter validate team config · 23b1f823
      Thomas Haller authored
      For each artifical team property we need to track whether it was
      explicitly set (i.e., present in JSON/GVariant or set by the user
      via NMSettingTeam/NMSettingTeamPort API).
      
       --
      
      As a plus, libnm is now no longer concerned with the underling default values
      that teamd uses. For example, the effective default value for "notify_peers.count"
      depends on the selected runner. But libnm does not need to care, it only cares
      wheher the property is set in JSON or not. This also means that the default (e.g. as
      interesting to `nmcli -o con show $PROFILE`) is independent from other properties
      (like the runner).
      
      Also change the default value for the GObject properties of
      NMSettingTeam and NMSettingTeamPort to indicate the "unset" value.
      For most properties, the default value is a special value that is
      not a valid configuration itself.
      For some properties the default value is itself a valid value, namely,
      "runner.active", "runner.fast_rate", "port.sticky" and "port.prio".
      
      As far as NMTeamSetting is concerned, it distinguishes between unset
      value and set value (including the default value). That means,
      when it parses a JSON or GVariant, it will remember whether the property
      was present or not.
      
      When using API of NMSettingTeam/NMSettingTeamPort to set a property to the
      default value, it marks the property as unset. For example, setting
      NM_SETTING_TEAM_RUNNER_ACTIVE to TRUE (the default), means that the
      value will not be serialized to JSON/GVariant. For the above 4
      properties (where the default value is itself a valid value) this is a
      limitation of libnm API, as it does not allow to explicitly set
      '"runner": { "active": true }'. See SET_FIELD_MODE_SET_UNLESS_DEFAULT,
      
      Note that changing the default value for properties of NMSetting is problematic,
      because it changes behavior for how settings are parsed from keyfile/GVariant.
      For team settings that's not the case, because if a JSON "config" is
      present, all other properties are ignore. Also, we serialize properties
      to JSON/GVariant depending on whether it's marked as present, and not
      whether the value is set to the default (_nm_team_settings_property_to_dbus()).
      
       --
      
      While at it, sticter validate the settings. Note that if a setting is
      initialized from JSON, the strict validation is not not performed. That
      means, such a setting will always validate, regardless whether the values
      in JSON are invalid according to libnm. Only when using the extended
      properties, strict validation is turned on.
      
      Note that libnm serializes the properties to GVariant both as JSON "config"
      and extended properties. Since when parsing a setting from GVariant will
      prefer the "config" (if present), in most cases also validation is
      performed.
      
      Likewise, settings plugins (keyfile, ifcfg-rh) only persist the JSON
      config to disk. When loading a setting from file, strict validation is
      also not performed.
      
      The stricter validation only happens if as last operation one of the
      artificial properties was set, or if the setting was created from a
      GVariant that has no "config" field.
      
       --
      
      This is a (another) change in behavior.
      23b1f823
    • Thomas Haller's avatar
      libnm/team: reorder fields in JSON output for team link watcher · efe602af
      Thomas Haller authored
      The order of the fields in the JSON object does not really matter.
      
      Note that with the recent rework the order changed. Before it was
      arbitrarily, now it still is arbitrary.
      
      Reorder again, to follow the same order as `man teamd.conf`.
      efe602af
    • Thomas Haller's avatar
      libnm/team: add space in JSON output for link watcher · 56f45d7b
      Thomas Haller authored
      Generate the following:
      
       { "runner": { "sys_prio": 10 }, "link_watch": { "name": "ethtool" } }
      
      instead of:
      
       { "runner": { "sys_prio": 10 }, "link_watch": { "name": "ethtool"} }
      56f45d7b
  3. 02 Jun, 2019 1 commit
  4. 31 May, 2019 1 commit
  5. 30 May, 2019 1 commit
    • Lubomir Rintel's avatar
      config: also save next-server in the state file · 5cf6cfd9
      Lubomir Rintel authored
      The early boot tooling gets the root-path from our state file due to a
      lack of a better way to do that. However, when booting with NFS root,
      the root path alone is not sufficient; the server address is communicated
      via the next-server option. Save that one in the state file as well.
      
      !168
      5cf6cfd9
  6. 29 May, 2019 12 commits
  7. 28 May, 2019 8 commits