4 ms·

I agree with this in general, but I think there’s room for more programmatic ways of calculating what the desired state is in tools like Terraform. There are al

I agree with this in general, but I think there’s room for more programmatic ways of calculating what the desired state is in tools like Terraform. There are already a lot of built-ins in terraform that are deterministic but procedural ways of calculating what the state is, without infecting the declarative nature of the reconciliation process.

nicois 8y ago
We also were frustrated at the verboseness and vagaries of the terraform syntax. We ended up preprocessing them using jinja2, injecting our variables via its context, and using its cleaner syntax for expressing conditions, loops, etc. Now we have the best of both worlds.
- pm90 8y ago
  ... until your jinja templating breaks for some obscure reason, or the underlying terraform resource upgrades (they follow the provider api after all), or if you need to do some state surgery and partition one terraform state into multiple ones, or until you want to import resources into the generated terraform or.... Apologies, I don't mean to be a downer. But... you're making your present life easier but making the code harder to maintain for future maintainers of your codebase.
  - detaro 8y ago
    What's the more maintainable alternative? Is writing repeated constructs etc out individually really more maintainable, or are you referring to other ways of getting these things reduced?
    - pm90 8y ago
      Just plain terraform modules, for now. I’m eagerly awaiting 0.12 so the language would have similar features as jinja templating.
    - nitelord 8y ago
      I highly recommend taking a look at the AWS CDK. It's a relatively new project, still in beta and hasn't gotten a lot of attention yet. It allows you to use real programming languages to generate Cloudformation templates. In my eyes this is the best of both worlds.
viraptor 8y ago
If that's what you want to achieve, you can generate the terraform files from any external system. Basically template it. That's what sparkleformation does for cloudformation stacks.

nicois 8y ago

We also were frustrated at the verboseness and vagaries of the terraform syntax. We ended up preprocessing them using jinja2, injecting our variables via its context, and using its cleaner syntax for expressing conditions, loops, etc. Now we have the best of both worlds.

pm90 8y ago
... until your jinja templating breaks for some obscure reason, or the underlying terraform resource upgrades (they follow the provider api after all), or if you need to do some state surgery and partition one terraform state into multiple ones, or until you want to import resources into the generated terraform or.... Apologies, I don't mean to be a downer. But... you're making your present life easier but making the code harder to maintain for future maintainers of your codebase.
- detaro 8y ago
  What's the more maintainable alternative? Is writing repeated constructs etc out individually really more maintainable, or are you referring to other ways of getting these things reduced?
  - pm90 8y ago
    Just plain terraform modules, for now. I’m eagerly awaiting 0.12 so the language would have similar features as jinja templating.
  - nitelord 8y ago
    I highly recommend taking a look at the AWS CDK. It's a relatively new project, still in beta and hasn't gotten a lot of attention yet. It allows you to use real programming languages to generate Cloudformation templates. In my eyes this is the best of both worlds.

viraptor 8y ago

If that's what you want to achieve, you can generate the terraform files from any external system. Basically template it. That's what sparkleformation does for cloudformation stacks.