Open ghostsquad opened 12 months ago
I think this is not specific to ConfigGroup but is a limitation of components in general. This issue is tracking a general enhancement: https://github.com/pulumi/pulumi/issues/8969
Regarding the transformations, I think you should be able to return new options, not modify the existing one. I haven't tried it right now but the first example on the following page seems to be doing what you need: https://www.pulumi.com/docs/concepts/options/transformations/
The ConfigGroup transformation is special. It's not the standard.
@mikhailshilkov you'll notice that the yaml
package has it's own Transformation
type:
Transformations: []yaml.Transformation{
This is not the same as pulumi.ResourceTransformation
@mikhailshilkov alternatively, if there's a way to pass a pulumi.ResourceTransformation
to the ConfigGroup that modifies some set of resources that configGroup manages, then that actually means that the yaml.Transformation
is redundant. If this scenario is possible, I'd like to know how that can be accomplished with an example.
@ghostsquad thanks for the report and sorry about the confusion about which type of transformation you're referring to. It's true there's two variations - the general-purpose transformation as described here, and a transformation provided by the pulumi-kubernetes provider as described here. The key difference is that the former presents you with Pulumi resource properties, whereas the latter presents you with the Kubernetes object.
It is also true that the Go SDK for pulumi-kubernetes has a design flaw in that you cannot mutate the resource options within the kubernetes-centric transformation function, despite what the "YAML with Transformations" example shows.
As a workaround, I do think that you could mutate the resource options using the general-purpose transformation.
@EronWright what I don't totally understand is how that would work. A ConfigGroup
generates resources for each k8s object it finds. Could you provide an example of how to use the general-purpose transformation that targets a specific resource within the ConfigGroup?
@ghostsquad the general-purpose transformation function that's attached to a given resource is invoked for each child resource (in addition to the resource itself). Please take a look at the example here that shows how to identify the sub-resource you seek to mutate. Also, feel free to reach out to me on the Pulumi Community slack workspace for more assistance.
Note to implementors, be sure to make a copy of the opts before passing them to transform function, as the other SDKs do. For example: https://github.com/pulumi/pulumi-kubernetes/blob/9b2f918b864ce2b5e671148653cb16d2edc2f70d/sdk/nodejs/yaml/yaml.ts#L3249-L3255
Regarding the API change we'd need to make, consider making use of the ResourceOptions
struct that was introduced in https://github.com/pulumi/pulumi/issues/11698.
Ok, I think this makes sense. I see now, by looking at the state, what the subresources look like:
@EronWright if I get this working, I'd like to submit an example of how to do this for everyone else. I often find the pulumi documentation to be lacking in thorough examples for Go š . I think Go is one of the harder languages to use effectively with Pulumi. How would I go about submitting an example that would show up somewhere on the site?
@ghostsquad I believe you'd contribute to pulumi-hugo; cc @pulumi/docs .
Hi @ghostsquad,
The best place to submit an example would be in the pulumi/examples repo. That will then get funneled to the How-To guides section on the site.
Hello!
Issue details
I'm unsure how to implement
ignoreChanges
resource option with the yaml.ConfigGroup resource. It would be nice to have an example of this.EDIT: I was pointed to this: https://www.pulumi.com/registry/packages/kubernetes/api-docs/yaml/configgroup/#yaml-with-transformations
Of which would seemingly allow me to transform a resource's
resourceOptions
, including theignoreChanges
resourceOption. However, upon further investigation, I noticed that this won't work (in Golang). Slices in Golang are not reference values. Appending to a slice doesn't change the original slice, it makes a new one. The transformation here is not returning the new slice.Affected area/feature
yaml.ConfigGroup
/Go