https://pulumi.com
Join Slack
what's the trick to not recreating resources just because the provider version is updated?
# google-cloud
t
what's the trick to not recreating resources just because the provider version is updated?
b
do a 
pulumi up --target <provider-urn>
t
@brash-monkey-31522 can you elaborate on that? Does that just lock you in to use a single provider version?
from what i'm reading, that will tell pulumi to only update the specified provider.
b
Does that just lock you in to use a single provider version?
No, it just updates the one resource like you said
t
ok. i still want to update all of my resources but i don't want resources to be deleted and recreated just because a provider updated their versioning. surely i'm missing something about the concept of pulumi. it seems i can either lock in to a specific version OR certain resources get deleted and recreated when there's a new release here https://github.com/pulumi/pulumi-gcp/releases
b
You shouldn’t need to update your resources when you update the provider, the resources already exist in GCP and any API change on gcp’s side will be automatically applied to your resources.
ex if they add a new field, then that field will be added with a default value to your resource in GCP, the provider update is just to support managing that new field.
t
[provider: urnpulumimain:redacted pulumipulumiprovidersgcpdefault 7 13 0:22a434da-6115-44e7-b085-dc962c2d0b6a => urnpulumimain:redacted pulumipulumiprovidersgcpdefault 7 14 0:output<string>]
b
The exception being breaking changes in the provider, in which case you need to read the changelog for that version change
t
nothing in that changelog about breaking changes
v7.14.0 Changelog 6918cf0 Remove gcp creds from state (#1814) 452bcce Upgrade pulumi-terraform-bridge to v3.77.0 (#1813) 62d279c Upgrade terraform provider google beta to v5.20.0 (#1824)
b
What is the current provider version you are using?
oh nvm I see it 7.13
then yeah, i would do as I initially described, a 
pulumi up
targeting only the provider resource
t
so, does everyone just lock in to a single provider version forever? that doesn't seem right. it doesn't make sense to recreate your infrastructure just to get updates on a provider.
b
You aren’t locking into a provider version
Pulumi just isn’t smart enough to decide on each provider update if it needs to change resources, so it defaults to replacing every resource
The targeted pulumi up will make any API calls after use the updated version of the provider
t
so, you're saying i need to specify the 7.13 version as the target going forward?
b
no
pulumi up --target <provider-urn>
this will update your provider to the version you have installed in your language’s dependency manager
so 7.14 in this case
once you run 
pulumi up --target <provider-urn>
you can do 
pulumi preview
and you’ll see there are no resources to be replaced, life is good, you have updated the provider, congrats
t
isn't this the result the of updating the provider? "[provider: urnpulumimain:redacted pulumipulumiprovidersgcpdefault 7 13 0:22a434da-6115-44e7-b085-dc962c2d0b6a => urnpulumimain:redacted pulumipulumiprovidersgcpdefault 7 14 0:output<string>]"
when the resource was initially created, it was done using the 7.13 provider. then on this update, it's using the 7.14 provider and since the provider version is part of the resource urn, it replaces the resource. right?
b
> it replaces the resource. right? yes, but it doesn’t have to, pulumi just isn’t able to understand that
t
does it hurt anything to keep the 
--target <provider-urn>
part in my pulumi up command and have it always run? i ask because my pulumi commands are all in ci/cd pipelines and not executed locally on developer systems.
also, what about when you have multiple providers? should i specify each provider as a target to prevent this issue with them?
b
you only need to do the target once
also, what about when you have multiple providers? should i specify each provider as a target to prevent this issue with them?
only if you see the replace issue
t
how do you manage this with ci/cd?
b
I don’t 😛
t
the more i learn, the more i think pulumi was designed to be ran from your local computer 99.9% of the time
b
Yeah, same. I haven’t bothered trying to CI/CDify my pulumi stack
t
this makes me want to nuke my infra from orbit and go back to terraform. (which pulumi seems to be using all the integrations from anyways)
4 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by