-
Notifications
You must be signed in to change notification settings - Fork 86
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
Unable to install Flux in k8s 1.19 #241
Comments
Did the kubectl provider switched to server-side apply? |
@stefanprodan I use the official Kubernetes provider for Terraform. How can I switch to the server-side apply? |
@mvoitko I'm unsure of how to answer that, but YSK that Flux 0.26 is coming soon which drops support for K8s 1.19. It does look like terraform-provider-kubernetes is migrating/migrated to Server-Side Apply according to these notes. It seems to have been this way for at least 6 months: hashicorp/terraform-provider-kubernetes@fc8ad5f |
@stefanprodan @kingdonb @phillebaba I have dived into the release notes and the code. The Kubernetes provider is ok and
The problem appeared because the more strict validation for CRD was introduced in k8s |
@stefanprodan Could you please tell me what's the flow of the release? When will be the next release of the controllers and when terraform-rpovider-flux could do the next release with the new versions of the controllers? |
Next release will drop support for Kubernetes 1.19 as it has reached end-of-life months ago. Flux 0.26.0 release can be tracked here: fluxcd/flux2#2308 |
@stefanprodan But can I use some specific commit from master for the terraform provider flux? The thing is that I want to deploy kubeflow with manifests with flux. And the kubeflow supports only k8s 1.19. The flux installation is broken for k8s 1.19. |
The flux installation is not broken on 1.19, this provider uses kubectl not the official Kubernetes provider for Terraform. See the examples please https://github.com/fluxcd/terraform-provider-flux/blob/main/examples/github/main.tf#L31 |
Hi @mvoitko 👋 I hope you are doing well! As part of our ongoing effort to maintain and improve the quality of our project, I've been reviewing open issues and came across the one you've reported. First off, thank you for taking the time to contribute by reporting this issue; your input is crucial to us. Upon reviewing the details of your issue, I noticed that it involves the use of a resource or feature that has yet to be supported since the 1.0.0 release of our project, which was approximately 9 months ago. This might be a key factor in the challenges you're experiencing. We understand that changes and deprecations can impact your work, and we're here to help navigate these transitions. If there are specific reasons you've continued using this unsupported resource or if there's any way we can assist in migrating to a supported alternative, please let us know. Additionally, to ensure the efficient management of our issue tracker and to focus on issues that are actively affecting our community, we have implemented a policy for issues that remain inactive. If there is no activity on this issue within the next 3 weeks, we will consider the issue inactive and close it for you. This doesn't mean your issue is not important to us, but rather that we aim to keep our focus on actively pursued concerns. Of course, if the issue continues or if you have further updates in the future, feel free to reopen the issue or create a new one. Thank you once again for your contribution to our project. Your feedback not only helps us improve but also supports the broader community in overcoming similar challenges. We look forward to hearing from you and hope to resolve any outstanding concerns together. Best regards, Steve |
Kubenetes version: 1.19
Suggested solution is to specify the default value for protocol as mentioned in
kubernetes-sigs/structured-merge-diff#130
The text was updated successfully, but these errors were encountered: