Output variables are available before nodes are up

[kevensen]

In most (if not all) cases, the output variables are available before the nodes of the cluster are up. For example, the endpoint variable is populated as soon as it is known to Terraform (makes sense).

It would be helpful to not populate these variables until the nodes are up in a node pool. Or add an output variable that is along the lines of pods_schedualable to provide a check whether or not other resources can be deployed in the cluster.

[morgante]

I don't know if this is possible from the API endpoint.

[kevensen]

Would love feedback on this thought. The GKE REST API provides a status in the response object. Would it be reasonable to set a variable (e.g. module.gke.ready) if the state is RUNNING?

[kevensen]

Or have the output variable be module.gke.state?

[morgante]

One of the issues is that I think the cluster actually slips between RUNNING and RECONCILING as it spins up node pools so we can't simply wait for it to become 'RUNNING' the first time.

[kevensen]

boo

[morgante]

That being said, I think added depends_on to the outputs similar to the internal dependencies should help make this a bit better: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/master/masq.tf#L43

[kevensen]

How would that work?

output variable --> [triggered in] --> null resource --> [depends on] --> all that

[kevensen]

nm. I think I figured it out.

https://www.terraform.io/docs/configuration/outputs.html#depends_on-explicit-output-dependencies

[morgante]

Yeah, do you think you could open a PR?

[kevensen]

I am working on it as we speak

[kevensen]

I am thinking of making the endpoint output variable "depend on" these resources. Do you think we ought make another variable?

[morgante]

Probably all the variables should, but you can start with whichever ones are important for your use case.

[kevensen]

understood.

[kevensen]

merged and closed