Fix aliasing children

[justinvp]

Note: This is a large PR that I've separated into many smaller commits to make it easier to review commit by commit.

Background

Originally, each SDK would compute alias URNs from alias "specs" and the alias URNs would be sent to the engine. #10819 added support for having the engine compute the alias URNs by enabling SDKs to send just the alias specs to the engine. #11206 updated the Node.js SDK to leverage this new capability, and subsequent PRs enabled it for the other SDKs.

Unfortunately, there are a couple of issues:

1. Engine: A bug in alias computation
2. Node.js SDK: A bug in the alias specs sent to the engine

Engine Bug

There is an issue with how the engine computes the aliases when the resource is a child and doesn't have Parent set on the alias spec (and the parent doesn't have any aliases).

class FooResource(pulumi.ComponentResource):
    def __init__(self, name, opts=None):
        super().__init__("my:module:FooResource", name, None, opts)


class ComponentResource(pulumi.ComponentResource):
    def __init__(self, name, opts=None):
        super().__init__("my:module:ComponentResource", name, None, opts)
        FooResource("childrenamed", pulumi.ResourceOptions(
            parent=self,
            aliases=[pulumi.Alias(name="child")]
        ))

In the example above, ComponentResource has a child FooResource which was renamed from child to childrenamed.

The engine does not compute the correct alias:

expected: urn:pulumi:stack::project::my:module:ComponentResource$my:module:FooResource::child
  actual: urn:pulumi:stack::project::my:module:FooResource::child

The problem is due to:

pulumi/pkg/resource/deploy/step_generator.go

Lines 370 to 382 in 117955c

	var parentType tokens.Type
	// If alias.NoParent is true then parentType is blank, else we need to look if a parent URN is given
	if !alias.NoParent() {
	parentURN := alias.Parent
	if parentURN == "" {
	parentURN = goal.Parent
	}
	if parentURN != "" && parentURN.Type() != resource.RootStackType {
	// Skip empty parents and don't use the root stack type; otherwise, use the full qualified type.
	parentType = parentURN.QualifiedType()
	}
	}

... and:

pulumi/sdk/go/common/resource/alias.go

Lines 24 to 26 in 117955c

	func (a *Alias) NoParent() bool {
	return a.Parent == ""
	}

Because the alias spec doesn't have Parent specified, the parent type is not being included the computed alias URN.

Existing tests such as https://github.com/pulumi/pulumi/tree/master/tests/integration/aliases/python/rename_component_and_child didn't catch the problem because the alias specifies both the name and parent:

pulumi/tests/integration/aliases/python/rename_component_and_child/step2/__main__.py

Line 15 in 117955c

aliases=[Alias(name="otherchild", parent=self)]))

In this case, specifying parent on the alias shouldn't be necessary. However, even after removing parent from the alias spec, the test still succeeds because the parent itself has an alias:

pulumi/tests/integration/aliases/python/rename_component_and_child/step2/__main__.py

Line 18 in 117955c

aliases=[Alias(name="comp5")]))

... and parent aliases are inherited as part of a child's aliases, so we still get an alias that works from the inheritance.

If we change the test to make no changes to the parent such that it doesn't have any aliases, then we get the failure as we'd expect.

A similar problem will happen when retyping a child.

Fix

The fix involves using the child's parent in the calculated alias URN when Parent isn't specified for the alias.

As part of this, we need to properly handled NoParent because right now the engine is not correctly using it. The struct representing an alias in the engine does not have a NoParent field:

pulumi/sdk/go/common/resource/alias.go

Lines 8 to 15 in 117955c

	type Alias struct {
	URN URN
	Name string
	Type string
	Project string
	Stack string
	Parent URN
	}

And therefore does not copy it over in the gRPC request:

pulumi/pkg/resource/deploy/source_eval.go

Lines 1082 to 1088 in 117955c

	alias = resource.Alias{
	Name: aliasSpec.Name,
	Type: aliasSpec.Type,
	Stack: aliasSpec.Stack,
	Project: aliasSpec.Project,
	Parent: resource.URN(aliasSpec.GetParentUrn()),
	}

Instead, the Alias struct has an incorrect NoParent method which returns true if the Parent field has a value of "":

pulumi/sdk/go/common/resource/alias.go

Lines 24 to 26 in 117955c

	func (a *Alias) NoParent() bool {
	return a.Parent == ""
	}

Node.js SDK Bug

The Node.js SDK is not sending the right Parent and NoParent alias spec fields.

pulumi/sdk/nodejs/runtime/resource.ts

