-
Notifications
You must be signed in to change notification settings - Fork 115
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
[sdk/nodejs] Add a ready attribute to await Helm Charts #1364
Conversation
PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting. Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. Any ideas on how to test this?
Hey @lblackstone what would the code look like for the python sdk, I am guessing very similar. Wanted to give it a try. |
I haven't had a chance to work on it yet, but should be the same basic concept. Easiest way to test out would be modifying the relevant Helm/YAML SDK files in your virtualenv |
I'm not sure yet. I'd like to verify that the ConfigMap isn't created until after all of the Chart resources, but I'm not sure how to get that information. I don't suppose there's an easy way to get timestamps of resource creation events? @pgavlin |
b9f30d4
to
e7d952d
Compare
PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting. Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR |
/run-acceptance-tests |
Please view the PR build - https://github.com/pulumi/pulumi-kubernetes/actions/runs/358343347 |
Note: this PR is only for NodeJS. Once this merges, I'll follow with the other SDKs |
PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting. Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR |
…ernetes into lblackstone/helm-await
PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting. Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR |
/run-acceptance-tests |
Please view the PR build - https://github.com/pulumi/pulumi-kubernetes/actions/runs/360140970 |
PR is now waiting for a maintainer to run the acceptance tests. This PR will only perform build and linting. Note for the maintainer: To run the acceptance tests, please comment /run-acceptance-tests on the PR |
@@ -255,7 +255,7 @@ export class Chart extends yaml.CollectionComponentResource { | |||
} | |||
}); | |||
|
|||
this.ready = this.resources.apply(m => Object.values(m).map(r => pulumi.output(r))); | |||
this.ready = this.resources.apply(m => Object.values(m)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nice, I was just gonna say the same thing ✅
/run-acceptance-tests |
Please view the PR build - https://github.com/pulumi/pulumi-kubernetes/actions/runs/360168574 |
Proposed changes
After chatting with @pgavlin about this problem, we determined that Helm Charts were not awaiting properly because child resources are not known at the time the Chart is initialized. The most promising solution appears to be exposing a field on the Chart class that can be passed into the
dependsOn
option. The existingresources
field is a map rather than an array, so we either need to expanddependsOn
support to include maps, or create a new field on the Chart class that works with the existing definition.This PR takes the latter approach, and creates a new
.ready
field that can be passed directly to thedependsOn
option. This change makes dependent resources wait until all Chart subresources are ready as expected. Here's an example program to demonstrate:Here's what this looks like before/after the change (notice the
test
ConfigMap
gets created immediately onBefore
):Before
After
Related issues (optional)
Related to #861