Enable questions to depend on prior answers

[josh-padnick]

Here's an excerpt from my vars.tf:

variable "kms_key_administrator_iam_arns" {
  description = "A list of the IAM ARNs (Users or Roles) that should have Administrator access to the KMS key created for this service. Administrators can manage the Key Policy and use it to encrypt/decrypt."
  default = "arn:aws:iam::1234567890:user/gus,arn:aws:iam::1234567890:user/jim,arn:aws:iam::1234567890:user/josh"
}

One issue with this is that this question / boilerplate variable should only appear if IsUsingKms is true.

[brikis98]

Yes, this would be great.

It's worth taking a step back and asking: is there an existing language of some sort that implements the features we're looking for in boilerplate? Obviously, we can define our own language on top of YAML, with types, and dependencies, and all that... But is it possible that there is some language we can leverage that has all of this built-in already?

[josh-padnick]

I'm not sure I follow...a declarative language that is opinionated enough about its domain that it has a built-in concept of dependencies?

I suppose imperative languages all support that with classes / structs and composition. Not sure how I'd feel about writing my boilerplate.scala file...I'll keep an open mind, though.

[brikis98]

Well, as an example, HCL as a language (or more accurately, the way Terraform uses HCL) supports the following:

1. Simple, declarative syntax
2. Types (string, int, bool, list, map)
3. Dependencies (explicit and implicit)
4. Interpolation (including a number of helpers)
5. Different types of providers (e.g to looking up the latest release, as per #8, sounds like a "data source" in Terraform parlance)

It's hard for me not to notice the overlap and wonder if there is a way to reuse it, or find another similar language that does what we need.

[josh-padnick]

Oh, that's a really interesting observation. You're right that there are a lot of parallels there! Maybe the thing to do is to try writing a boilerplate.yml as a boilerplate.hcl while taking the liberty to invent your own syntax as needed to support use cases.

While doing that, I'd be curious if you find yourself making use of the HCL support for dependencies, or if this just clutters things.

Also, I suppose some of the features you're mentioning above are "terraform", not just HCL (e.g. data providers). So that speaks a little to the dynamic between the language itself and the underlying interpretation engine.

[brikis98]

I actually suspect most of the items above (dependencies, interpolation, data source) are part of Terraform, not HCL. The point, however, is to think through whether any existing languages might be a good fit, rather than just inventing our own syntax. I'll think on this some more in the future.