For those using auto-naming, how are corresponding app configuration changes typically made? If Pulumi needs to drop and recreate a MSK cluster or some other resources and then something like bootstrap brokers changes as a result, it may be near-zero downtime for infra but likely not applications depending on if their config needs to change to repoint to new resources? This seems to be a critical point missing from any docs I've seen. Outside of the auto package, is there a way for apps to easily get pulumi state outputs (not the IAC app itself)? Or are people reading outputs with apply from IAC and then storing those somewhere like AppConfig or Parameter Store and notifying apps of config changes / restarting them etc. (with apps being dynamic, never hardcoding resource names)?

If the non-infra logic cannot fetch generated names on demand (e.g. from a key-value store or vault that Pulumi can update), then you may be better off using fixed names for some resources. This has not often happened for me, as I have usually been able to protect app logic from infra naming through the use of some service specifically designed for this problem. The most common such service is DNS.

Thanks, yeah DNS works for a lot of endpoints but if everything is auto-named it could be something as small as a Kafka topic name but know hybrid mix and match makes sense at times. Was just curious if people were grabbing pulumi outputs and storing wherever then fetching from there, or if there was something I was missing to pull from Pulumi from apps. Also seemed strange not to mention anywhere in docs or examples. I get that it's not directly IaC but infra isn't being done in vacuum and mentioning implications and considerations of auto-naming for infra consumers makes sense IMO.

Both approaches are taken. Well-known values can be set in Pulumi code and "just known" elsewhere. And output values get stored in appropriate places, or get fetched on demand from the stack. Whatever works!

I’m assuming fetched on demand from the stack is referring to Pulumi CLI. Is there say a Pulumi Go package that can be pointed a an s3 cloud url to get stack outputs from an app, free of the cli? I found the auto package but it looks suited for other scenarios.

If you want to use the Pulumi SDK, it is in the automation-api package. If you'd rather not use that, then you could load the stack file directly from the bucket. It's a straight-foreward JSON file, the outputs are easy to find.

Thanks! We'll probably store the outputs in AWS ourselves somewhere after creating them with Pulumi but s3 read might be an option. Ideally there'd be a middle ground lightweight package. Not "embedding Pulumi CLI engine" with all heft of automation inside a non-infra app but also not reading raw s3 files where we might make assumptions or the format or data might change in ways we might not expect in the future.