https://www.pulumi.com/docs/concepts/options/import/ Why do the inputs have to match? importing should be about moving a resource between stacks, I can't see any reason for why the destination stack has to match the inputs exactly. sometimes this is not even possible

I can't find the gh issue about this, but I know there's been work in the last few releases to improve imports overall. The ideal solution I've proposed in the past is it just imports as part of the refresh, the applies the changes detected during the update

Why do the inputs have to match? i

If they didn't you would have differences between what your state records and what the actual cloud state is. If you use the

import

command we warn about this but it's not an error, because you still have a chance between the run of

import

and

up

to run

refresh

to fix it. But if using the import option the engine wants to do any update there and then, there's no opportunity to run refresh or fix another way. So we have the option of either A) Error B) Ignore the inputs defined in your program Given the whole point of

up

is to make the cloud state look like what your program says that pretty much excludes doing B.

I've generally gone with manual state modification over using import because of this limitation. The import cli is cumbersome when you're doing multi-stack projects, and the inability to use the import option with slight differences for manually created cloud resources just results in time lost. That or just delete resources in cloud if they're not going to cause too long or an outage.

I’m not sure it needs to be so strict, when using the import option can the resource not spawn both an import and an update into the plan? And re: state consistency, the import operation can ignore the local program input values on first run, and store in the state what it reads from the remote resource. These are the same inputs that are rendered to stdout when you perform a CLI import

when using the import option can the resource not spawn both an import and an update into the plan?

We could, but now you need to be careful about watching for warnings on preview (and hopefully your running preview not just up) to check that your not inadvertently changing a resource that you thought you were just importing. This is very much a trying to find a balance for good overall UX thing, not a technical thing.

But if your program is requesting both an import (by adding the import resource option) and a change (different input values), would you ultimately expect to be changing the resource? I don’t think that could be classified as an “inadvertent” change, it would be quite an intentional change

Yes it could be, but historically we've err'd on the cautious side that if your trying to import and change at the same time it's more likely that you just wrote the program inputs wrong.

but how is that any different to writing inputs wrong in a normal program editing flow?

there are no gutter guards in that scenario, so I don't see why they should be additional guards for the import flow?

Well there can't be any guards in that case, we've got nothing to compare against.

trepidation around imports has really put me off that as a flow for moving resources between stacks

The

pulumi import

command is probably better for this, but I'd really like to write a proper transfer command at some point. Something like

transfer stackA/resA stackB/resB

to transfer resA from stackA to stackB and call it resB.

we've got nothing to compare against

for an update, you are comparing against the previously known state

transfer stackA/resA stackB/resB

this would be a fantastic addition, it might even be a good idea to alert people in the docs that they should use microstacks for new projects only -- and wait until

transfer

is available before refactoring existing projects into microstacks this is the page where the warning should be placed: https://www.pulumi.com/docs/using-pulumi/organizing-projects-stacks/

for an update, you are comparing against the previously known state

Well yes, but you clearly need to be able to change things in that scenario. If we err'd that the inputs didn't match you'd never be able to change anything.

this would be a fantastic addition

Yeh I'll talk to docs about that

> If we err'd that the inputs didn't match you'd never be able to change anything. at the risk of running in circles, my question is... why even err when the inputs don't match, in the import scenario? for the same reason it's not done on

update

- the program needs to be effective - i think it should also not be done for

import

matching inputs is sometimes not even possible in the context of the new stack, for example inputs might need to be changed to reflect the destination stack environment - and having the imported resource still reflecting the old context after a successful import also seems like a inconsistent state to leave your program in between runs

why even err when the inputs don't match, in the import scenario?

Because it was quite common for people to think they were importing a resource exactly as is but inadvertently causing an update because the inputs didn't exactly match. Arguably this is user error and they should have looked at the preview more closely but alas humans are human.

and having the imported resource still reflecting the old context after a successful import also seems like a inconsistent state to leave your program in between runs

Yes, that's a good case for when you really do mean to import and then update in the same operation. It might be worth raising an issue to discuss this. It may be that we can solicit enough input that it would be ok to just allow import/update in one step.