This PR changes the way how Terraform (or the provider) handles the load process of the kubectl config.
Instead of failing, only a WARNING log message will be produced. I also noticed that the provider will only create an INFO log message, if the path to the kubectl config that was provided is non-existent. Thus I believe a 'malformed' (E.g. empty) config should not cause a failure.
Why?
This is useful in scenarios where the Terraform code itself will bootstrap the actual environment (In our case Rancher) and hence create the proper kubectl config somewhere in the middle of the Terraform execution.
Please find the initial converstation between @bonifaido and me below.
What's in this PR?
This PR changes the way how Terraform (or the provider) handles the load process of the kubectl config.
Instead of failing, only a WARNING log message will be produced. I also noticed that the provider will only create an INFO log message, if the path to the kubectl config that was provided is non-existent. Thus I believe a 'malformed' (E.g. empty) config should not cause a failure.
Why?
This is useful in scenarios where the Terraform code itself will bootstrap the actual environment (In our case Rancher) and hence create the proper kubectl config somewhere in the middle of the Terraform execution.
Checklist