pulumi: Allow applications to handle "not found" errors from `.get()`
Problem Scenario
It can be common to need to query for an existing resource and if it doesn’t exist then take some other action. Currently Pulumi’s <resource>.get()
methods halt Pulumi execution without throwing an error that the user/application can catch and react to.
Suggestion
The results or error from <resource>.get()
calls and data sources should be catchable so that users can take other actions as a result.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 62
- Comments: 26 (8 by maintainers)
+1 any updates on this one? Really need the get to be “catchable”. The scenario I want to accomplish is as follows
Same issue here with an attempt to create k8s namespace.
Is there any progress on this one?
Give the above & https://github.com/pulumi/pulumi/issues/11275 I think we should reopen this. We’ll need to be careful to explain that this can not be used for “try get or create” logic, but it sounds like it has other applications as well.
For invokes (“data sources”), you can do this today:
That is, the error is bubbled up through the promise error handler (and as an exception in
async/await
code).Another example:
This is not true for
.get()
calls though (which is what I will continue to track with this issue).Is there any way to lookup for the existence of a resource without the function actually throwing an error? For context - I am trying to get
getUserAssignedIdentityOutput
but it errors out and the error seems to be not catchable. https://www.pulumi.com/registry/packages/azure-native/api-docs/managedidentity/getuserassignedidentity/+1
Scenario: run a Lambda Function to create schema on an RDS Cluster only if the Cluster hasn’t existed before.
I have a similar use case which cannot be covered with “create if not exists” pattern.
I have a database deployed with helm, and I have to read out the secrets created by the chart to get the connection password (which is then passed to other resources I wanted to create).
+1 for that
After an investigation in #10883 and discussing the implications with @Frassle we are leaning to close this issue and recommend other Pulumi mechanisms for the use cases here:
A lot of the readers coming here are interested in handling the error from get to create a resource if it does not already exist. #3388 will provide a much better way to address this scenario.
There is a workaround available now before #3388 ships. Providers expose data sources allowing the program to query for existence of resources in the cloud. For an example see getSecurityGroups in AWS. The advantage of these compared to
Resource.get()
is that they do not interfere with Pulumi state.For use cases that need to run some logic when a resource actually gets created, lifecycle hooks (specifically create hooks) as specified in #1691 seem to be the preferable mechanism.
Technicalities from the #10338 exploration:
Explored building conditional creation on top of recoverable Resource.get in #10883. While it can be made to work, there are some challenges in this approach to get previews and repeated updates working correctly.
The engine sees Resource.tryGet()…new Resource() as two separate operations and not an atomic operation, confusing URN uniqueness tracking, requiring workarounds
Repeated update has to edit the resource’s record in the state to switch from the
new Resource
style record to aResource.get
style record (external: true), requiring workarounds to get empty previews and avoid UI glitchesExpereincing the same issue. Would like to create an AWS Config recorder (limited to 1 per account per region) and want to check if one already exists before attempting to create one.