-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Use calico_pool_blocksize from cluster when existing #10516
Use calico_pool_blocksize from cluster when existing #10516
Conversation
Hi @VannTen. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
b72b6c2
to
b3e84a6
Compare
The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
b3e84a6
to
6439d0c
Compare
/ok-to-test |
HI @cyclinder |
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.
thanks, I think it's a good idea.
_calico_blocksize: > | ||
{ | ||
"spec": { | ||
"blockSize": {{ (_calico_pool_cmd.stdout | from_json).spec.blockSize }} |
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.
Do we need also to merge the CIDR? update the CIDR of the existing ippool is dangerous.
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.
I'd say it depends on whether we consider changing the cidr as part of the playbook a valid use-case, and what's the "default history" of the cidr
attribute is (I came across this little inconvenience because the blockSize default changed apparently, because those clusters never had an explicit setting in their inventory for that).
Changing the blockSize is definitely out of scope, because it's simply impossible, since it's immutable in the IPPool. The cidr, I don't know.
Overall, I would err on the side on keeping it that way, for minimal changes (which might be breaking someone workflow => can't be the case for blockSize
).
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.
I would err on the side on keeping it that way, for minimal changes
Agree, It's ok for me.
In your case, the default blocksize was not used when the cluster was installed, but the default value was still used when upgrading the cluster, right? It makes sense that blocksize is immutable so we don't make it be updated.
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.
Yeah, I think that's how it went. The clusters were installed some years ago (not by me), and I think for some it was the calico default value for blocksize (26) and for others... well I don't really know ^^.
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.
I used to change the blockSize of calico from 24 to 26(#9055) because it was consistent with the upstream of calico. maybe your cluster was created before this PR merged.
/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.
@VannTen Thank you for the PR 👍
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, VannTen 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 |
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
…#10516) The blockSize attribute from Calico IPPool resources cannot be changed once set [1]. Consequently, we use the one currently defined when configuring the existing IPPool, avoiding upgrade errors by trying to change it. In particular, this can be useful when calico_pool_blocksize default changes in kubespray, which would otherwise force users to add an explicit setting to their inventories. [1]: https://docs.tigera.io/calico/latest/reference/resources/ippool#spec
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The blockSize attribute from Calico IPPool resources cannot be changed
once set 1. Consequently, we use the one currently defined when
configuring the existing IPPool, avoiding upgrade errors by trying to
change it.
In particular, this can be useful when calico_pool_blocksize default
changes in kubespray, which would otherwise force users to add an
explicit setting to their inventories.
Special notes for your reviewer:
We faced that problem while upgrading our cluster (to 2.19.1). We have some clusters which have different blockSize (for reasons unclear to me), and while setting the correct value (instead of the default) is not that long, it's still a bit annoying.
Does this PR introduce a user-facing change?: