I just opened this issue to get a documented examp...
# kubernetes
b
I just opened this issue to get a documented example of this for the next person, but I was wondering if anyone would no off hand how to
ignoreChanges
for a
ConfigGroup
within the Kubernetes provider? https://github.com/pulumi/pulumi-kubernetes/issues/2666
s
b
@stale-answer-34162 ya, I'm aware of the resource option, I just don't know how to "select" the resources I care about.
so, like select a resource by name, apiVersion, kind, namespace, etc, and then ignore a specific field within it
s
yeah so it probably selectable in json or yaml format. look at how it is organized in the state file.
b
oh, that's a good idea! I didn't think to look at the state file
is there a way to do specify an ignoreChanges like a transformation? (make it dynamic)
the only thing I can think of right now is do some preprocessing of the yaml before passing it (and the ignoreChanges array) to the
ConfigGroup
resource
s
idk but you could try https://www.pulumi.com/ai
b
like, unmarshal all the resources into
[]map[string]any
so I can see what's inside, and dynamically construct the
ignoreChanges
array from that.
d
You should be able to use transformations for this. Setting up an example now
oh, there's an example of modifying resource options on the docs. You can substitute
Alias
for
IgnoreChanges
. https://www.pulumi.com/registry/packages/kubernetes/api-docs/yaml/configgroup/#yaml-with-transformations
b
oh I see
because the ConfigGroup produces the other resources, using a transformation allows me to inject other resourceOptions, such as
ignoreChanges
into specific resources.
Thanks!
I'll try this out and see if I run into any problems
Copy code
// Set a resource alias for a previous name.
func(state map[string]interface{}, opts ...pulumi.ResourceOption) {
	if state["kind"] == "Deployment" {
		aliases := pulumi.Aliases([]pulumi.Alias{
			{
				Name: pulumi.String("oldName"),
			},
		})
		opts = append(opts, aliases)
	}
},
uh... this shouldn't work...
opts
isn't a pointer.. this append operation would remain local to the this transformation function (it would not be visible to the code that calls this transformation)
maps are pointers though, so it makes sense that changes to a map will be seen from outside the transformation function (after the transformation runs).
am I missing something?
d
I think you're right, and this is a limitation in the go-sdk version of the provider. It's worth updating your issue into a feature request
b
well... I think this is more of a bug than a feature request
I've updated this issue