-
Notifications
You must be signed in to change notification settings - Fork 463
Write MTU migration configuration #2856
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write MTU migration configuration #2856
Conversation
7864225 to
eb0095f
Compare
1f2268f to
40ae07b
Compare
|
/hold cancel |
yuqi-zhang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some questions from an initial pass. Is this required for 4.10? Also would prefer some one from the Networking team to take a look
Yes, this is required for 4.10. |
|
/assign @trozet |
|
/retest |
yuqi-zhang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's some more context to the PR now that I understand it better:
- This PR is mostly safe from the MCO's perspective, since it doesn't affect anything in the core code path. Nothing happens if you don't define migration which is set via the CNO (which we read already)
- This PR itself is a no-op, and requires a follow up PR (which we may squash) that drops in a NM dispatcher script to do the actual operations
- This is required in 4.10
So with that in mind, I am mostly confident this is an ok approach given the tight timelines. This does introduce the concept of "empty file templates" which only renders if a condition is met. For future consideration, I think either:
- have the CNO be the one generating the MC in the first place, such that we don't have to read it in the MCO, or
- have the MCO core logic have better understanding of conditional templates
Is the better way to go.
Some more comments below:
59cc4ed to
c016bd0
Compare
|
PTAL please @trozet Also your opinion on: Can or should we, and how, deprecate the current
@yuqi-zhang thoughts on this is that ControllerConfigSpec is not really a public API and that general way of proceeding is option 3 above. This could be worked on in a follow up PR as it is not needed for 4.10 |
81e201d to
1992908
Compare
trozet
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general lgtm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe just comment that this is only for a use case where the host MTUs are not modified and just the CNI MTU is modified?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if its possible, it would make it more readable to indent this logic. The logic looks OK to me though.
ab552aa to
2937399
Compare
2937399 to
359f95c
Compare
|
/retest |
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
359f95c to
2c75679
Compare
|
/retest-required |
|
/retest |
trozet
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
|
@yuqi-zhang can you PTAL for approval? |
|
@jcaamano: The following tests failed, say
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/test-infra repository. I understand the commands that are listed here. |
yuqi-zhang
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
New changes lgtm
Also linking #2871 as the second part of this migration work
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jcaamano, trozet, yuqi-zhang The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Add support for MTU migration.
MCO updates the controller spec with MTU migration configuration obtained from network status. This MTU migration configuration is only there while a MTU migration is taking place. Only then, as a result, MCO renders a configuration file from a template included in this PR. This configuration file will be sourced from an upcoming NM dispatcher script that will also be rendered from an MCO template. Both configuration file and NM dispatcher script only need to be rendered while an MTU migration is in progress.
Enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/network/allow-mtu-changes.md
Vendored in needed openshift-api changes: openshift/api/pull/1078
/assign @yuqi-zhang
/hold