Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

filestate/internal: Use stack reference, not name #12426

Merged
merged 1 commit into from Mar 16, 2023

Conversation

abhinav
Copy link
Contributor

@abhinav abhinav commented Mar 13, 2023

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return organization/$project/$name.

Change extracted from #12134

@abhinav abhinav added the impact/no-changelog-required This issue doesn't require a CHANGELOG update label Mar 13, 2023
@pulumi-bot
Copy link
Contributor

pulumi-bot commented Mar 13, 2023

Changelog

[uncommitted] (2023-03-16)

Copy link
Member

@Frassle Frassle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks as I'd expect but it's late and I don't trust my eyes to have not missed anything!
Will pick this up in the morning if no one beats me to approving it.

if !is {
return nil, fmt.Errorf("bad stack reference type")
}
return localStackRef, nil
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should actually be more strict. In the project changes I added a *localBackend field to localBackendReference and maybe this should check that the references isn't just the right type, but also comes from the backend object that is now trying to use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I may have removed the localBackend field. 😆

I suspect the type check here is enough: outside callers cannot construct their own localBackendReference.
I can't imagine many likely scenarios where we'll need to guard against two filestate backends passing bad references to each other. However, if that changes, we can guard against it either in the way you suggest or with a cheap numeric identifier assigned to the localBackend and passed to the localBackendReference.
(I think keeping localBackendReference as a data-only object is desirable until we add meaningfully complex behavior to it.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeh was just a thought, but given we'll need to re-add *localBackend to do the project name lookup in ParseStackReference it would be very doable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't understand. Why do we need to add localBackend to localBackendReference?
ParseStackReference is a method on localBackend, so it can do the lookup as needed.

For context, this is the change I made to drop the dependency:
980b3af
localBackendReference held onto localBackend only to look up the current project, so it could shorten the String() representation. I figured it can do that with the name of the current project at creation time instead.
(Accessing localBackend.currentProject on String has implications to thread-safety: there's no guarantee that String is not called concurrently; so if we end up putting the reference back. localBackend.currentProject will probably become an atomic.Pointer.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to add localBackend to localBackendReference?

To match the behavior of httpBackend. You'll change the output of pulumi new if you don't use the current project because we parse the stack reference first then make the project and set it with "SetCurrentProject".

It might be ok to change this, but filestate and httpstate should be the same in regards to this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack. I'll add the behavior back in the filestate PR.
(This PR will be unaffected by that.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added back in e3e40b1 and fixed race in c91e493.
(This is just FYI for changes to the draft PR. Real PRs incoming.)

Base automatically changed from abhinav/filestate-ctx to master March 13, 2023 23:10
@abhinav abhinav force-pushed the abhinav/filestate-use-local-ref branch from d0d9d8a to 9eedec4 Compare March 14, 2023 00:32
@abhinav abhinav force-pushed the abhinav/filestate-use-local-ref branch from 9eedec4 to 14fd8f9 Compare March 14, 2023 16:27
@abhinav
Copy link
Contributor Author

abhinav commented Mar 15, 2023

bors merge

bors bot added a commit that referenced this pull request Mar 15, 2023
12426: filestate/internal: Use stack reference, not name r=abhinav a=abhinav

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return `organization/$project/$name`.

Change extracted from #12134


12433: sdk/go: Don't use Provider for type if package doesn't match r=abhinav a=abhinav

In #12296, we started correctly interpreting the Provider argument
per other SDKs. but this introduced a regression:
the Provider field is now set for resources with mismatched types.

This results in a scenario where a provider foo for package X
is passed to a resource bar with package Y,
with the intent of plumbing it to bar's descendants,
but bar attempts to incorrectly use the provider directly.

    foo := NewXProvider()
    bar := NewYThing("bar", Provider(foo))
    // ...
    baz := NewXThing("baz", Parent(bar)) // should use foo

This worked previously, but with #12296, this fails
because NewYThing attempts to use Provider foo directly.

To fix this, we need to prevent NewYThing from using a provider
that does not match the package that it belongs to.
We had to make a similar change to the Python SDK in #12292.

https://github.com/pulumi/pulumi/blob/477e0c97660bdbeb28a142057899792d52e63a0b/sdk/python/lib/pulumi/resource.py#L925-L927

The regression test is specific to remote component resources
per #12430, but the issue would be caused even for normal component
resources before this.

Resolves #12430


12435: Pin CI to Node 19.7.x to avoid hitting assert in 19.8.0 r=abhinav a=justinvp

Node 19.8.0 was released ~5 hours ago and we're hitting an internal assert. Pin to 19.7.x to unblock CI until we understand what's going on with 19.8.0.

Part of #12434

Co-authored-by: Fraser Waters <fraser@pulumi.com>
Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
Co-authored-by: Justin Van Patten <jvp@justinvp.com>
@bors
Copy link
Contributor

bors bot commented Mar 15, 2023

This PR was included in a batch that timed out, it will be automatically retried

bors bot added a commit that referenced this pull request Mar 15, 2023
12426: filestate/internal: Use stack reference, not name r=abhinav a=abhinav

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return `organization/$project/$name`.

Change extracted from #12134


Co-authored-by: Fraser Waters <fraser@pulumi.com>
bors bot added a commit that referenced this pull request Mar 15, 2023
12426: filestate/internal: Use stack reference, not name r=abhinav a=abhinav

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return `organization/$project/$name`.

Change extracted from #12134


Co-authored-by: Fraser Waters <fraser@pulumi.com>
@bors
Copy link
Contributor

bors bot commented Mar 15, 2023

Timed out.

filestate backend currently operates exclusively with stack names.
All its internal pass around just the stack name, and nothing else.
This makes it a bit difficult to add project support to the backend.

This is a refactor in advance of adding project support,
changing the internals of filestate to pass a stack reference around.
It inspects the reference directly for all its operations.

Note: This contains no behavioral changes.
Name and FullyQualifiedName currently both return just the stack name.
In a future change, once project name is incorporated into the object,
FullyQualifiedName will be able to return `organization/$project/$name`.

Extracted from #12134

Co-authored-by: Abhinav Gupta <abhinav@pulumi.com>
@abhinav abhinav force-pushed the abhinav/filestate-use-local-ref branch from 14fd8f9 to 5ba5f26 Compare March 16, 2023 21:45
@abhinav
Copy link
Contributor Author

abhinav commented Mar 16, 2023

bors merge

@bors
Copy link
Contributor

bors bot commented Mar 16, 2023

Build succeeded:

  • bors-ok

@bors bors bot merged commit c05e46c into master Mar 16, 2023
@bors bors bot deleted the abhinav/filestate-use-local-ref branch March 16, 2023 22:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/no-changelog-required This issue doesn't require a CHANGELOG update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants