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.

Sign up for GitHub

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

Jump to bottom

cloud_cidr_allocator: don't assume gce cidrs are validated #118043

Closed
wants to merge 1 commit into from
Closed

cloud_cidr_allocator: don't assume gce cidrs are validated #118043

wants to merge 1 commit into from

Conversation

aojea
Copy link
Member

@aojea aojea commented May 16, 2023 •
edited
Loading

The cloud_cidr_allocator should not assume that the cidrs allocated for the Nodes are validated and will be always single stack or dual-stack.

/kind bug
/kind cleanup

cloud-cidr allocators only considers the first cidr of each IP family to assign to the nodes

Fixes: kubernetes/test-infra#29500

@aojea
cloud_cidr_allocator: don't assume gce cidrs are validated
2a20407 
The cloud_cidr_allocator should not assume that the cidrs allocated
for the Nodes are validated and will be always single stack or
dual-stack.

Change-Id: Ieeda768335b2f7ea9c2007e053de46ce2c7f270a
@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. kind/bug Categorizes issue or PR as related to a bug. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 16, 2023
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@k8s-ci-robot k8s-ci-robot added the needs-priority Indicates a PR lacks a `priority/foo` label and requires one. label May 16, 2023
@aojea
Copy link
Member Author

aojea commented May 16, 2023

/assign @wojtek-t @bowei @basantsa1989
/cc @Argh4k

@k8s-ci-robot k8s-ci-robot added the sig/apps Categorizes an issue or PR as relevant to SIG Apps. label May 16, 2023
@k8s-ci-robot
Copy link
Contributor

@aojea: GitHub didn't allow me to assign the following users: basantsa1989.

Note that only kubernetes members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @wojtek-t @bowei @basantsa1989
/cc @Argh4k

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.

@k8s-ci-robot k8s-ci-robot added the sig/network Categorizes an issue or PR as relevant to SIG Network. label May 16, 2023
@k8s-ci-robot
Copy link
Contributor

@aojea: GitHub didn't allow me to request PR reviews from the following users: Argh4k.

Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.

In response to this:

/assign @wojtek-t @bowei @basantsa1989
/cc @Argh4k

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.

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label May 16, 2023
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: aojea

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 16, 2023
@k8s-ci-robot k8s-ci-robot requested review from bowei and MrHohn May 16, 2023 10:25
@basantsa1989
Copy link
Contributor

basantsa1989 commented May 18, 2023 •
edited
Loading

@aojea when the provider returns incorrect list of cidrs (like 2 ipv4 addresses), we do not know which one of them is the valid ipv4 address that is meant for podCIDR.

In your changes here, we are assuming it is the first one, is that the expected behavior?

I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

@wojtek-t
Copy link
Member

@aojea - can you respond to the above? I'm not familiar with this stuff enough and the above sounds like a legitimate concern.

@aojea
Copy link
Member Author

aojea commented May 24, 2023

In your changes here, we are assuming it is the first one, is that the expected behavior?

I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

I really don't know honestly, I can't see any place that defines the "expected behavior" , if the expected behavior is "return only ipv4 and ipv6" then @basantsa1989 is right

/close

@k8s-ci-robot
Copy link
Contributor

@aojea: Closed this PR.

In response to this:

In your changes here, we are assuming it is the first one, is that the expected behavior?

I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

I really don't know honestly, I can't see any place that defines the "expected behavior" , if the expected behavior is "return only ipv4 and ipv6" then @basantsa1989 is right

/close

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.

@aojea aojea mentioned this pull request May 25, 2023
Open
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesn't merit a release note. labels May 25, 2023
@aojea
Copy link
Member Author

aojea commented May 25, 2023

In your changes here, we are assuming it is the first one, is that the expected behavior?

that is how most of these situations are handled here AFAIK, or we fail in validation or first wins

@aojea
Copy link
Member Author

aojea commented May 26, 2023

@aojea when the provider returns incorrect list of cidrs (like 2 ipv4 addresses), we do not know which one of them is the valid ipv4 address that is meant for podCIDR.

In your changes here, we are assuming it is the first one, is that the expected behavior?

I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

/reopen

@basantsa1989 I'm not convinced that this behavior is correct, since there are at least 2 situations this dual-stack assumption leaves a cluster unusable and is confusing for users.
Assuming ordered precedence seems legit, since GCE has this notion of primaries and secondaries too ... we should talk to find a solution but leaving it as "worked as intended" does not sound correct

@k8s-ci-robot k8s-ci-robot reopened this May 26, 2023
@k8s-ci-robot
Copy link
Contributor

@aojea: Reopened this PR.

In response to this:

@aojea when the provider returns incorrect list of cidrs (like 2 ipv4 addresses), we do not know which one of them is the valid ipv4 address that is meant for podCIDR.

In your changes here, we are assuming it is the first one, is that the expected behavior?

I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

/reopen

@basantsa1989 I'm not convinced that this behavior is correct, since there are at least 2 situations this dual-stack assumption leaves a cluster unusable and is confusing for users.
Assuming ordered precedence seems legit, since GCE has this notion of primaries and secondaries too ... we should talk to find a solution but leaving it as "worked as intended" does not sound correct

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.

@aojea
Copy link
Member Author

aojea commented May 26, 2023

@aojea when the provider returns incorrect list of cidrs (like 2 ipv4 addresses), we do not know which one of them is the valid ipv4 address that is meant for podCIDR.
In your changes here, we are assuming it is the first one, is that the expected behavior?
I don't see the current behavior as a "bug". It is designed to handle dual stack and we expect at most 2 cidrs from the providers, one IPv4 and one IPv6.

/reopen

@basantsa1989 I'm not convinced that this behavior is correct, since there are at least 2 situations this dual-stack assumption leaves a cluster unusable and is confusing for users. Assuming ordered precedence seems legit, since GCE has this notion of primaries and secondaries too ... we should talk to find a solution but leaving it as "worked as intended" does not sound correct

I just realized this will move to the cloud-controller-amanger so maybe is not worth the effort to fix it here

@aojea aojea closed this May 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bowei bowei Awaiting requested review from bowei

@MrHohn MrHohn Awaiting requested review from MrHohn

Assignees

@bowei bowei

@wojtek-t wojtek-t

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/bug Categorizes issue or PR as related to a bug. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/apps Categorizes an issue or PR as relevant to SIG Apps. sig/network Categorizes an issue or PR as relevant to SIG Network. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

ControlPlane node is not ready in scalability tests when run on GCE
5 participants
@aojea @k8s-ci-robot @basantsa1989 @wojtek-t @bowei