OPNET-763: NMState Opt-In for br-ex#1963
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@cybertron: This pull request references OPNET-763 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 epic to target the "4.22.0" version, but no target version was set. DetailsIn 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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@cybertron: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. |
openshift-ci
Bot
requested review from
emy,
everettraven,
mkowalski,
rbbratta and
zaneb
| Because this feature is delivered using the same mechanism (MCO) as the | ||
| existing configure-ovs script, it should work the same way. |
There was a problem hiding this comment.
Do we have any documentation as to how this works today on HyperShift? IIRC the MCO doesn't work the same way on HyperShift as it does on standalone clusters so making sure that there isn't something special we need to do to make sure HyperShift is configuring things correctly would be good.
@yuqi-zhang and/or @sjenning probably have a better handle of the nuances here than I do.
There was a problem hiding this comment.
I don't have any specific documentation, but I did discuss it with the MCO team and although user-created machine-configs are not available in HyperShift, the built-in MCO templates are still delivered via Ignition. That's how configure-ovs gets to HyperShift nodes today, and the same will be true if we add new template(s) for this feature.
| We also anticipate having a bridgeTopology for balance-slb bonds, which is | ||
| structurally different from a standard br-ex configuration and can't easily | ||
| be handled in the same policy. There is an existing feature in configure-ovs | ||
| that creates a br-ex1 too, so at some point we will need to support that as | ||
| well. |
There was a problem hiding this comment.
Any chance we can document what the future behavior we anticipate needing is a bit more clearly for those unfamiliar with this space?
As an API reviewer with less context in this space, having an understanding of what we may need to account for in the future helps influence the API structure and ensuring we have good extensibility paths.
There was a problem hiding this comment.
Yes, I can try to expand on this.
There was a problem hiding this comment.
Hmm, in fact, after revisiting this in light of some PoC work I've done, I think this needs to be redesigned. I originally anticipated multiple independent topologies. However, I think now we will need a matrix of topologies. I'll rewrite to reflect this updated understanding.
| Some users may already have existing full NMState br-ex configs that they would | ||
| like to keep using. This is possible because we are not removing the old | ||
| feature, but it also doesn't improve the old, bad, interface. |
There was a problem hiding this comment.
Just to make sure I'm following along, this feature is meant to be an "easy button" for configuring NMState br-ex with some set of default values. For those that have custom configurations they would like to apply they continue to use the existing configure-ovs script instead of this feature?
Do you envision a future where the install config is a complete replacement of the configure-ovs script?
If a cluster uses this feature and later decides they need more nuanced configuration, what is their path to doing so?
There was a problem hiding this comment.
It will still be possible to use configure-ovs or use NMState with full configs delivered via machine-configs. Configure-ovs is less flexible but is the default today, and the existing NMState feature requires significantly more complex configuration to be written by the user. Ideally this will be a hybrid of the two - most of the flexibility of NMState with the simplicity of configure-ovs.
We do hope that eventually this feature will be able to replace configure-ovs completely. It's the main reason we decided to drop #1795 in favor of this. Even if we replace configure-ovs completely, we'll likely still need a field like this for some configurations. If we did the thing described in #1795 we might end up with dead configuration fields that we don't want people to use anymore.
There are actually multiple ways to modify these configs on day 2. The primary method will be to adopt the config into Kubernetes-NMState and modify it using that operator. More dangerous is the disruptive changes mechanism: https://docs.redhat.com/en/documentation/openshift_container_platform/4.20/html/installing_on_bare_metal/bare-metal-post-installation-configuration#making-disruptive-changes-br-ex-bridge.adoc_bare-metal-postinstallation-configuration
I actually should include something about the adoption process into the operator because it turns out to be more complicated in this instance than we expected and is going to require some tooling to support.
|
This seems consistent with what we previously discussed 👍 |
4 participants
No description provided.