Implement create_when_missing

[raphaelfff]

Implement the recommendation in #33633 (comment)

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[github-actions]

Changelog Warning

Currently this PR would target a v1.13 release. Please add a changelog entry for in the .changes/v1.13 folder, or discuss which release you'd like to target with your reviewer. If you believe this change does not need a changelog entry, please add the 'no-changelog-needed' label.

[jbardin]

Hi @raphaelfff,

I don't think there's been any team conversation about this, so there is not currently a recommended solution to implement. More broadly, this feature is going to require protocol changes for this to work correctly, which is the reason it's not possible to do at this time. The ImportResourceState call is almost always an entirely offline transformation, and will usually succeed regardless of whether the remote instance exists or not.

Once we have an updated protocol in place for import, in coordination with the provider development teams, than we can implement a solution to this feature request.

[raphaelfff]

I was going off of the comment linked, this has been stalled for a while now, and i have a pretty strong need for this feature (seems like I'm not alone!)
How do we move that feature forward ?

[jbardin]

It would first require working with the plugin development teams to add a new protocol to communicate the additional information, then wait for the major public providers to implement the functionality themselves for each resource to be imported. There may be other options available to reach the same end goal however, but that all still requires internal collaboration and development before we might see any changes. Once there is a change in status, the linked issue will be updated.

[raphaelfff]

Why do we need some extra plugin dev?

1. During plan phase, call the provider.Read
2. if this fails, run import as usual
3. if it succeeds, ignore the import

What am i missing here ?

[jbardin]

The protocol changes are really because the ImportResourceState protocol itself is a holdover from early Terraform, and we currently can't follow that protocol fully as it is. Updating the import process something that needs to be addressed for future improvements anyway.

The provider has no context as to why Read is being called, nor can it return a specific error indicating why the read may have failed, any failure is a fatal error. That means we have to guess, but perhaps that does work the case of read with import.

The internal work around that possibility is already in progress. Another aspect of the idea is that the feature needs to be useful for more than a single hard-coded identifier. Since most single instance data sources can't return an ID (and have no access to expose the new identity), there is no reusable way to create a config that will "import if doesn't exist". A new feature to list existing instances is already underway, and may provide the API access we need.

[raphaelfff]

Hum i see, is there a ticket tracking this? (trying to gauge an ETA, because i m really stuck on this atm...)

[raphaelfff]

Actually in my plan i meant to say: call the provider.Import, not .Read, to be able to support the identity workflow

[jbardin]

The linked issue is what tracks the feature externally. The IBM/Hashicorp roadmaps are not publicly available.

Your reference to the Read call was actually closer to a solution, because the Read call is the first point where the provider must make remote API calls. The Import call doesn't fail, because it's implemented entirely offline for nearly every resource, and we can't really change that without a corresponding change in protocol. But the main sticking point is still the fact that you need an identity to begin with to even start the process, and currently that means a hardcoded solution which isn't reusable at all. If you need to hard-code the identity, then in almost every case you already know whether it exists or not and if it needs to be imported.

[raphaelfff]

Right, yeah i see, my use-case is really focused around k8s, i want to "get or create" a deployment, I can refer to it by id (which is namespace/name)
Sounds like I hit a rock.