ephemeral resource deferrals

[DanielMSchmidt]

Target Release

1.10.x

Draft CHANGELOG entry

ENHANCEMENTS

• Ephemeral Resources: Support providers deferring ephemeral resource open calls

[jbardin]

Another place to check is nodeExpandPlannableResource is currently bypassing the dynamicExpandPartial method. I have not looked to see if that method is relevant to ephemeral resources or not.

I wouldn't worry about exactly how that gets called right now (if we need it), all that dynamic expand code will get refactored to accommodate the ephemeral mode, since the current structure doesn't allow us to reuse the code during apply.

[jbardin]

I think this look good! Any refactoring we need in the plan nodes will probably come up again as I work on apply, since it needs to use the same codepaths as planning for ephemeral values.

[jbardin]

Don't need to refactor now, but would it make sense to just track all these in resourceInstancesDeferred? The address are all the same type and are differentiated by mode, but I don't know if it helps reduce code otherwise or not.

[DanielMSchmidt]

I discussed this with @liamcervante and we think that since we serialize the other deferred changes into the plan, differentiating them by mode alone would put us at more risk of accidentally not accounting for ephemeral resources. The extra effort we need to put in now does not feel major to warrant that risk.

[github-actions]

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.