https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
l
There's a few reasons for these sorts of things.
You might be creating some resources / properties inside an 
apply()
, which preview and refresh can't unroll. So they report differences, to be safe. When you request the final refresh / up, those differences might not manifest.
Or those properties might be known to Pulumi to be particularly transient, and Pulumi can't guarantee that at refresh / up time, the in-cloud situation will be the same as it was during the preview. ASGs are likely to be in this category. I don't know how this works, and this is just a guess based on my own experience.
There may be default values that you're not setting in code, but the cloud provider has set up. A refresh will put those values into state, This situation is inconvenient, because your next up will remove them from state (because they're not in code), and the next refresh will put them back in. If this is the case, I recommend updating your code to explicitly set those values to whatever the provider is setting them to, so that the cloud state, code and Pulumi state all match up.
And the final case (that I can think of) is that the cloud provider has genuinely changed the value, and the code has not been changed. This is a minor various of the previous case, and the same solution applies.
r
thank you @little-cartoon-10569 for the details! re `apply()`: not too sure what you’re referring to here, but I’ve got no 
apply
function call in my code.. and as for invoking pulumi, I am only doing 
pulumi up -r
re transient properties (and also “default values that you’re not setting in code”): to take the example of the launch templates, I am setting specific values for the vpc security ids (and they do not change)… so I’m not sure what’s going on here. These values should not be changed arbitrarily by the cloud provider as well.
l
It looks like you're deploying proj-dev, and seeing changes that have happened in proj-aaaaa. That is, your current stack is being updated with changes that you've made via a different stack. Would that explain it?
r
oh, no. 
proj
is just my redacted name for the actual project name. Sorry if that confused you. It’s all in one stack. I have no other stacks besides 
dev
let me edit the output to be clearer
l
Are you building the resources in a loop? If you are, is it possible that you're re-ordering some input values relative to others? If you're iterating over parallel arrays, and those arrays might be re-ordering on different runs of Pulumi, then you would be changing the resources just like the preview suggests.
If this is the case, maybe try removing the loop and building the resources with fixed values, to test that every works. Then work back to building the resources using the correct variables / arrays, until you find what value is changing each run.
r
no loops here, but good idea. My 
vpc_security_group_ids
and 
vpc_zone_identifiers
are defined using variables (more on that later), BUT I have tried hard-coding them as well, and I still get diffs when doing 
pulumi up -r
To illustrate, my 
vpc_security_group_ids
are defined like this:
Copy code
vpc_security_group_ids = [
	vars.security_group_ids[f'sg_{ SERVICE_NAME }'],
	vars.security_group_ids['sg_common'],
]
(I define the actual security group values in a separate file, 
vars.py
that gets imported, because these are common values). As mentioned, I have tried defining them directly and not using variables to get the values, but even when I do that, 
pulumi up -r
still claims that there are diffs. I’ve tried upgrading through new versions of pulumi as they are released… Same thing
bumping this again. Anybody from Pulumi want to take a look at this? I can provide sample source and info
e
https://github.com/pulumi/pulumi-aws/issues/ if you've got a program that repros this raise an issue there with details.
👌 1
246 Views
Open in Slack
PreviousNext
Powered by