Terraform-provider-kubernetes: Startup probes on statefulset never apply

[weeco]

Terraform Version and Provider Version

Terraform v0.13.5

• provider registry.terraform.io/gavinbunney/kubectl v1.9.1
• provider registry.terraform.io/hashicorp/google v3.42.0
• provider registry.terraform.io/hashicorp/kubernetes v1.13.3
• provider registry.terraform.io/hashicorp/local v2.0.0
• provider registry.terraform.io/hashicorp/random v2.3.1

Affected Resource(s)

Terraform Configuration Files

# Add a startup probe to the containerspec inside of a stateful set
          startup_probe {
            tcp_socket {
              port = 9092
            }
            tcp_socket {
              port = 9093
            }
            tcp_socket {
              port = 9094
            }
            initial_delay_seconds = 30
            timeout_seconds       = 1
          }

Expected Behavior

I expected that a startup_probe will be added to the existing statefulset. It is shown in the plan and the apply diff. When I apply this, the cli also say that the change was complete/succesful, however the startup probe is actually never added. The next apply/plan the exact same diff is shown again.

Actual Behavior

The startup probe is not added to the statefulset set container

Steps to Reproduce

a startup_probe to an already (with Terraform) deployed stateful set

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[sbunce]

I just hit this one too. I learned that this is a Kube issue. It accepts the spec and silently doesn't apply the startupProbe if the feature isn't enabled. This feature is only enabled by default in Kube 1.18 (when the feature enters beta). To get access to this feature in < Kube 1.18 you have to specify a "StartupProbe" feature flag. We don't have this enabled on our cluster, so this silently fails.

https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

It's really a bummer that this silently fails like this instead of having an error.

[jrhouston]

This is a problem in some other places to like ttl_seconds_after_finished on the job resource. It's annoying because there isn't an easy way for the provider to check which feature gates are actually switched on so we could warn you about this.

The only way to do it at the moment is to actually grab the args for the apiserver and check for the --feature-gates flag, which probably isn't going to work for clusters with managed control planes.