https://pulumi.com logo
#general
Title
# general
i

icy-controller-6092

01/07/2024, 8:30 AM
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
d

dry-keyboard-94795

01/07/2024, 11:46 AM
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
e

echoing-dinner-19531

01/08/2024, 2:21 PM
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.
d

dry-keyboard-94795

01/08/2024, 2:35 PM
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

icy-controller-6092

01/08/2024, 10:34 PM
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
If the resource cannot spawn 2 operations into the plan (import then update) you can still do just the import ignoring local inputs on first run, then the program will need to be run again to effect the update A minor inconvenience compared to the current options
There’s another side too, which is when you’re using import simply to transfer state between stacks. I ran into an issue with the upstash package’s importer and it made me think… For a transfer of resources between stacks, can we skip the importer logic altogether?
e

echoing-dinner-19531

01/08/2024, 11:31 PM
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.
i

icy-controller-6092

01/08/2024, 11:48 PM
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
e

echoing-dinner-19531

01/08/2024, 11:52 PM
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.
And like we could add an option for this
importAsIsIReallyMeanIt: true
but then you need to work out a good UX around making sure people are aware of that option and what exactly it means
i

icy-controller-6092

01/08/2024, 11:54 PM
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?
anyway i guess this is moot for my use case as I'm trying to refactor into microstacks as recommended by the docs, and I guess all this trepidation around imports has really put me off that as a flow for moving resources between stacks I think for now I will just go back to manually editing state by hand
e

echoing-dinner-19531

01/09/2024, 12:00 AM
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.
i

icy-controller-6092

01/09/2024, 12:04 AM
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/
e

echoing-dinner-19531

01/09/2024, 12:15 AM
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
i

icy-controller-6092

01/09/2024, 12:17 AM
> 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
e

echoing-dinner-19531

01/09/2024, 12:22 AM
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.