Lines 332 to 361 in 117955c

	function mapAliasesForRequest(aliases: (URN | Alias)[] | undefined, parentURN?: URN) {
	if (aliases === undefined) {
	return [];
	}
	return Promise.all(
	aliases.map(async (a) => {
	const newAlias = new aliasproto.Alias();
	if (typeof a === "string") {
	newAlias.setUrn(a);
	} else {
	const newAliasSpec = new aliasproto.Alias.Spec();
	const noParent = !a.hasOwnProperty("parent") && !parentURN;
	newAliasSpec.setName(a.name);
	newAliasSpec.setType(a.type);
	newAliasSpec.setStack(a.stack);
	newAliasSpec.setProject(a.project);
	if (noParent) {
	newAliasSpec.setNoparent(noParent);
	} else {
	const aliasParentUrn = a.hasOwnProperty("parent") ? getParentURN(a.parent) : output(parentURN);
	const urn = await aliasParentUrn.promise();
	newAliasSpec.setParenturn(urn);
	}
	newAlias.setSpec(newAliasSpec);
	}
	return newAlias;
	}),
	);
	}

• It's only setting NoParent when the alias doesn't have a Parent set and the resource doesn't have a parent.
• If the resource has a parent and Parent isn't set on the resource, it sends the parent's URN for Parent.

Instead:

• It should set NoParent when Parent is set to undefined.
• It should only send Parent if the user's alias has specified a Parent.

This makes the Node.js SDK behave like the other SDKs.

Fixes #12662

[pulumi-bot]

Changelog

[uncommitted] (2023-06-14)

Bug Fixes

• [engine] Fix aliasing children
  #12848

• [sdk/nodejs] Fix Parent/NoParent aliases
  #12848

[justinvp]

Technically, this is a breaking change. However, I think it's worth making the change because it's unlikely anyone else is actually using this directly.

The alternative is to keep the NoParent method as-is (potentially marking it as deprecated) and add a new bool field for NoParent with some other name.

[Frassle]

I'm fine with this, most of the things in /common aren't really supposed to be used for public consumption.

[justinvp]

The engine change fixes the non-Node.js SDKs. For Node.js, if you're using the fixed engine with an old Node.js SDK, or a new Node.js SDK with an old engine, you may see some behavior differences depending on how you're using Parent and NoParent.

Some possible mitigations:

1. I contemplated keeping around a legacy mode in the engine, which would make it behave the old way, unless an SDK has explicitly indicated that it's using the alias specs the "right way," but the extra complexity likely isn't worth it.

2. Another idea would be to provide an environment variable to opt-out of engine support for calculating aliases. This would work similar to what we do for resource references and output values, i.e. in the SupportsFeature gRPC:

   pulumi/pkg/resource/deploy/source_eval.go

   Lines 676 to 687 in 117955c

   	switch req.Id {
   	case "secrets":
   	hasSupport = true
   	case "resourceReferences":
   	hasSupport = !rm.disableResourceReferences
   	case "outputValues":
   	hasSupport = !rm.disableOutputValues
   	case "aliasSpecs":
   	hasSupport = true
   	case "deletedWith":
   	hasSupport = true
   	}

   This would allow going back to the old behavior where aliases are computed in the SDK, and could be used as a temporary workaround for any behavior changes for Node.js (or any bug in the engine, for that matter).

Although, the simplest answer would be to just update both your CLI and SDK to the latest version.

[Frassle]

I'm fine with this, most of the things in /common aren't really supposed to be used for public consumption.

[justinvp]

I've pushed some additional commits to maintain behavior for users of the Node.js SDK.

I looked at these two cases:

• New CLI + Old Node.js SDK
• Old CLI + New Node.js SDK

New CLI + Old Node.js SDK

The new adopt_component_child and existing adopt_into_component integration tests fail -- the ones that use the parent: pulumi.rootStackResource alias.

The mitigation for this is ugly and I initially felt uneasy about it, but it is a practical way to address the issue, and I'm personally OK with it. If the engine detects a RegisterResource request is from an old Node.js SDK, it fixes up the incorrect aliases to be correct.

It does this by looking at the gRPC request's metadata headers, specifically looking at the "pulumi-runtime" and "user-agent" headers.

First, if the request has a "pulumi-runtime" header with a value of "nodejs", we know it's coming from the Node.js plugin. The Node.js language plugin proxies gRPC calls from the Node.js SDK to the resource monitor, and the proxy now sets the "pulumi-runtime" header to "nodejs"
for RegisterResource calls.

Second, if the request has a "user-agent" header that starts with "grpc-node-js/", we know it's coming from the Node.js SDK. This is the case for inline programs in the automation API, which connects directly to the resource monitor, rather than going through the language plugin's proxy.

We can't just look at "user-agent", because in the proxy case it will have a Go-specific "user-agent", and it doesn't look like you can modify the "user-agent".

Updated Node.js SDKs set a new aliasSpecs field on the RegisterResource request, which indicates that the alias specs are correct, and no transforms are needed.

Old CLI + New Node.js SDK

The new retype_component_child and rename_component_child integration tests fail. Essentially the same state as the other SDKs.

The mitigation for this is simple. We just have the Node.js SDK continue to set the resource's parent in the alias when the alias itself doesn't have a parent specified. If following the spec correctly, this isn't necessary, but there's no harm in doing it.

[Frassle]

nodejs workarounds are a bit sad but all looks reasonable to keep things working

[justinvp]

bors merge

[bors]

Build failed:

• bors-ok

[justinvp]

bors retry

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• bors-ok