This message was deleted.

are you parenting your resources inside your component to the component itself?

Thanks @billowy-army-68599.

yes, you’re not setting the

parent

on the child resources

Thanks @billowy-army-68599 — I must be missing something, is line 24 not doing just that? The docs say it should be sent in the

opts

as the named param

parent

, which is happening in line 24 (I thought — note that line 13 is what sets the local

parent

to

this

). It seems like your example

{parent, this}

would instead send

this

as a named param

this

, which doesn’t exist from what I can see in the

CustomResourceOptions

interface. Thanks for your help, here.

Ah sorry, that’s a typos. You need parent:this (not a comma)

In JS if

parent

is a local you do not need to do

parent: parent

—

parent

alone will suffice (so-called “shorthand property names”). So I believe the code above is equivalent to

{ parent: this }

.

I’m not really following that, what I am trying to say is this particular resource:

this.admin = new postgresql.Role(
      `${dbName}-postgres-admin-role`,
      {
        login: true,
        name: adminUserName,
        password: adminUserPassword,
      },
      { dependsOn, parent },
    );

Does not know it is a member of a component at all. It just knows that it

dependsOn

the component. Parenting a resource in Pulumi is a specific thing. It tells Pulumi to let all resources inherit the resource options from the thing it’s parenting to, including

dependsOn

Thank you @billowy-army-68599 — I think the code is functionally equivalent (JS syntax is the difference). I will rewrite it though and try it that same way. One clarification — you added

parent: this

to the

opts

for the component resource initializer as well (i.e. also to

new PostgresDb()

, not just the children of the component like

new postgresql.Role()

) — presumably that would make the component’s parent the…. stack? I haven’t seen this use of

parent

before.

ah sorry, I didn’t realise that was a component, you don’t need parent there

Good to know! 🙂 I tried with the different syntax, same result. This results in the expected

parent

associated with its state, but no

dependencies

at all:

"parent": "urn:pulumi:(stack)::cda::mynamespace:PostgresDb::my-svc-postgres-db",

did you make the component instantiation depend on the role?

Sorry, no, the role is part of the component.

sorry let me regrok this

I’m happy to present it in a different way (e.g. change names to be more obvious).

okay, I think I understand now. Let’s say you have a component like this

// Component class
export class PostgresDb extends pulumi.ComponentResource {
  db: postgresql.Database;
  admin: postgresql.Role;

  constructor(
    name: string,
    args: PostgresDbArgs,
    opts?: pulumi.ComponentResourceOptions,
  ) {
    super('mynamespace:aws:PostgresDb', name, args, opts);

	const parent = this;
    const dependsOn = opts?.dependsOn;
    const { dbName, adminUserName, adminUserPassword } = args;
		
    this.admin = new postgresql.Role(
      `${dbName}-postgres-admin-role`,
      {
        login: true,
        name: adminUserName,
        password: adminUserPassword,
      },
      { parent: this },
    );
    
	// ...
  }
}

And you instantate it like this

const MySvcDb = new PostgresDb(
  'my-svc-postgres-db',
  {
    dbName: 'my-svc',
    adminUserName: '...',
    adminUserPassword: '...',
  },
  {
    dependsOn: someOtherResources
  },

Everything in the

PostgresDb

class should depend on

someOtherResources

is there somrthing else you need?

That is what I assume — but that’s not what I’m observing.

how are you observing that?

I’m deploying, doing a

pulumi stack export

, and finding the resource in the file, looking at its

dependencies

property. It’s not present on children; when I explicitly plumb through the

opts.dependsOn

to the children it shows up.

It won’t be set on anythjng other than the parent. The logic happens in the engine

Hmmm… I guess that’s the answer then, and good to know. I introduced it because I saw the children being created before the

dependsOn

resources that were provided to the parent. That’s a hard thing to reproduce quickly (it involves spinning up new RDSes). I can revert the explicit piping then and see if it reintroduces the problem or not! 🙂 Thanks for sticking with this thread, much appreciated. I’m not sure if the documentation can be improved in this respect — it’s a little vague on that parent page what should happen and how the state doesn’t show this implicit dependency. I appreciate your help in clarifying!