Bug 1854306: Run ovn in shared gw mode when configure-ovs.sh run with parameter OVNKubernetes

[pliurh]

ovs-configuration.service is enabled for both ovn-kube and openshift-sdn. So using the parameter of configure-ovs.sh as the condition to tell whether ovnkube shall be in a shared gw or local gw mode. In 4.5, this parameter is not added yet.

[pliurh]

/hold
don't merge before openshift/machine-config-operator#2066 merged

[pliurh]

@trozet I am not sure whether we still need this logic anymore since we will not run ovn-kube in old local gw mode.

[openshift-ci-robot]

@pliurh: This pull request references Bugzilla bug 1854306, which is valid. The bug has been updated to refer to the pull request using the external bug tracker.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target release (4.6.0) matches configured target release for branch (4.6.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, ON_DEV, POST, POST)

In response to this:

Bug 1854306: Run ovn in shared gw mode when configure-ovs.sh run with parameter OVNKubernetes

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.

[pliurh]

/unhold

[danwinship]

/assign @trozet
but I think this is irrelevant now

(if it's not, then you need to rebase because there's currently a merge commit there)

[pliurh]

/assign @trozet
but I think this is irrelevant now

(if it's not, then you need to rebase because there's currently a merge commit there)

It's still relevant. Now the ovs-configuration.service is always enabled on 4.6 nodes, so we cannot use the file as the condition anymore. This PR makes the DaemonSets can be rendered correctly in the following 3 scenarios:

1. During an upgrade, 4.6 pods on 4.5 host, no ovs-configuration.service, run with --gateway-interface none.
2. Normal case, 4.6 pods on 4.6 host, ovs-configuration.service rendered with OVNKubernetes, run with --gateway-interface br-ex.
3. The intermediate stage of migration, 4.6 pods on 4.6 host, ovs-configuration.service rendered with Openshift-SDN, run with --gateway-interface none.

[trozet]

for ovn 4.5-> 4.6 this change doesn't matter, but it is required for openshift sdn-> ovn conversion

[trozet]

/lgtm

[pliurh]

/retest

[pliurh]

/retest

[danwinship]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, pliurh, 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:

• OWNERS [danwinship]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@pliurh: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
ci/prow/e2e-azure	81fcbeb	link	/test e2e-azure

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[openshift-bot]

/retest

Please review the full test history for this PR and help us cut down flakes.

[openshift-ci-robot]

@pliurh: Some pull requests linked via external trackers have merged:

• openshift/machine-config-operator#2066

The following pull requests linked via external trackers have not merged:

• openshift/cluster-network-operator#803 is open

These pull request must merge or be unlinked from the Bugzilla bug in order for it to move to the next state.

Bugzilla bug 1854306 has not been moved to the MODIFIED state.

In response to this:

Bug 1854306: Run ovn in shared gw mode when configure-ovs.sh run with parameter OVNKubernetes

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.