Init -migrate-state

[chriskolenko]

Not sure when -migrate-state was added to Terraform, but in version 1.3.7 it exists.

If a PR was created with adding the extra option would it be accepted? Not sure how to make it forward or backward compatibility.

[chriskolenko]

Looks like this feature needs approval.

            Error: Can't ask approval for state migration when interactive input is disabled.
            
            Please remove the "-input=false" option and try again.

[radeksimko]

Hi @chriskolenko
We're generally not aiming to add support for 100% of all subcommands and flags, but primarily for the ones which make sense in automation.

As you already mentioned, this one requires interactive approval, and its nature generally suggests it's something a human would more likely do than an unattended script.

I can see the need to do some kind of mass-migration of many workspaces between backends though. Is that the use case you are hoping to satisfy? Have you considered writing a (simpler) one-off shell script for this?

[draeron]

see #279, it would greatly benefit this library to enable custom arguments to be provided when it's not supported off the shelf by the library.

Also migration path from 0.12 to 1.3.7 in automated fashion is nothing simple, especially when trying to migrate over 100 hundred workspace only to keep up in versioning.

[radeksimko]

To be completely transparent, one-off migration code written in Go is not a use case we have previously considered for this library, which may explain the lack of many other commands and flags.

In the interest of understanding the consumers and future enhancements:
Is there a particular reason you want to write these migration scripts in Go, rather than shell where it's also easier to return the interactive prompt to the user running the script?

Is it just familiarity with the language and/or unfamiliarity with shell?

Also migration path from 0.12 to 1.3.7 in automated fashion is nothing simple

I agree, but I don't see how one could fully and reliably automate the upgrade in any language, i.e. run it as unattended script? Hence my question about the use case and intentions.

We are open to changing the APIs, but we need to understand the use cases and address those more holistically than one command/flag at a time.

[draeron]

Is there a particular reason you want to write these migration scripts in Go, rather than shell where it's also easier to return the interactive prompt to the user running the script?

Same reasons you would use go for any other use case.

1. Debugging
2. Type Safety
3. Clarity
4. Testing

We also use go for rendering/generating terraform hcl (à la CDK i guess), so it makes sense to use the same language. Can't say about OP use case though.

[radeksimko]

@draeron Thank you, this is useful.

I still think that scripts cannot be completely reliable even with the use of upgrade* commands in various versions or custom HCL rendering/rewriting, or at least that reliability will highly depend on the complexity of the configuration being migrated.

That said it would probably still make sense to support this use case pragmatically for the simple/happy cases. I am not sure what implications it will have for init -migrate-state specifically though.

We'll need to bring this up with Terraform Core maintainers, as it wouldn't make much sense for the CLI to prevent automation by detecting interactive mode and rejecting -input=false and then terraform-exec somehow hacking around these limitations. There are also likely other commands and flags where this disconnect between assumptions exists.