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

Allow component providers to return outputs to the engine #15408

Merged
merged 1 commit into from Feb 14, 2024

Conversation

Frassle
Copy link
Member

@Frassle Frassle commented Feb 8, 2024

Description

This adds a new flag to provider Construct and Call requests to indicate that the engine will accept output values in the response.

If a component provider sees that flag set they can return Output PropertyValues and optionally skip filling in the dependency map in the response.

The engine will use the combined information of the dependency map and any dependencies found on any output values in the property to build the final dependency map that is returned to programs.

Checklist

  • I have run make tidy to update any new dependencies
  • I have run make lint to verify my code passes the lint check
    • I have formatted my code using gofumpt
  • I have added tests that prove my fix is effective or that my feature works
  • I have run make changelog and committed the changelog/pending/<file> documenting my change
  • Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version

@pulumi-bot
Copy link
Contributor

pulumi-bot commented Feb 8, 2024

Changelog

[uncommitted] (2024-02-08)

Features

  • [components] Component providers can return output values in their response to the engine.
    #15408

@Frassle Frassle force-pushed the fraser/componentOutputReturn branch 3 times, most recently from 82609d3 to b398705 Compare February 8, 2024 19:54
ret.ReturnDependencies = map[resource.PropertyKey][]resource.URN{}
}
for k, v := range ret.Return {
ret.ReturnDependencies[k] = addOutputDependencies(ret.ReturnDependencies[k], v)
Copy link
Member Author

Choose a reason for hiding this comment

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

This appends to the dependency list, so it's ok for Call to return both, it'll just end up with the same URN duplicated (maybe these should be sets?)

pkg/resource/deploy/source_eval.go Outdated Show resolved Hide resolved
constructResult.OutputDependencies = map[resource.PropertyKey][]resource.URN{}
}
for k, v := range result.State.Outputs {
constructResult.OutputDependencies[k] = addOutputDependencies(constructResult.OutputDependencies[k], v)
Copy link
Member Author

Choose a reason for hiding this comment

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

Again this is appending to the deps map so the provider can return the map, or output values, or both.

@@ -1884,3 +1904,31 @@ func downgradeOutputValues(v resource.PropertyMap) resource.PropertyMap {
}
return result
}

func addOutputDependencies(deps []resource.URN, v resource.PropertyValue) []resource.URN {
Copy link
Member Author

Choose a reason for hiding this comment

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

So tempted to write a reducer for property values

@@ -164,6 +164,8 @@ message CallRequest {
int32 parallel = 11; // the degree of parallelism for resource operations (<=1 for serial).
string monitorEndpoint = 12; // the address for communicating back to the resource monitor.
string organization = 14; // the organization of the stack being deployed into.

bool accepts_output_values = 17; // the engine can be passed output values back, returnDependencies can be left blank if returning output values.
Copy link
Member Author

Choose a reason for hiding this comment

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

The engine now always sets this to true, but it means providers can use it as a flag for if they can return output values or not because old engines won't have set it (so it defaults to false)

@Frassle Frassle force-pushed the fraser/componentOutputReturn branch from b398705 to ae1ad75 Compare February 8, 2024 20:25
@Frassle Frassle force-pushed the fraser/componentOutputReturn branch from ae1ad75 to 384b797 Compare February 8, 2024 20:25
@Frassle Frassle requested a review from a team February 8, 2024 20:40
@Frassle Frassle marked this pull request as ready for review February 8, 2024 20:40
Copy link
Member

@justinvp justinvp left a comment

Choose a reason for hiding this comment

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

LGTM

@Frassle Frassle added this pull request to the merge queue Feb 14, 2024
Merged via the queue into master with commit 556cd9b Feb 14, 2024
46 checks passed
@Frassle Frassle deleted the fraser/componentOutputReturn branch February 14, 2024 09:32
@justinvp justinvp mentioned this pull request Feb 15, 2024
github-merge-queue bot pushed a commit that referenced this pull request Feb 16, 2024
### Features

- [components] Component providers can return output values in their
response to the engine.
  [#15408](#15408)

- [programgen/{dotnet,go,nodejs,python}] Emit missing trivia for
resources and local variables
  [#15419](#15419)

- [sdk/{nodejs,python}] Publish dev versions of the nodejs and python
SDKs


### Bug Fixes

- [cli] Fix `pulumi destroy` to fill in stack config with the secret
config from state, not fresh secret config.
  [#15432](#15432)

- [engine] Engine no longer assumes program dependencies are specified
as semantic versions.
  [#15409](#15409)

- [components/go] Component providers now correctly return output values
to the engine.
  [#15405](#15405)


### Miscellaneous

- [protobuf] Split CallRequest into ResourceCallRequest for the
ResourceMonitor service.
  [#15404](#15404)

- [backend/diy] Add a warning that non-project mode will be deprecated
at some point.
  [#15411](#15411)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants