This message was deleted.

What end state do you want to be in - I can imagine two: 1. You want to

ignore_changes

for ~everything. You don't want your Pulumi program to overwrite anything in the cloud (even when you make future changes). 2. You want to just go ahead and import, and then Pulumi will propose updates and/or replacements for things that don't match, and you'll accept making those changes. For (1), we could offer

ignoreChanges: ["*"]

or similar. For (2), we could provide an option to just not block the import, but you will get some possibly scary updates/replacements on future updates.

I'd say 2 would be better. If an existing resource is added to be adopted, I'd like to see a preview of what would be changing. Ultimately, I'd like to see pulumi own that resource outright if I proceed with those changes. It's not the end of the world to add in the ignore cases. I was exploring the idea that if a resource is being adopted for the first time, to just ignore the case for the first action.

Just to make sure - you are okay in these cases if the next update you do leads to changes or even replacements of the resource? That does not seem like it would in general be desirable?

Thinking about this more, I guess I’d prefer to have the inverse. And this currently is a limited scope. Example. An account has 100 ECRepositories that were manually created, tagging lacks consistency, policies all over the place, no security scanning and no event driven notifications. Assume there’s a custom component that would, create or adopt a repo based on name, apply a tagging template, configure scan on push, and the cloud trail event notifications on high severity findings, etc. The want would be adopt the current aws resources into a pulumi stack and apply specific templates. It would import without issues as long as you accepted the stack changes, (or potentially,

errorOnChanges: ["Policy"]

to error out if it detects a change to said property.