Eron Wright

I interpret this feature request as, provide a way to set the `deleteBeforeReplace` option on the child resources. I imagine that you'd want to apply this to a specific child,...

Along these lines would be the ability to use a Pulumi Asset as a chart "value" to get the asset's content.

I don't understand how we'd avoid baking cloud specifics into the provider. Wouldn't it be preferable that eks provider continue to handle this?

I take this issue to be an enhancement request, asking that the Helm Release resource automatically import an existing Helm release. Today we support various import strategies as outlined in...

@martinmesserli it sounds like you should import the release by using the `import` option on the `Release` resource. This should be non-disruptive.

This does seem like a useful feature. We should keep in mind the design principle of Kustomize (from [Eschewed Features](https://kubectl.docs.kubernetes.io/faq/kustomize/eschewedfeatures/#build-time-side-effects-from-cli-args-or-env-variables)), that informed the simplistic design of the `Directory` resource. >...

Some background information: https://github.com/kubernetes-sigs/kustomize/blob/master/examples/remoteBuild.md Seems like Kustomize uses the locally-installed `git` tool and I wonder if a possible workaround is to pre-configure your local environment, e.g. to use a credentials...

I tested this feature branch (which also contains the unmarshaling fix) with the pulumi-kubernetes provider and it seems to work really well. Here's the patch that I applied: https://github.com/pulumi/pulumi-kubernetes/compare/eronwright/any-resource?expand=1 Then...

Since `defaultProviders` seems to allow side-by-side versions, why aren't the explicit providers handled in this same way?

To repro, simply deploy a ConfigGroup containing a ConfigMap: ```yaml name: issue-1642 runtime: yaml resources: cg: type: kubernetes:yaml/v2:ConfigGroup properties: objs: - apiVersion: v1 kind: ConfigMap metadata: name: issue-1642 ``` Delete...