No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

No, there is no concept of sub-resources. You can create a TG in any project and its LoadBalancerID can be from any other project.

You need to be aware of these dependencies, because they make actions like replacements harder to track. But that's all.

gotcha. would it be a possible circular though? let's say i got:
• project A with ALB
• project B with targetGroup
B imports ARN from A
does A need any awareness of B?

You should absolutely avoid that sort of thing. It is possible through a sequence of deployments, but you shouldn't do it.

i figured as much - how do I work around that?

It means you can't destroy either project's stacks without code changes and redeployments

What's the problem that requires a workaround?

I'm working on a microstack pattern outlined here -&gt; <https://blog.bitsrc.io/managing-micro-stacks-using-pulumi-87053eeb8678>

is this a fair resource? I havent found many [n] microstack examples in the pulumi example github

right now the problem is mostly my lack of comprehension :sweat_smile:

&gt; Pulumi introduced Micro-Stacks
I wonder where he got that from. There's nothing called "micro-stacks" in the Pulumi docs, afaik. It's just a project architecture.

Spend a little time designing your solution. Ensure all your dependencies follow a single direction, and nothing is circular. If you can do that, then you should have fewer problems.

i mean yeah the fundamental patterns of sane infra don't change regardless of the tool haha;

just curious about the implementation pattern more than anything

Also, it's not a biggy, but I recommend against using CallbackFunction. In my experience, mushing the app code into the infra codebase isn't terribly helpful and can lead to maintenance problems.

um... yeah. just looked it up, that's an antipattern to say the least

i guess its okay to have as an absolute oh :hankey: button

It's great for rapid prototyping, it can be ok for infra-specific code.. but for app code, since you often have different devs, different deploy cycles, and different test regimes and requirements, it's just too hard to keep them in one codebase.

If nothing else, the testability goes _way_ down.