Expose more variables in service catalog modules from the get-go

[umm0n]

It's often the case for us, when using service catalog modules, that we can't use a certain feature because it's not supported in the code. However, those features are often supported in the underlying repos the service catalog uses; they simply aren't exposed. Here's one recent example.

We understand the service catalog modules are intended to provide a rather opinionated, concise, straightforward path to deployment, but more often than not, we feel these constraints are detrimental rather than beneficial. This is particularly relevant as the complexity of our organization grows.

It would be ideal if service catalog modules exposed more, if not all, of the variables supported in the underlying groundwork repos. And to take it even further, it would be ideal if they exposed the majority of the variables supported by terraform itself. We love the work you do, but if I had to name one, this is probably our number one "gripe" with the platform.

---

Tracked in ticket #110403

[josh-padnick]

Hello! Gruntwork Chief Product officer here. First, thanks for sharing your feedback. It's greatly appreciated. 👍

I'd like to better understand the problem as a starting point. It sounds like you value the convenience of the service catalog modules, but then feel constrained by the limited number of variables they expose. Let's say we set up some kind of process or automation that exposed literally 100% of the relevant underlying module variables in the service catalog modules. Would that address your problem? Or would there still be other friction points with using the service catalog?

As one example, suppose that we gave you a tool to create our own modules, but built out of the Gruntwork building blocks. So rather than Gruntwork maintain a canonical module that you reference, we could maintain a canonical code template whose underlying building blocks would frequently get updated. That would you give you more control, but less convenience because when non-trivial updates come out, you'd now be responsible for incorporating those into your module. Still, would that be a better fit?

Also, could you clarify what you mean by this?

And to take it even further, it would be ideal if they exposed the majority of the variables supported by terraform itself.

Sorry for all the questions, but you're the authority in the problem, and I'd like to make sure I have a full understanding of that before reaching any conclusions on how to solve it.

[umm0n]

Hello Josh!

Let's say we set up some kind of process or automation that exposed literally 100% of the relevant underlying module variables in the service catalog modules. Would that address your problem? Or would there still be other friction points with using the service catalog?

Absolutely, that would address our problem 100%.

As one example, suppose that we gave you a tool to create our own modules, but built out of the Gruntwork building blocks. So rather than Gruntwork maintain a canonical module that you reference, we could maintain a canonical code template whose underlying building blocks would frequently get updated. That would you give you more control, but less convenience because when non-trivial updates come out, you'd now be responsible for incorporating those into your module. Still, would that be a better fit?

Not sure I would trade the convenience of the service catalog for that added flexibility, at least for most of our use cases. Honestly, simply exposing all underlying module variables in the service catalog would be sufficient, as you mentioned before.

Perhaps you could mantain an additional extra-variables.tf file of some sort, that way you can keep an opinionated, dialed down variables.tf file that won't overwhelm people looking for simplicity, but still have the other file to provide flexibility for those who require more. Just a thought.

Also, could you clarify what you mean by this?

You can disregard that, I think we nailed the "issue".

[josh-padnick]

Ooh, that extra-variables.tf file is a really nice idea.

@ebeneliason @zachreborn @arsci We should consider prioritizing something here. Eben, could you add something to our backlog for prioritization review?