https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
c
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
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
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
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
Okay. Issue = raise on github?
e
Yup
c
Open in Slack
PreviousNext
Powered by