https://pulumi.com logo
Powered by
c

cool-dress-96114

07/25/2023, 9:21 PM
Hi folks, question about the 
--target-dependents
flag for 
pulumi up
. I’ve got a very minimal stack to outline what I’m describing (see thread). I have a resource 
a
which depends on 
b
which depends on 
c
. I’ve made changes to 
b
and want to roll out the update to 
b
and to 
c
. We explicitly do NOT want to roll out changes to 
a
on the fly, in favor of a maintenance window due to the sensitivity of the resource. Is there a way from the command to roll out only those specific resources? We’ve tried the following:
Copy code
pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b' # makes changes to b
pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b' -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::c' # makes changes to b and c, as expected 
pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b' --target-dependents # makes changes to a, b, c
Due to the size of our stack, it’s unwieldily and not practical to call 
-t
for all the resources, as there’s a bunch of nested and resources that are dynamically created resources. I’m confused why 
--target-dependents
does not only target the dependents of the 
b
resource (
c
); Ideally there’s a corresponding 
--target-dependencies
that would also target the dependency resource (in this case 
a
in addition to 
b
), but that’s for another thread.
Copy code
provider, err := random.NewProvider(ctx, "rand", &random.ProviderArgs{})
	if err != nil {
		return err
	}

	a, err := random.NewRandomInteger(ctx, "a", &random.RandomIntegerArgs{
		Max:  <http://pulumi.Int|pulumi.Int>(10000),
		Min:  <http://pulumi.Int|pulumi.Int>(1),
		Seed: pulumi.Sprintf("%s", time.Now().String()),
	}, pulumi.Provider(provider))
	if err != nil {
		return err
	}

	b, err := random.NewRandomInteger(ctx, "b", &random.RandomIntegerArgs{
		Max:  <http://pulumi.Int|pulumi.Int>(10000),
		Min:  <http://pulumi.Int|pulumi.Int>(1),
		Seed: pulumi.Sprintf("%s", time.Now().String(), a.Result),
	}, pulumi.Provider(provider))
	if err != nil {
		return err
	}

	_, err = random.NewRandomInteger(ctx, "c", &random.RandomIntegerArgs{
		Max:  <http://pulumi.Int|pulumi.Int>(10000),
		Min:  <http://pulumi.Int|pulumi.Int>(1),
		Seed: pulumi.Sprintf("%s%d", time.Now().String(), b.Result),
	}, pulumi.Provider(provider))
	if err != nil {
		return err
	}

	_, err = random.NewRandomInteger(ctx, "d", &random.RandomIntegerArgs{
		Max:  <http://pulumi.Int|pulumi.Int>(10000),
		Min:  <http://pulumi.Int|pulumi.Int>(1),
		Seed: pulumi.Sprintf("%s", time.Now().String()),
	}, pulumi.Provider(provider))
	if err != nil {
		return err
	}
Note that with the 
Seed
parameter changing for all 3 resources, this is simulating all 3 resources of changes queued up and waiting to be deployed. Trying to figure out how to delay deploying 
a
Edit: Updated with a provider, same issue still manifests.
Copy code
» pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b'
Previewing update (scratch):
     Type                           Name            Plan        Info
     pulumi:pulumi:Stack            pragma-scratch              
 +-  └─ random:index:RandomInteger  b               replace     [diff: ~seed]
Copy code
» pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b' --target-dependents
Previewing update (scratch):
     Type                           Name            Plan        Info
     pulumi:pulumi:Stack            pragma-scratch              
 +-  ├─ random:index:RandomInteger  a               replace     [diff: ~seed]
 +-  ├─ random:index:RandomInteger  b               replace     [diff: ~seed]
 +-  └─ random:index:RandomInteger  c               replace     [diff: ~seed]
Even weirder is when I add another completely unconnected resource (update stack example, see 
d
) it still shows up as one to change with the 
--target-dependents
flag
Copy code
» pulumi up -t 'urn:pulumi:scratch::pragma::random:index/randomInteger:RandomInteger::b' --target-dependents
Previewing update (scratch):
     Type                           Name            Plan        Info
     pulumi:pulumi:Stack            pragma-scratch              
 +-  ├─ random:index:RandomInteger  a               replace     [diff: ~seed]
 +   ├─ random:index:RandomInteger  d               create      
 +-  ├─ random:index:RandomInteger  b               replace     [diff: ~seed]
 +-  └─ random:index:RandomInteger  c               replace     [diff: ~seed]
e

echoing-dinner-19531

07/26/2023, 12:16 PM
I've just put in a fix for --target-dependents. It was being overly eager about targeting every resource with a default provider. Should be better in the release due today.
c

cool-dress-96114

07/26/2023, 2:11 PM
Perfect, can’t wait to try it. Thanks.
@echoing-dinner-19531 reading up on this more, it looks like your fix is mainly targeted around default providers? Everything we do is in AWS / Github / Auth0 / Buildkite, which all require credentials + configuration, so we use explicit providers with a parent calling the 
ctx.RegisterComponentResource
call and a provider map, then passing that down as a parent to all subresources
Copy code
pulumi.ProviderMap(map[string]pulumi.ProviderResource{
		"aws":       awsProvider,
		"buildkite": buildkiteProvider,
		"github":    githubProvider,
		"auth0":     auth0Provider,
	}
Is this change going to fix what I think is a similar issue for things with non-defaulted providers?
(Sorry for not providing an example that better reflects our actual project structure with providers lol)
I updated the second message in this thread with a specific provider resource, same issue. Unless I’m misunderstanding what your fix was targeting
e

echoing-dinner-19531

07/26/2023, 3:40 PM
No it doesn't, I did wonder when doing this fix if it was wrong for --target-dependents to look at providers at all. Worth raising an issue to discuss this properly, the current logic is odd I don't think we'd be against a re-think here.
c

cool-dress-96114

07/26/2023, 4:06 PM
Okay. Issue = raise on github?
e

echoing-dinner-19531

07/26/2023, 4:07 PM
Yup
c

cool-dress-96114

07/26/2023, 5:13 PM
Powered by