This message was deleted.
# general
s
This message was deleted.
b
Also, I encapsulated provisioning of the A and B into the ComponentResource in hope that pulumi would be then treating it as an atomic object and would delete all its parts at once before provisioning new ones but it doesn't seem to be the case
w
There is a “dependsOn” resource option you can pass to B that may solve your problem. https://www.pulumi.com/docs/intro/concepts/resources/#options
b
@bland-shoe-75993 as per my experimenting it seems that dependsOn doesnt cause dependent resources to be removed first. In my opinion the dependsOn has effect only when provisioning to provision the resources in the right order
w
@boundless-angle-56560 Hmmm. You should see the dependsOn being taken into account for destroy as well. Here’s a bit of test code:
Copy code
import * as aws from "@pulumi/aws";
import * as azure from "@pulumi/azure";

const bucket = new aws.s3.Bucket("mitch-bucket");
const resourceGroup = new azure.core.ResourceGroup("mitch-rg",
  {},
  {dependsOn: bucket}
)
Azure takes a bit of time to delete a resource group, so when I destroy this stack, I see that the AWS bucket stays around until the Azure resource group is deleted. If I remove the
dependsOn
bit, the bucket gets deleted in parallel with the resource group and so the bucket is deleted immediately while the RG takes a bit of time.
b
@witty-candle-66007 chmm, I will retest and report back
@witty-candle-66007 btw in my situation I don't do destroy. I do updating already provisioned resource. In my case I update data for the resource A, pulumi decides that A needs a replacement but in this case doesn't delete the B first