-
Notifications
You must be signed in to change notification settings - Fork 152
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
Update Terraform Provider RKE to 1.3.11 #342
Comments
@annablender Following your comment, I ran an acceptance test with
Complete log file: test.log |
I also tested |
@annablender I locally applied the PR #337 and tested the provisionning of a one node cluster v1.23.6 (with etcd/control plane/worker roles). I managed to have a cluster up and running with either As a side note, enabling the option led me to the behavior described in rancher/rke#2938 so I added a comment with my findings. This is not related to this terraform provider in any way, but it may be a blocker in a near future for supporting 1.24. |
Great, thanks for testing this! |
Testing templateRoot causeUpdate Terraform RKE provider. What was fixed, or what changes have occurredTwo major changes have been done by community PRs (thank you open source!)
Areas or cases that should be tested
What areas could experience regressions ?Provisioning of standalone RKE clusters where Are the repro steps accurate/minimal ?Yes. |
Thanks for merging the related PRs |
@tmsdce Undergoing testing now 👍 |
Ticket #342 - Test Results [pt. 1] Pending test:
With Docker on a single-node instance: Verified on rancher
Screenshots: Additional Information:
|
Hi @Josh-Diamond, Does the It would allow users to deploy Kubernetes 1.22 and 1.23 safely with etcd v3.5.3 that is not subjected to this issue. Waiting for 1.24 can take a significant amount of time and I'd like to be able to upgrade my clusters to 1.23. This was the primary objective of this issue. Maybe I misunderstand the |
When can we expect an update for this? The provider has been locked to RKE Version 1.3.3 for 7-8 months now... we are currently locked to kubernetes v1.22.4-rancher1-1 and we can not use important etcd fixes because of the error above. |
We are releasing terraform provider RKE v1.3.2 today which uses RKE v1.3.11 (has kubernetes default version 1.23.6 and important etcd fixes that were mentioned). It should be published by Hashicorp by Monday. Once that is done, this issue can be retested @Josh-Diamond. |
I was too excited to wait after seeing the release; and used Thank you so much for this release! |
@Patricol wonderful! It's my pleasure to help. |
@annablender , will this release be pushed to terraform provider registry? https://registry.terraform.io/providers/rancher/rke/latest points to 1.3.1. Thanks! |
Comment says it will be pushed monday |
@Sartigan , @annablender it seems that did not happen on Monday. Are there plans to update terraform registry release? Thanks! |
FYI, 1.3.12 is available now. See https://registry.terraform.io/providers/rancher/rke/1.3.2 |
Ticket #342 - Test Results [cont. ] Pending test:
Verified with rke
Screenshots: Note: |
It looks like the failure of creating 1.24 cluster is expected, because terraform-provider-rke 1.3.2 embeds rke 1.3.11 which does not support 1.24. ( upcoming rke 1.3.13 will support 1.24) per the offline conversation with @Josh-Diamond , a new issue will be opened for tracking the support for 1.24. and this issue can be closed. |
Provisioning w/ k8s 1.24 will be tracked #354 |
Bump RKE version to 1.3.11
This version uses etcd v3.5.3 that includes the fix for etcd-io/etcd#13766. Due to this etcd bug, versions 1.3.9 was not recommended for production use.
I'm far form being a golang guru so I based my changes mainly on @VIKMSTR and @fe-ax already opened PRs. Since 1.3.10 ships with the etcd fix, I think we should concentrate on this PRs if that's OK for you @VIKMSTR and @fe-ax. I successfully built the provider and used it to build a test cluster with 3 control planes nodes and 2 workers. Still, I may have missed some key changes that should be made, so double checking would be wise ^^.
Changes include
The text was updated successfully, but these errors were encountered: