Check for a terraform based replacement for this provider

[a-thaler]

Description
The provider is used in the Kyma CLI to provision a gardener cluster in a simple way for a demo/development scenarios. The indirection via terraform turned out to be cumbersome and for our scenario not bringing much value, and we replaced the setup with a simple implementation based on kubernetes API to just directly create a shoot spec.

With that the provider is not needed anymore in the kyma project. As the provider seem to be used outside of the project, we should see if there is a terraform specific replacement available.

The https://github.com/hashicorp/terraform-provider-kubernetes introduced CRD support a while ago and should in theory be a drop-in replacement.

Reasons

Attachments

[linuxbsdfreak]

@a-thaler I had tried the https://github.com/hashicorp/terraform-provider-kubernetes for launching a gardener shoot. However it worked with the alpha provider. I have used above provider and it does not work since the new provider tries to validate the CR and it does not work since there is no Shoot.yaml CR on the Seed using the Robot acccount. I am using the kubectl tf provider which works.

[a-thaler]

@linuxbsdfreak thanks a lot for the info. I remember that the alpha version had problems to detect the changeset properly, it treated some generated values on the remote side as a change to the local plan.
Do you encounter any problems with the kubectl provider? Are you talking about that one https://github.com/gavinbunney/terraform-provider-kubectl?
If not I will give it a try and then see if we officially deprecate the provider here.

[linuxbsdfreak]

@a-thaler . The https://github.com/gavinbunney/terraform-provider-kubectl provider works very well. However it does not have any support for querying the status field of a CR. I see that someone has implemented it. But the Maintainer of the plugin has not looked at it to get it officially in the provider

gavinbunney/terraform-provider-kubectl#41

[tobiscr]

@clebs - jfyi

[tuxgoose]

I am at bit torn on whether to look into updating this terraform or spend the cycles on landscaper. Currently we are using helm to deploy/maintain shoot yaml, and like @a-thaler mentioned use the apply in kubectl to create gardener clusters.

https://github.com/gardener/landscaper

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity.
Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[a-thaler]

It seems that there is no direct replacement available. It is recommended to work with the plain gardener resources directly. As the repository effectively is not maintained anymore, I will archive the repository to be most transparent on that.