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

change: ip_range_services to optional value (#1949) #1989

Closed

Conversation

0Delta
Copy link
Contributor

@0Delta 0Delta commented Jul 4, 2024

resolve #1949

As of GKE version 1.29 and Autopilot 1.27, the service ip range is given a default of 34.118.224.0/20 per cluster.
Versions earlier than the specified version may be omitted, but will be rejected by the validator.

This change has a big impact, but has not been thoroughly discussed yet.
We hope to merge it after sufficient discussion and making the necessary corrections.

…#1949)

As of GKE version 1.29 and Autopilot 1.27, the service ip range is given a default of 34.118.224.0/20 per cluster.
Versions earlier than the specified version may be omitted, but will be rejected by the validator.
@0Delta 0Delta requested review from ericyz, gtsorbo and a team as code owners July 4, 2024 14:58
@0Delta 0Delta marked this pull request as draft July 4, 2024 15:03
@0Delta
Copy link
Contributor Author

0Delta commented Aug 7, 2024

Hi @apeabody , sorry for the sudden mention.
I'd like to gather opinions from others about this change.
Do you know of a good place to ask questions or users who can give their opinions?

@apeabody
Copy link
Contributor

apeabody commented Aug 7, 2024

Hi @apeabody , sorry for the sudden mention. I'd like to gather opinions from others about this change. Do you know of a good place to ask questions or users who can give their opinions?

Hi @0Delta! - Generally the related issue (e.g. #1949) or if implementation specific the PR itself are good options. However this PR is currently marked as draft, so won't be reviewed and less likely to get comments.

@0Delta
Copy link
Contributor Author

0Delta commented Aug 9, 2024

Thanks for the replies @apeabody.
This issue is now mostly a discussion about what to change, not the code implementation.
I'd like someone to provide advice on the original PR - do you know who would be the best person to do so?

@@ -147,7 +147,8 @@ variable "additional_ip_range_pods" {

variable "ip_range_services" {
type = string
description = "The _name_ of the secondary subnet range to use for services"
description = "The _name_ of the secondary subnet range to use for services. Omit to use default range."
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we clarify the new section to something similar to: If not provided the default 34.118.224.0/20 range will be used.

@apeabody
Copy link
Contributor

apeabody commented Aug 9, 2024

Thanks for the replies @apeabody. This issue is now mostly a discussion about what to change, not the code implementation. I'd like someone to provide advice on the original PR - do you know who would be the best person to do so?

Thanks @0Delta - Given the scope of the change, we'll need to include full test coverage. This can be done by updating at least one standard cluster and one autopilot cluster example to omit ip_range_services: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/tree/master/examples, and then validate the actual cluster in the associated example's test verify: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/tree/master/test/integration

Copy link

github-actions bot commented Oct 8, 2024

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days

@github-actions github-actions bot added the Stale label Oct 8, 2024
@github-actions github-actions bot closed this Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make service range optional
2 participants