mirror of https://github.com/pulumi/pulumi.git
8314293d6e
When executing a `--target`ed operation, Pulumi considers all providers to be "implicitly targeted", whether their URNs are mentioned or not. As a result, *all* Pulumi operations update provider resources, `--target`ed or not. This can lead to some tricky scenarios that Pulumi needs to handle or detect in order not to break the user's program or state. One such case is where a user tries to alter the provider of an untargeted resource. Consider the following starting program/state: ```typescript const parent = new sdk.Component("parent") const provider = new sdk.Provider("provider") const resource = new sdk.Resource("resource", { provider }) ``` Let us modify the program so that `provider` becomes a child of `parent`. In doing so, `provider`'s URN will be changed on the next update to include `parent`'s type (so e.g. `provider` will become something akin to `parent$provider`): ```typescript const parent = new sdk.Component("parent") const provider = new sdk.Provider("provider", { parent }) const resource = new sdk.Resource("resource", { provider }) ``` Now we run `pulumi up --target "**non-existent**"`. That is, we specify a target glob that will not target *any* of the resources in the program. Our update will proceed as follows: * A resource registration for `parent` is sent. `parent` is not targeted (it is not matched by the `--target` glob, and it is not a provider resource), so we emit a `SameStep` for it to copy it unchanged from the old state to the new state. * A resource registration for `provider` is sent, with a parent of `parent`. This resource *is* targeted since it is a provider, and thus is implicitly targeted. Pulumi constructs the URN `parent$provider` for the provider resource and looks to see if there is any old state for it. * Pulumi finds no old state (the existing provider state is registered under the URN `provider` [no `parent$`]) and so decides that `provider` must be `Create`d. It emits a `CreateStep` and moves on. * A resource registration for `resource` is sent. `resource` is not targeted (it is not matched by the `--target` glob, and it is not a provider resource), so we want to emit a `SameStep` for it to copy it unchanged from the old state to the new state. * *However*, as part of checking whether we can emit a `SameStep` for resource, we find that it references a provider that we have not seen a registration for (`provider` -- recall that we have only seen `parent$provider`). We thus abort with an error informing the user that they have to run an untargeted update to update their provider before targeted updates can proceed. If the user genuinely wants to rename the provider, and not actually delete the old one and create a new one whose parent happens to be `parent`, they can of course use an alias: ```typescript const parent = new sdk.Component("parent") const provider = new sdk.Provider( "provider", { parent, aliases: [new Alias({ parent: undefined })], } ) const resource = new sdk.Resource("resource", { provider }) ``` At least, that's what they might expect. Presently, attempting to do this will yield a `panic`, neither tripping the existing error machinery, nor successfully completing the `--target`ed operation. This commit fixes this panic by making it work. We'd previously considered making this case trigger the existing "no provider exists" error flow, but this is not in fact correct -- in the case an alias is supplied, the provider *does* exist and we should be able to find it and complete the rename. Here we make that so. Fixes #17719 |
||
---|---|---|
.. | ||
analyzer | ||
deploy | ||
edit | ||
graph | ||
provider | ||
stack | ||
testdata |