OSDOCS-10661:updates for local gateway mode #90373
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/L
|
🤖 Wed Apr 02 15:13:52 - Prow CI generated the docs preview: |
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
JoeAldinger
force-pushed
the
OSDOCS-10661
branch
from
4f0cc9c to
f2d3718
Compare
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
LGTM. Thanks! |
|
LGTM! @palonsoro Can you have a look too please? |
modules/nw-operator-cr.adoc
Outdated
| @@ -206,7 +206,7 @@ endif::operator[] | |||
|
|
|||
| |`gatewayConfig` | |||
| |`object` | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Accepted values are `Shared` and `Local`. The default value is `Shared`. In the default setting, all external traffic leaving the cluster is routed through a centralized gateway node and pods use a single egress IP for outbound traffic. In the `Local` setting, external traffic from pods exits through the node that it is running on. Each node serves as its own gateway. | |||
There was a problem hiding this comment.
This is incorrect. In both Shared and Local gateway modes, the traffic exits from the pod node unless it has to use an egress IP located in a different node.
The difference between Shared and Local is that, in Shared, OVS outputs traffic directly to the node IP interface, while in Local it traverses the host network (so it gets applied the routing table of the host, etc.)
There was a problem hiding this comment.
It might be possible that you are misinterpreting some details on how the logical architecture at OVN level used to be described. But here it is best to stick to what happens physically, which is what I described above.
modules/nwt-gateway-mode.adoc
Outdated
|
|
||
| As a cluster administrator you can configure the gateway mode using the `gatewayConfig` spec in the Cluster Network Operator. The following procedure can be used to set the `routingViaHost` field to `true` for local mode or `false` for shared mode. | ||
|
|
||
| You might follow the optional step 4 to enable IP forwarding alongside local gateway mode if you require node level traffic control. For example, possible use cases for combining local gateway mode with IP forwarding include: |
There was a problem hiding this comment.
Enabling IP forwarding toes not allow "node level traffic control", so that sentence should be removed. It allows the host network of the node to act as router for traffic not related to OVN-Kubernetes.
modules/nwt-gateway-mode.adoc
Outdated
| ipsecConfig: | ||
| # ... | ||
| ---- | ||
| <1> A value of `true` sets local gateway mode and a value of `false` sets shared gateway mode. |
There was a problem hiding this comment.
It may be easier for customers to understand if we bring the "shared gateway" and "logical gateway" to the background and favor talking about "we are routing through the host" or "we aren't routing through the host". I am not talking about removing the terminology (because users know it already) but easing the explanation that way.
|
|
||
| As a cluster administrator you can configure the `gatewayConfig` object to manage how external traffic leaves the cluster. You do so by setting the `routingViaHost` spec to `true` for local mode or `false` for local mode. | ||
|
|
||
| In the shared mode traffic is forwarded from pods in the cluster to a shared centralized node where it exits the cluster. In the local mode, each node serves as its own gateway so that traffic exits from a pod through the node it is running on. |
There was a problem hiding this comment.
Again, this is wrong or, at least, misleading. Traffic always goes out from the pod node (unless there is an egress IP in place). The difference is whether it traverses the host network stack or OVS sends it directly to the physical interface.
JoeAldinger
force-pushed
the
OSDOCS-10661
branch
from
f2d3718 to
64cf210
Compare
|
LGTM now. Thanks! |
JoeAldinger
force-pushed
the
OSDOCS-10661
branch
from
64cf210 to
3d26d14
Compare
JoeAldinger
added
the
peer-review-needed
skopacz1
added
the
peer-review-in-progress
|
@asood-rh can you help with the versions this should be applied to, please? |
@JoeAldinger gateway mode is applicable to all the above versions that you added. |
|
/lgtm |
modules/nw-operator-cr.adoc
Outdated
| @@ -206,7 +206,7 @@ endif::operator[] | |||
|
|
|||
| |`gatewayConfig` | |||
| |`object` | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Possible values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface, In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. | |||
There was a problem hiding this comment.
Comma that should be a period:
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Possible values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface, In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. | |
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Possible values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface. In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. |
modules/nw-operator-cr.adoc
Outdated
| @@ -206,7 +206,7 @@ endif::operator[] | |||
|
|
|||
| |`gatewayConfig` | |||
| |`object` | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. | |||
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Possible values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface, In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. | |||
There was a problem hiding this comment.
Just a suggestion to consider, but maybe switch "possible" for "valid"? Unless there's a reason to keep it as is
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Possible values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface, In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. | |
| |Optional: Specify a configuration object for customizing how egress traffic is sent to the node gateway. Valid values are `Shared` and `Local`. The default value is `Shared`. In the default setting, the Open vSwitch (OVS) outputs traffic directly to the node IP interface, In the `Local` setting, it traverses the host network; consequently, it gets applied to the routing table of the host. |
|
|
||
| toc::[] | ||
|
|
||
| As a cluster administrator you can configure the `gatewayConfig` object to manage how external traffic leaves the cluster. You do so by setting the `routingViaHost` spec to `true` for local mode or `false` for local mode. |
There was a problem hiding this comment.
In the second sentence, it states that both options are for local mode, is this correct?
There was a problem hiding this comment.
Good catch. True is local mode, false is shared mode.
There was a problem hiding this comment.
Yes, good catch. Thank you, @skopacz1
modules/nwt-gateway-mode.adoc
Outdated
|
|
||
| As a cluster administrator you can configure the gateway mode using the `gatewayConfig` spec in the Cluster Network Operator. The following procedure can be used to set the `routingViaHost` field to `true` for local mode or `false` for shared mode. | ||
|
|
||
| You might follow the optional step 4 to enable IP forwarding alongside local gateway mode if you need the host network of the node to act as a router for traffic not related to OVN-Kubernetes. For example, possible use cases for combining local gateway mode with IP forwarding include: |
There was a problem hiding this comment.
Per the ISG, "might" is used to indicate possibility ("this might happen"), while "can" is used to indicate ability ("You can do this action, if you want"). Do you think this is a case where you could use "can" to indicate that someone has the option to do this?
| You might follow the optional step 4 to enable IP forwarding alongside local gateway mode if you need the host network of the node to act as a router for traffic not related to OVN-Kubernetes. For example, possible use cases for combining local gateway mode with IP forwarding include: | |
| You can follow the optional step 4 to enable IP forwarding alongside local gateway mode if you need the host network of the node to act as a router for traffic not related to OVN-Kubernetes. For example, possible use cases for combining local gateway mode with IP forwarding include: |
I don't know the context here so I will leave it up to you
There was a problem hiding this comment.
For the best of my knowledge, "can" would make more sense as per your definition. But I'll let @JoeAldinger decide.
There was a problem hiding this comment.
You know I struggled with whether might or can should go here when I was writing this up. Good to have more than one input. I'm changing to can.
modules/nwt-gateway-mode.adoc
Outdated
| $ oc get network.operator cluster -o yaml > network-config-backup.yaml | ||
| ---- | ||
|
|
||
| . Set `routingViaHost` to `true` for local gateway mode by running the following command: |
There was a problem hiding this comment.
Suggestion to add a noun to the param for clarity:
| . Set `routingViaHost` to `true` for local gateway mode by running the following command: | |
| . Set the `routingViaHost` parameter to `true` for local gateway mode by running the following command: |
modules/nwt-gateway-mode.adoc
Outdated
| ---- | ||
| $ oc patch network.operator cluster --type=merge -p '{"spec":{"defaultNetwork":{"ovnKubernetesConfig":{"gatewayConfig":{"ipForwarding": "Global"}}}}}' | ||
| ---- | ||
| .. Verify that `ipForwarding` spec has been set to `Global` by running the following command: |
There was a problem hiding this comment.
I think this needs an article here:
| .. Verify that `ipForwarding` spec has been set to `Global` by running the following command: | |
| .. Verify that the `ipForwarding` spec has been set to `Global` by running the following command: |
skopacz1
removed
peer-review-in-progress
skopacz1
added
the
peer-review-done
JoeAldinger
force-pushed
the
OSDOCS-10661
branch
from
3d26d14 to
e0ff960
Compare
|
New changes are detected. LGTM label has been removed. |
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
@JoeAldinger: all tests passed! 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-sigs/prow repository. I understand the commands that are listed here. |
|
@JoeAldinger: This pull request references OSDOCS-10661 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.19." or "openshift-4.19.", but it targets "openshift-4.16.z" instead. 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 openshift-eng/jira-lifecycle-plugin repository. |
|
/cherrypick enterprise-4.19 |
|
/cherrypick enterprise-4.18 |
|
/cherrypick enterprise-4.17 |
|
@JoeAldinger: new pull request created: #91537 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-sigs/prow repository. |
|
@JoeAldinger: new pull request created: #91538 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-sigs/prow repository. |
|
@JoeAldinger: new pull request created: #91539 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-sigs/prow repository. |
|
Confirmed with QE and SME that this is ok to CP to 4.16 given inflight PR: #90373 |
|
/cherrypick enterprise-4.16 |
|
@JoeAldinger: new pull request created: #92139 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-sigs/prow repository. |
Version(s):
4.17+
Issue:
https://issues.redhat.com/browse/OSDOCS-10661
Link to docs preview:
https://90373--ocpdocs-pr.netlify.app/openshift-enterprise/latest/networking/ovn_kubernetes_network_provider/configuring-gateway-mode
QE review:
Additional information:
PR that adds local gateway procedural change to OVN-K docs: #90975