is cross-stack subresource ownership possible? ex.: • I have an ApplicationLoadBalancer defined in "core-infrastructure" github repo / pulumi project • I'd like to load it in a different repo and add a target group to it which that repo / stack owns. or do all target groups need to be created in "core-infrastructure" and then their ARNs exported + StackRef'd

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.

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

yeah

What's the problem that requires a workaround?

I'm working on a microstack pattern outlined here -> 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

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.

good to know for starters!

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;

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

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.