Eron Wright
Some example manifests for exercising the prerequisites feature. In this case, we would expect the "child" stacks to force the "parent" stack to be re-synced periodically. This functionality is powered...
Most resources in this provider are implemented using Azure Resource Manager (ARM). There is some support for "custom resources" that are not ARM-based, for example the Blob resource (see [code](https://github.com/pulumi/pulumi-azure-native/blob/93902b7671e8ad9d47c4b70264237576566db71b/provider/pkg/resources/customresources/custom_storage.go#L170))....
Here's a thought-experiment to argue against taking this change. Imagine you are deploying a third-party Chart and, over time, the chart version changes and, over time, the chart's resources change....
@blampe can we close this PR?
Good news everyone, we just release a preview of Pulumi Kubernetes Operator v2. This new release has a whole-new architecture that provides much better horizontal scalability. Please read the announcement...
Sorry for the inconvenience, it is an aspect we'd like to improve upon. A possible workaround is to use a [transform function](https://www.pulumi.com/blog/kubernetes-chart-v4/#new-style-pulumi-transformations) to apply an "alias" option to each child....
Good news everyone, we just release a preview of Pulumi Kubernetes Operator v2. This new release has a whole-new architecture that uses pods as the execution environment. The locking story...
This ticket is about adding `__pulumiType` metadata to the overlay resources, `ConfigGroup`, `ConfigFile`, etc. The `Chart` resource has already been dealt with.
A related PR: https://github.com/pulumi/pulumi-kubernetes/pull/2918
@blampe note that Chart v4 uses server-side dry-run, to support the lookup method. Lookup is similar to a Pulumi resource `get` method, in that it assumes the object exists even...