Loren Gordon

I think parsing descriptions is bound to be flaky. I'd maybe suggest a custom "deprecation" provider, to maintain compatibility with Hashicorp Terraform.

Just the way providers work. Write a resource with the behavior and workflow you want. Something like, take the deprecated variable value and an deprecation message as an input, generate...

This issue is about variable deprecation, not outputs. That would be different anyway. Would probably want the warning to occur when a user _accesses_ the deprecated output. That's going to...

I had transferred the related terraform issue earlier, https://github.com/opentofu/opentofu/issues/299, but the content was wiped out when external references were removed. I'll close that issue in favor of this one.

This makes a lot of sense to me. Goes along with the other recent changes to bring `state` commands into configuration, instead of modifying state outside of the plan/apply workflow....

For a UX, it might be as simple as: ``` replace_provider { from = ... to = ... } ``` which also aligns well with the current help text of...

Another use case... Say Hashicorp BUSLs the providers they own, and opentofu forks them. Now we need a way to transition state from the namespace `hashicorp/aws` to `opentofu/aws`...

I'd be curious whether exposing retry mechanisms in a more general way might also do the trick. Something to the effect of, do X at a time, but if you...

Yes they do, and some providers for some resources do have specific/enhanced retry handling. But I'm talking about a core feature. Similar to the various lifecycle options.

:shrug: take it or leave it. Just another idea that addresses the underlying issue at hand, which is the failure, not really the need for a delay or sequential execution...