1. 11 Jun, 2019 14 commits
  2. 09 Jun, 2019 3 commits
    • Thomas Haller's avatar
      libnm/team: fix setting setting same JSON string · 2d6c711d
      Thomas Haller authored
      When we set the same JSON config twice in a row, the second time has
      indeed no effect and we can just return right away (indicating that
      no attributes changed).
      However, that is not true, if we are in strict validating mode and
      the JSON string just happens to be the same. In this case, we still
      want to switch from strict validating mode to relaxed mode. Hence,
      we should not return early but continue setting the property.
    • Thomas Haller's avatar
      wwan: don't call _nm_modem_set_operator_code() in property setter · dd3b47de
      Thomas Haller authored
      NM_MODEM_OPERATOR_CODE property is construct-only. Add our common
      code comment to the property setter.
      Construct-only setters are pretty simple. They run before the object is
      constructed, hence their scope is clearer. As such, there is no need to
      emit property changed notifications (also because that is already taken
      care by the GObject property setter). Don't call _nm_modem_set_operator_code(),
      just directly set the property.
      Usually we aim to have only one place where we set state (_nm_modem_set_operator_code()).
      But a construct-only property setter is trivial enough that we can affort having two
      places to modify the property. In particular, because the property setter does not "modify"
      the property, it merely initializes it before the object is fully
    • Thomas Haller's avatar
      wwan: remove unused property setter for NM_MODEM_APN · 5b098203
      Thomas Haller authored
      The property is read-only. The setter code is unused and unnecessary.
  3. 05 Jun, 2019 11 commits
  4. 04 Jun, 2019 7 commits
    • Lubomir Rintel's avatar
      release: bump version to 1.19.3-dev · f51548f8
      Lubomir Rintel authored
    • Beniamino Galvani's avatar
    • 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.
    • 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.
    • 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
      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.
    • 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`.
    • 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"} }
  5. 02 Jun, 2019 1 commit
  6. 31 May, 2019 1 commit
  7. 30 May, 2019 1 commit
  8. 29 May, 2019 2 commits