Skip to content
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

KEP-3705: update CloudDualStackNodeIPs to beta #3975

Merged
merged 1 commit into from
May 30, 2023

Conversation

danwinship
Copy link
Contributor

  • One-line PR description: update KEP-3705 CloudDualStackNodeIPs to beta, dropping the parts that were not implemented in alpha

  • Issue link: Cloud Dual-Stack --node-ip Handling #3705

  • Other comments:
    This drops the parts of the KEP that weren't implemented for alpha (--node-ip IPv4 / --node-ip IPv6, and renaming the alpha.kubernetes.io/provided-node-ip annotation), and moves some of the old text to the "Alternatives" section explaining what we didn't do and why.

/assign @thockin

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label May 1, 2023
@k8s-ci-robot k8s-ci-robot requested a review from shaneutt May 1, 2023 21:22
@k8s-ci-robot k8s-ci-robot added the kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory label May 1, 2023
@k8s-ci-robot k8s-ci-robot requested a review from thockin May 1, 2023 21:22
@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels May 1, 2023
@danwinship danwinship mentioned this pull request May 1, 2023
12 tasks
Copy link
Member

@wojtek-t wojtek-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple small comments from me - but overall this looks great

keps/sig-network/3705-cloud-node-ips/kep.yaml Outdated Show resolved Hide resolved
keps/sig-network/3705-cloud-node-ips/kep.yaml Show resolved Hide resolved

So assuming no bugs, the only visible change after (just) enabling the
feature is the duplicate annotation.
No
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't https://github.com/kubernetes/enhancements/pull/3898/files effectively a change in default behavior?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok - I guess you're dropping the proposal from that PR, right?
Assuming I'm right here, I actually like it especially given backward compatibility here...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure which part of that PR you're referring to, but it was never proposing a change in default behavior.

The original KEP-3705 said that we would

  1. add dual-stack --node-ips for external clouds
  2. add --node-ip IPv4 and --node-ip IPv6 etc
  3. rename the node IP annotation

#3898 just dropped parts 2 and 3 from alpha, and now this PR drops them from beta and GA too.

There was some discussion in #3898 about stuff we might do in the future, but even then, the assumption was that we'd do it in a backward-compatible way (eg, leave --node-ip with its current bad semantics and add --node-ips with new-and-improved semantics.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - I guess I was too much biased by the "late-breaking change" header. I've read it more carefully now and it all makes sense now.

Conveniently, we can do this just by passing the dual-stack
`--node-ip` value in the existing annotation; the old cloud provider
will try to parse it as a single IP address, fail, log an error, and
leave the node in the tainted state, which is exactly what we wanted
it to do if it can't interpret the `--node-ip` value correctly.

Therefore, we do not _need_ a new annotation for the new `--node-ip`
Therefore, we do not need a new annotation for the new `--node-ip`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You removed the part about the fact that annotation name is alpha.kubernetes.io/provided-node-ip - what we're going to do with it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As you may have noticed later, that text is still in the "Alternatives" section.

I'm not planning to do anything about the annotation as part of this KEP. I suspect I'm going to end up doing a new KEP with all of the leftover parts of this and #1665.

keps/sig-network/3705-cloud-node-ips/README.md Outdated Show resolved Hide resolved
keps/sig-network/3705-cloud-node-ips/README.md Outdated Show resolved Hide resolved
are missing a bunch of machinery and tooling and can't do that now.
-->
No. The behavior during upgrade and rollback is not especially
different from the ordinary runtime behavior.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this statement, but still, given that IPs are propagated to cloud-provider via the annotation (so technically we have some persistent state related to this feature), I think we should test it.

Manual test is good enough here (and can be done after feature freeze and updated with the description of the test then - https://github.com/kubernetes/enhancements/pull/3658/files is a great example).

Does that make sense to you? If so, can you please switch to a TODO for running it and updating this question before promoting the feature to beta?

@wojtek-t wojtek-t self-assigned this May 2, 2023
@danwinship danwinship force-pushed the kep-3705-to-beta branch 3 times, most recently from 0e6ee92 to 37fa611 Compare May 2, 2023 16:16
Copy link
Member

@wojtek-t wojtek-t left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great - just one small minor comment and this LGTM.

@wojtek-t
Copy link
Member

wojtek-t commented May 4, 2023

/lgtm
/approve PRR

thanks!

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 4, 2023
@aojea
Copy link
Member

aojea commented May 4, 2023

/lgtm

@thockin
Copy link
Member

thockin commented May 30, 2023

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: danwinship, thockin, wojtek-t

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 30, 2023
@k8s-ci-robot k8s-ci-robot merged commit b1fceaa into kubernetes:master May 30, 2023
@k8s-ci-robot k8s-ci-robot added this to the v1.28 milestone May 30, 2023
@danwinship danwinship deleted the kep-3705-to-beta branch May 31, 2023 16:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/kep Categorizes KEP tracking issues and PRs modifying the KEP directory lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/network Categorizes an issue or PR as relevant to SIG Network. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants