4 ms·

It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products. I remember when a colle

It’s a symbolic step but hopefully goes a long way to convince various decision makers about long term viability of hashicorp products. I remember when a colleague didn’t want to use TF from an unknown company in his saas. His company is now gone but terraform is alive and widely used.

pizza234 5y ago
I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features. For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had we started using TF now, we wouldn't have had this problem. But of course, nobody's at fault here.
- darkwater 5y ago
  module.count was added in TF 0.13 [1] but yet still what you say makes totally sense, and I really welcome a 1.0 release hoping that there won't be any more disruptive changes and revolutions in the DSL, because yeah, you definitely need to invest a lot of time in refactors/rewrites to keep it up with newer Terraform versions and language features. [1] https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG.md https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG....
- hnlmorg 5y ago
  I think the biggest problem is that the state file is a JSON blob who's hierarchy directly maps the structure of your code in Terraform. This makes refactoring a nightmare as you're continually having to fudge the state file and/or declare that a resource defined in code relates to a resource defined in state (I forget the exact CLI flag you pass to do this off hand).
  - pizza234 5y ago
    Yes, I think is reflected into our situation. For our TF codebase, specifically, it would be greate to deduplicate modules (which is something that couldn't be done some time ago), but there is no simple way of, say, creating a new module, and slowly migrate resources into it. In particular (AFAIK), there are no tools for moving stuff around, so in addition to the TF restructuring, one also need to write scripts to manually move the resources.
    - marenkay 5y ago
      terraform state mv is working for this but yeah, a migration path in some defined way would certainly be preferred.
    - 3np 5y ago
      You're looking for 'terraform state mv'. After my first handful of these it's now as natural as refactoring and moving modules in any code-base, almost. Or if it's a big mess you can 'rm' and 'import'.
      - pizza234 5y ago
        I'm aware one can rename the resources via mv. But when multiple self-standing modules with hundreds/thousands of resources in each have to be merged into an array of modules, it's a big work. I'm not even sure that the new resource address can be figured out, and the list of resources can be search/replaced in order to produce a single renaming (mv'ing) script. Even if this was possible, it would likely require: - either each module to be moved monolithically, which is risky (e.g. data sources may break, since there's no referential integrity) and requires a fully designed and implemented destination module (carrying two different representations of the resources contained in each module). - or, and I don't know if this works in real world, creating an structured but empty destination module, and slowly moving resources from the leaves down to the root. this is a lot of work, and probably requires a very large amount of references to be carried cross-modules. Big refactorings are a difficult in any language/framework, but in TF are particularly so, because referencing between resources is rigid, so it's hard to move small parts and their references. Doing this is Chef is much simpler, since resource name and address matches and it's under control of the developer (but Chef has a different approach, of course).

pizza234 5y ago

I think it's a very meaningful step, as it signals maturity - the platform changed significantly over the last couple of years, and it's (unfortunately but necessary) a pain to perform some upgrades, or at least, to redesign according to the new features. For example, we can't make full use of the modules flexibility which I think was added to 0.15 (module.kount anybody? :)), because it's a very painful process. Had we started using TF now, we wouldn't have had this problem. But of course, nobody's at fault here.

darkwater 5y ago
module.count was added in TF 0.13 [1] but yet still what you say makes totally sense, and I really welcome a 1.0 release hoping that there won't be any more disruptive changes and revolutions in the DSL, because yeah, you definitely need to invest a lot of time in refactors/rewrites to keep it up with newer Terraform versions and language features. [1] https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG.md https://github.com/hashicorp/terraform/blob/v0.13/CHANGELOG....
hnlmorg 5y ago
I think the biggest problem is that the state file is a JSON blob who's hierarchy directly maps the structure of your code in Terraform. This makes refactoring a nightmare as you're continually having to fudge the state file and/or declare that a resource defined in code relates to a resource defined in state (I forget the exact CLI flag you pass to do this off hand).
- pizza234 5y ago
  Yes, I think is reflected into our situation. For our TF codebase, specifically, it would be greate to deduplicate modules (which is something that couldn't be done some time ago), but there is no simple way of, say, creating a new module, and slowly migrate resources into it. In particular (AFAIK), there are no tools for moving stuff around, so in addition to the TF restructuring, one also need to write scripts to manually move the resources.
  - marenkay 5y ago
    terraform state mv is working for this but yeah, a migration path in some defined way would certainly be preferred.
  - 3np 5y ago
    You're looking for 'terraform state mv'. After my first handful of these it's now as natural as refactoring and moving modules in any code-base, almost. Or if it's a big mess you can 'rm' and 'import'.
    - pizza234 5y ago
      I'm aware one can rename the resources via mv. But when multiple self-standing modules with hundreds/thousands of resources in each have to be merged into an array of modules, it's a big work. I'm not even sure that the new resource address can be figured out, and the list of resources can be search/replaced in order to produce a single renaming (mv'ing) script. Even if this was possible, it would likely require: - either each module to be moved monolithically, which is risky (e.g. data sources may break, since there's no referential integrity) and requires a fully designed and implemented destination module (carrying two different representations of the resources contained in each module). - or, and I don't know if this works in real world, creating an structured but empty destination module, and slowly moving resources from the leaves down to the root. this is a lot of work, and probably requires a very large amount of references to be carried cross-modules. Big refactorings are a difficult in any language/framework, but in TF are particularly so, because referencing between resources is rigid, so it's hard to move small parts and their references. Doing this is Chef is much simpler, since resource name and address matches and it's under control of the developer (but Chef has a different approach, of course).