Bug 1971715: configure-ovs: fix nondeterministic master in slave profiles #2626
Conversation
openshift-ci
bot
added
bugzilla/severity-high
|
@jcaamano: This pull request references Bugzilla bug 1971715, which is valid. The bug has been moved to the POST state. The bug has been updated to refer to the pull request using the external bug tracker. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (anusaxen@redhat.com), skipping review request. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/cc @trozet @msherif1234 |
|
/retest |
| local old="$1" | ||
| local new="$2" | ||
| for conn_uuid in $(nmcli -g UUID connection show) ; do | ||
| if [ "$(nmcli -g connection.master connection show uuid "$conn_uuid")" != "$old" ]; then |
There was a problem hiding this comment.
@jcaamano what if the old connection has a connection.master of device name instead of UUID, should we check that too?
There was a problem hiding this comment.
Done, we look for both things.
|
@jcaamano: This pull request references Bugzilla bug 1971715, which is valid. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Bugzilla (anusaxen@redhat.com), skipping review request. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/retest |
|
@jcaamano: An error was encountered querying GitHub for users with public email (anusaxen@redhat.com) for bug 1971715 on the Bugzilla server at https://bugzilla.redhat.com. No known errors were detected, please see the full error message for details. Full error message.
non-200 OK status code: 403 Forbidden body: "{\n \"documentation_url\": \"https://docs.github.com/en/free-pro-team@latest/rest/overview/resources-in-the-rest-api#abuse-rate-limits\",\n \"message\": \"You have triggered an abuse detection mechanism. Please wait a few minutes before you try again.\"\n}\n"
Please contact an administrator to resolve this issue, then request a bug refresh with In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
| # bring down old iface | ||
| nmcli device disconnect $iface | ||
|
|
||
| # bring up new connectionx |
There was a problem hiding this comment.
nit typo on the connectionx
|
/assign @kikisdeliveryservice |
configure-ovs sets the master device name as connection.master on slave connection profiles when the default gateway being replaced is a master device. Those slave profiles may activate before the master profile and if so, NM may chose non-deterministically any master profile that might provide a connection for the master device name, which may be the old master connection profile instead of the replacement connection profile. The auto-connect priority does not seem to be considered as this might not be regarded by NM as an auto-connect of the master profile in strict sense. Setting the master connection profile uuid as connection.master on slave connection profiles ensures that the correct master profile is activated when the slave auto-connects. This requires a bit more effort when reverting the configuration. Additionally, if there is any modification to the slave connection profiles, those need to be persisted as well from systemConnectionsMerged to system-connections fixes: openshift#2519 fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com>
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jcaamano, sinnykumari, trozet The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/test e2e-agnostic-upgrade |
Pull request openshift#2626 did not account for a possible scenario where networking configuration would be backed with ifcfg files instead of nmconnection files. Attempting to persist slave nmconnection changes in case of an overlay setup of NM configuration directory would fail. Additionally opted for a strategy of cloning slave connection profiles instead of modifying them directly to avoid any interference with MCO existing configuration. Also fixed shellcheck reported issues in 4.8 backport pull request openshift#2639. fixes: openshift#2626 fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com>
Pull request openshift#2626 did not account for a possible scenario where networking configuration would be backed with ifcfg files instead of nmconnection files. Attempting to persist slave nmconnection changes in case of an overlay setup of NM configuration directory would fail. Additionally opted for a strategy of cloning slave connection profiles instead of modifying them directly to avoid any interference with MCO existing configuration. Also fixed shellcheck reported issues in 4.8 backport pull request openshift#2639. fixes: openshift#2626 fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 6654fd1)
Pull request openshift#2626 did not account for a possible scenario where networking configuration would be backed with ifcfg files instead of nmconnection files. Attempting to persist slave nmconnection changes in case of an overlay setup of NM configuration directory would fail. Additionally opted for a strategy of cloning slave connection profiles instead of modifying them directly to avoid any interference with MCO existing configuration. Also fixed shellcheck reported issues in 4.8 backport pull request openshift#2639. fixes: openshift#2626 fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 6654fd1)
Pull request openshift#2626 did not account for a possible scenario where networking configuration would be backed with ifcfg files instead of nmconnection files. Attempting to persist slave nmconnection changes in case of an overlay setup of NM configuration directory would fail. Additionally opted for a strategy of cloning slave connection profiles instead of modifying them directly to avoid any interference with MCO existing configuration. Also fixed shellcheck reported issues in 4.8 backport pull request openshift#2639. fixes: openshift#2626 fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715 Signed-off-by: Jaime Caamaño Ruiz <jcaamano@redhat.com> (cherry picked from commit 6654fd1)
- What I did
configure-ovs sets the master device name as connection.master on slave
connection profiles when the default gateway being replaced is a master
device.
Those slave profiles may activate before the master profile and if so,
NM may chose non-deterministically any master profile that might provide
a connection for the master device name, which may be the old master
connection profile instead of the replacement connection profile. The
auto-connect priority does not seem to be considered as this might not
be regarded by NM as an auto-connect of the master profile in strict
sense.
Setting the master connection profile uuid as connection.master on slave
connection profiles ensures that the correct master profile is activated
when the slave auto-connects. This does require a bit more effort when
reverting the configuration.
Additionally, if there is any modification to the slave connection
profiles, those need to be persisted as well from
systemConnectionsMerged to system-connections
- How to verify it
Run
./configure-ovs OVNKuberneteson a device with a bond interface as default gateway, using the following NM configuration:where
/etc/NetworkManager/systemConnectionsMergedis an overlay fs as:Verify that the applied network configuration persists accross reboots.
- Description for the changelog
Improved configuration of OVS with bond interfaces for OVNKuberentes
fixes: #2519
fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1971715
Signed-off-by: Jaime Caamaño Ruiz jcaamano@redhat.com