-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Replacements do not work with fields that were set in a parent kustomization. #4099
Comments
@zero-below: This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I'm suffering similar problem with
|
Per @natasha41575's #4031 (comment), it sounds like I'm asking for too much in my example. She writes:
In my case that's arguably possible, but it breaks encapsulation. The environment variable value I mentioned is something that I'd prefer to hide from—at at least not burden with fixing—any overlays that might change the namespace. I have packaged that use of [Time passes ....] Reading #4034, @rjferguson21 shows a concise example in #4034 (comment) much line mine here. Rob shows the base as a Kustomization, but I've found that the same problem arises when including one like it as a Component as well. |
My above example was with including files as But the common use for a replacements block would be to apply environment specific information into more generic modular code...and those environment specific configurations would typically occur at the top of the kustomize tree. Also, note that the behavior is identical if the requires is in a kustomization or a component -- so the normal use case of making a top level set of environment specific settings, then loading a shared configuration with replacements, is also broken. It means that to do a requirements for an environment, the requirements block must be cut and pasted into each separate possible config. |
In my case, I was trying to establish an invariant down in the base, where the Service referred to by this environment variable (in a Deployment pod spec) is defined. Much like name references in kustomize, I was trying to express that this environment variable's value should always "point" at this Service, so that if someone places the Service into a different namespace or adjusts its name, the environment variable's value would follow along accordingly. As |
And realistically -- if I want to use a field from a resource to put into another resource, I can not think of any cases I'd want to use any value other than the FINAL RENDERED value of it. If you see my example above, we take the annotation from a configmap, and put that into the value of another configmap. But then after all that's done, the original configmap annotation is changed in the final product. In what world does it make sense to read a field to reference somewhere else, when the source field isn't yet final rendered value of that field? It just seems to be ripe for having semi-predictable inconsistencies. |
One of the reasons (though not the primary one) for our desire to replace
Quoting from #2052 (comment):
This is what we are trying to avoid. A user should be able to reuse bases and overlays without concerns about effects on other kustomizations in their pipeline.
I am open to updating name references if the replacement source came from a resource name. This would work similarly to the name prefix and suffix transformers which are able to update name references to bases in overlays. However, I think there needs to be a very, very strong case to break kustomization encapsulation more generally. |
I think that's what I'm asking for here, if I understand you correctly. I want my Here's my current configuration that attempts to do this, trying to update the Kong ingress controller's environment variable: replacements:
# Ensure that the namespaced reference to Kong's proxy Service remains
# intact as the namespace or name changes.
#
# We can't configure kustomize's name reference transformer to handle
# this composite reference format.
#
# NB: This only works at this level, but not if we change the namespace or
# name at a higher level, even in a component, per the discussion in
# the following issues and PRs:
# https://github.com/kubernetes-sigs/kustomize/issues/4034
# https://github.com/kubernetes-sigs/kustomize/pull/4031
#
# If kustomize changes how replacements work to allow them to track
# renamings like its name reference transformer does, then we can move
# this configuration back down into the Kong base kustomization.
- source: &source
group: ""
kind: Service
name: kong-proxy
targets:
- select: &target
group: apps
kind: Deployment
name: ingress-kong
fieldPaths:
- &fieldPath spec.template.spec.containers.[name=ingress-controller].env.[name=CONTROLLER_PUBLISH_SERVICE].value
options: &options
delimiter: /
index: 1
- source:
<< : *source
fieldPath: metadata.namespace
targets:
- select: *target
fieldPaths:
- *fieldPath
options:
<< : *options
index: 0 Does my use of |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
Hi, I'm actually facing the same problem. I'm using components to add (or not) an ingress resource to my base and construct my ingress paths with the namespace name and a label. Here is an example :
When i'm calling my base, with my component and that i add my namespace and labels with the kustomize CLI i get an error like :
While at the same time, using vars i get the result i want :
I'll go with the vars for the moment even if it's planned to deprecate. But i would like some advice to handle such things with replacements. Kustomize version |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/remove-lifecycle rotten |
Given that vars are deprecated it seems quite important to fix this |
Any updates on this issue? I was considering using vars after watching, what is apparently an old kubecon talk, and sounds like replacements might not have the same capabilities?? Thanks. |
Totally agree |
I believe this is possible, at least in the scenarios where the replacement Given a folder
and a file called env.required
when kustomize build is applied on the folder either from a different folder with E.g. Separate folder called 'test' that references from
I was looking for a solution of issue I encountered where I want to set Istio Virtual Service weight property dynamically but also keep all the changes under version control. Since all environment variables are Hope this is useful in your usecase though. |
This makes live so much harder not to have it. |
This kind of kills the point of using components to add something meaningful without having to create yet another transformer in the parent that patches the output of the component. @natasha41575 isn't the point of components to access the RA of parents? This is from the KEP
The only issue here is that replacements inside the components are accessing the not yet transformed base resources. |
Describe the bug
replacements
does not work if thesource
resource comes from above thereplacements
in the dependency graph. This is the case whether kustomizations come asComponent
orKustomization
files.Note, the example below uses commonAnnotations to simplify the demonstration, however the same behavior occurs with static resources (such as a configmap.yaml file that sets an annotation statically) -- and it occurs with other fields, not solely metadata.annotations.
The use case:
I have a top level
kustomization.yaml
for each deployed environment (dev/prod/test/etc) that adds commonAnnotations to all of the resources in its tree. It then does aresources: [ ../k8s/base/ ]
, and in the shared kustomization, there's areplacements
entry to, for example, pull a DNS_HOSTNAME from an annotation and put it into a configmap data field, and other various resource spots it needs to go.This worked well with
vars
, which seems to render all of the manifests then do the var replacements afterwards. But withreplacements
, kustomize does not see any fields that are created above itself.Files that can reproduce the issue
replacementsinheritance_test.go.txt
a/kustomization.yaml
b/kustomization.yaml
kustomize build b
Note that all of the resources have the annotation
parent
, but thereplacements
does the replacement using the priorannotations
. Additionally, if you comment out thecommonAnnotations
froma/kustomization.yaml
and then runkustomize build b
, it will panic withpanic: runtime error: invalid memory address or nil pointer dereference
.Kustomize version
{Version:kustomize/v4.2.0 GitCommit:d53a2ad45d04b0264bcee9e19879437d851cb778 BuildDate:2021-07-01T00:44:28+01:00 GoOs:darwin GoArch:amd64}
Platform
Darwin 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec 2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64
The text was updated successfully, but these errors were encountered: