-
-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Update to support kubernetes provider v2 #93
Conversation
@@ -355,8 +355,8 @@ Available targets: | |||
| environment | Environment, e.g. 'uw2', 'us-west-2', OR 'prod', 'staging', 'dev', 'UAT' | `string` | `null` | no | | |||
| id\_length\_limit | Limit `id` to this many characters.<br>Set to `0` for unlimited length.<br>Set to `null` for default, which is `0`.<br>Does not affect `id_full`. | `number` | `null` | no | | |||
| kubernetes\_config\_map\_ignore\_role\_changes | Set to `true` to ignore IAM role changes in the Kubernetes Auth ConfigMap | `bool` | `true` | no | | |||
| kubernetes\_config\_path | Path to the kube config file. Defaults to `~/.kube/config` | `string` | `"~/.kube/config"` | no | |
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.
Due to provider behavior changes, this value no longer has a default. Previously, if load_config_file
, was false, this config was ignored. Updating the default to match the provider's maintains the same behavior as before.
/test all |
Just hit this a couple minutes ago 😄 thanks for opening a PR |
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 am not convinced this is really backwards compatible. The new Kubernetes provider drops support for KUBECONFIG
, load_config_file
, and the default ~/.kube/config
as a default config_path
. What will this break, how will clients fix it?
@Nuru For those that are loading a config file, chances are good they're already providing a path, and if they're not and relying on the default, the v2 provider would be a breaking change for them anyway. So for that segment of users, they'll have a v2 breaking change and just need to explicitly provide their path. Leaving the default path in the variable will break this for everyone who previously had |
This pull request is now in conflict. Could you fix it @woz5999? 🙏 |
This Pull Request has been updated, so we're dismissing all reviews.
/test all |
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 think we can make this backwards compatible instead. Hang on please while I investigate.
This Pull Request has been updated, so we're dismissing all reviews.
/test all @woz5999 after consulting with the team, we decide just to remove these variables altogether as they have no good use case for this module, and then move forward with the Kubernetes provider version pin |
Breaking Changes
kubernetes
Terraform provider>= 2.0
, which introduced breaking changes to the provider. This module has made additional breaking changes in response.kubernetes_load_config_file
has been removed because the correspondingload_config_file
option to the Kubernetes provider has been removed in provider version 2.0.kubernetes_config_path
has been removed as its use case (Allow k8s config file load #77, feat: add k8s provider config variables #78) was for one-time migration and in general we want to discourage its use. If needed anyway, a value can be provided via theKUBE_CONFIG_PATHS
environment variable. If a more compelling use case is made, it will be a non-breaking change to restore it.required_providers
blockwhat
why
references