Hi everyone! Is it possible to have a bi-direction...
# general
p
Hi everyone! Is it possible to have a bi-directional dependency between two resources in Pulumi? For example: • Some resource X needs an input from an Azure App Service • The Azure App Service needs an app setting created with an output value from resource X Manually (if I were to do everything in the Azure Portal) I would do this by creating the App Service first, then resource X, then going back to the App Service to add the app setting and its value from some property of resource X. Is the same possible in Pulumi?
h
Do you need resource x at initial creation time? Can you create default App Service, then resource x, then update App Service with resource x?
p
Yes, that’s what I’d like to do (i.e. the latter). But how do I do that in the same program, so that it all happens in the same
pulumi up
execution?
Or are you suggesting that I do it outside of Pulumi, as a separate step in my automation?
h
I guess what I’m getting at is do that all in the same program. If you can create an app service without resource x, create resource x, then update app service all in the same flow?
p
Right. 🙂 So what does that look like in a Pulumi program?
h
dunno! ¯\_(ツ)_/¯
p
OK 😄 Well that was my question
h
haha I just know some people have run into the chicken and the egg problem. I’ve done it with other things in AWS, just not familiar with app services
p
The problem is generic, I just used App Service as an example.
How did you do it for your AWS stuff?
h
I guess I’ll respond with another question: Is this for something specific? Because it depends on the resource. Some can be updated after created, others need everything up front
p
No, it’s not for something specific, the case I had in mind turned out to not be an issue after all. But it made me curious enough to want to know if this is possible, should I run into it again.
h
Gotcha
p
I guess I’m just struggling to imagine how you can create and update a resource is the same Pulumi program, given that all your program really does is construct a declaration tree. By the time Pulumi creates the resources, your program has long since exited already.
c
I don’t believe you could express that sort of dependency in Pulumi. I am not sure if there is a plan to add that capability either. However, if the Azure SDK supports updating the app setting of an App Service, you could wrap that in a Pulumi dynamic provider. This has the benefit of allowing you to detect changes in Resource X and take the appropriate action inside your dynamic provider, like updating the appsetting perhaps, if need be. Basically, you’ll have the ability to make API calls or really do anything else that your programming language supports (like invoking an external tool etc.) Dynamic providers are covered here: https://www.pulumi.com/docs/intro/concepts/programming-model/#dynamicproviders
p
Hmm… ok @clever-sunset-76585, thank you.
t
Cyclic dependencies are not supported. The need for them usually means rigid resource model (e.g. app setting could be a separate resource).
👍 1
p
@tall-librarian-49374 yes, indeed. That’s why I chose App Service as an example actually.
Its app settings are part of the resource properties, whereas perhaps they should be separate resources.
👍 1
But of course that’s defined at the ARM layer, not something either Terraform or Pulumi can do anything about.
t
Terraform could totally do something about that
They aren’t tied to ARM that heavily
p
Oh, didn’t know that. Guess that explains why their resource model seems so outdated. It seems I keep running into things where their model don’t map to Azure’s model.
t
Yes, that’s true