This message was deleted.

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?

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?

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?

Right. 🙂 So what does that look like in a Pulumi program?

dunno! ¯\_(ツ)_/¯

OK 😄 Well that was my question

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

The problem is generic, I just used App Service as an example.

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

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.

Gotcha

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.

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

Hmm… ok @clever-sunset-76585, thank you.

Cyclic dependencies are not supported. The need for them usually means rigid resource model (e.g. app setting could be a separate resource).

@tall-librarian-49374 yes, indeed. That’s why I chose App Service as an example actually.

Terraform could totally do something about that

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.

Yes, that’s true