Bug 1887523
Summary: | [bond] The packets_per_slave option should be only valid under balance-rr mode | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Gris Ge <fge> |
Component: | NetworkManager | Assignee: | Thomas Haller <thaller> |
Status: | CLOSED ERRATA | QA Contact: | Vladimir Benes <vbenes> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 8.4 | CC: | acardace, atragler, bgalvani, bperkins, lrintel, rkhan, sukulkar, thaller, till, vbenes |
Target Milestone: | rc | Keywords: | Triaged |
Target Release: | 8.4 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | NetworkManager-1.30.0-0.2.el8 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-05-18 13:29:43 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gris Ge
2020-10-12 17:34:44 UTC
`nm_setting_bond_add_option()` does not perform such kind of validations, nor should it. For one, that is because you always could also set the GObject property (NM_SETTING_BOND_OPTIONS), and when setting a GObject property, there is no place to validate the input (as `g_object_set()` has no return value to indicate failure). In general, in libnm it is not the setters that perform validation. Validation should be performed by nm_connection_verify(). That is for example also because often the validity of a setting depends on multiple properties (like `packets_per_slave` only works with certain bond modes). Validating values in the setter would mean that you need to set the options in a certain order. Say you start with a setting "mode=balance-rr, packets_per_slave=1" and you want to get to "mode=802.3ad, ad_actor_sys_prio=5". It means, you either first set "mode=802.3ad" (but then "packets_per_slave=1" would be wrong/inconsistent), or you first set "ad_actor_sys_prio=5" (but then the mode would be wrong). Actually, add-option does perform some basic form of validation. For example, "packets_per_slave" is validated to be a string. I think that is an actual bug, because it means you can set options via NM_SETTING_BOND_OPTIONS to anything, but there is no corresponding C API to achieve the same. That is a problem, because keyfile reader uses nm_setting_bond_add_option(), and -- in case of an invalid value -- it silently ignores certain values. Actually, nm_connection_verify() for bond options has a different problem: historically the validation was not strict and accept some settings that would not be valid. This was not fixed so far, because making validation more strict is a breaking change in behavior. Maybe, nm_connection_verify() should be tightend up for bond settings, but it's problematic to do so. What also should be done is `nm_setting_bond_add_option()` consistently does *not* perform any of the basic validation. Because the basic validation should only happen during nm_connection_verify(), and keyfile reader would better handle reading invalid values -- of course, that would also be a breaking change in behavior *sigh*. The way bond options are handled by libnm/NMSettingBond is rather ugly, and fixing it would break existing behavior. Gris does the '`packets_per_slave` option get rejected when bond-mode is not 'balance-rr' when using nm_connection_verify()? The `NM.RemoteConnection.verify()` return True when holding `NM.SettingBond` with `packets_per_slave: 1` and `mode: active-backup`. Nmstate has verification stage which will warn user about invalid bond options, so I don't expect NM fix it any time soon. Just want to let you know the issue exists. As the API user of libnm, the document said `add_option(): True if the option was valid and was added to the internal option list, False if it was not.`. And the document also have `validate_option()` which still return `True` in this case. Please update the document of API also. > The `NM.RemoteConnection.verify()` return True when holding `NM.SettingBond` with `packets_per_slave: 1` and `mode: active-backup`. Yes, that's because > > Actually, nm_connection_verify() for bond options has a different problem: historically the validation was not strict and accept some settings that would not be valid. This was not fixed so far, because making validation more strict is a breaking change in behavior. Maybe, nm_connection_verify() should be tightend up for bond settings, but it's problematic to do so. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/653 ^^ this disables all validation of nm_setting_bond_add_option() and adjust documentation. It does not add stricter validation for nm_connection_verify(). Maybe that should be done in the future, but it's problematic. Gris are you happy with this solution? I know it's not ideal but we might break a lot of (incorrect) connection profiles if we make the verify() stricter. Unfortunately options which are not compatible with the bond mode get stripped from the connection profile in NM. I am OK with NM remove all check on bond options and let others do the work. Note that https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/653 only removes the checks when adding an option through 'nm_setting_bond_add_option()', 'nm_connection_verify()' will still do all the previous checks on the bond connection options. I am OK on `nm_setting_bond_add_option` removing the validation work. NetworkManager-1.30.0-0.2.el8.x86_64.rpm passed bond test of nmstate CI. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: NetworkManager and libnma security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:1574 |