update and pin kubernetes provider to >= 1.11.1

[EricHorst]

Re-visting #429, the upstream issue has been resolved with 1.11.1 (hashicorp/terraform-provider-kubernetes#759). This update sets the kubernetes provider version at or greater than the problematic version 1.11.0

Advancing to 1.11.1 also addresses hashicorp/terraform-provider-kubernetes/issues/787 which was broken in kubernetes 1.10 and 1.11 and prevented running Terraform in a pod, ie Atlantis.

[bharathkkb]

@EricHorst thanks for the contribution. I think we should add a <2.0.0 constraint because there maybe breaking changes. Thoughts @morgante?

[EricHorst]

@bharathkkb I considered that. My reasoning was that prior to the version being pinned to 1.10, there was no version constraint so when undoing that I returned to effectively no version constraint (upward) except for the very specific one required.

[morgante]

Unfortunately my confidence in the stability of the Kubernetes provider is shaken by releasing a breaking change in a major version. In order to allow a wider variety of setups while preventing known issues, I suggest we use ~> 1.10.0, ~> 1.11.1 as the version constraint.

[EricHorst]

Incorporated @morgante suggested constraint. An enlightened solution I probably wouldn't have come up with!
And I concur about reduced confidence in Kubernetes provider based on both the breaking issues mentioned.

[EricHorst]

Whoops. I trusted and did not test that this would work. Looking...

[EricHorst]

This is more version exploration than I've done before. It seems that while compound expressions are allowed, it doesn't work when the expression results in two disjoint intervals.

Terraform doesn't find a suitable version for any of these:
~> 1.10.0, ~> 1.11.1
>= 1.10.0, < 1.11, >= 1.11.1, < 1.12
~> 1.10.0, > 1.11

How do you feel about simply != 1.11.0 which does work?

[EricHorst]

Trying to make this palatable and pass tests.

Terraform did not like the other compound forms but is happy with a compound of != 1.11.0, < 2.0.0. This will avoid version 1.11.0 that was reported problematic in #429 but allow us to use either the fallback 1.10.0 or the fixed 1.11.1. And also keep us below 2.0.0 as requested by @bharathkkb.

[morgante]

I think we should still pin to at least 1.10. How about ~> 1.10, ~= 1.11.0?

[EricHorst]

@morgante your last suggestion doesn't work as typed. ~> 1.10 means >= 1.10, < 2.0 which renders the ~= 1.11.0 meaningless.

I think you probably meant to type ~> 1.10, != 1.11.0 and in retrospect I think that is exactly what we want based on the conversation in this PR. In master it is restrictively pinned to 1.10.x. It is desired to have >= 1.10 and < 2.0 but avoid the known bad version 1.11.0 The last commit implements this.

[EricHorst]

Closed/reopened not paying attention to what tab I was in, not trying to be annoying.

[morgante]

I think you probably meant to type ~> 1.10, != 1.11.0 and in retrospect I think that is exactly what we want based on the conversation in this PR

Indeed I did, sorry for the typo!

[EricHorst]

We're seeing sporadic problems with Terraform Registry on init here locally so I assume that's why the triggered test here failed after I bumped it by closing and opening. It was passing before What's the easiest way to retrigger the test?

[morgante]

I just manually queued a test run. You can also push an (empty) commit to force it as well.

[bharathkkb]

@EricHorst @morgante test failures are due to a change in the proto for GKE and the way we were asserting eq; I opened an issue #454 and fix is in PR #442