This is basically the same as https://github.com/kubernetes-sigs/kustomize/issues/119.
Reopening, as the issue was closed.
The reason for reopening is that we (Arrikto) believe that the reasons given for eschewing this feature don't really apply.
It's also interesting that other use-cases mandating glob-like use have come up from the Kustomize team (although I feel the particular one could benefit from more explicit globbing):
https://github.com/kubernetes-sigs/kustomize/issues/3204
Is your feature request related to a problem? Please describe.
I want to automatically pick up new kustomizations inside a folder. For example, we have a structure like this:
user-resources
├── user1
└── user2
...
and I want to have a kustomization file that automatically imports everything under user-resources:
resources:
- path/to/user-resources/*
Describe the solution you'd like
Kustomize should support globbing in resources. This feature is eschewed right now and the given reason is:
kustomize supports the best practice of storing one’s entire configuration in a version control system.
Globbing the local file system for files not explicitly declared in the kustomization file at kustomize build time would violate that goal.
Allowing globbing in a kustomization file would also introduce the same problems as allowing globbing in java import declarations or BUILD/Makefile dependency rules.
kustomize will instead provide kustomization file editting commands that accept globbed arguments, expand them at edit time relative to the local file system, and store the resulting explicit names into the kustomization file.
I'd like to elaborate why we are not very clear on those arguments.
kustomize supports the best practice of storing one’s entire configuration in a version control system.
Globbing the local file system for files not explicitly declared in the kustomization file at kustomize build time would violate that goal.
This is not clear to us. Storing the entire configuration in a VCS means that checking out a specific commit and running kustomize build should produce the same result everytime. That's why kustomize has explicitly avoided CLI arguments and environment variables. But in the case of globs, the result of globbing the filesystem of a specific commit will always be the same. There is no hidden state here.
Allowing globbing in a kustomization file would also introduce the same problems as allowing globbing in java import declarations or BUILD/Makefile dependency rules.
The problem mentioned in the referenced blog post is that when importing with globs, name collisions may occur. The example given in the blog post is that if one writes:
import java.util.*;
import java.awt.*;
// Where did the List class come from?
List choices = new List();
and the List class is declared by two imports, Java will silently keep the one declared later in the code.
However, this doesn't really apply to kustomize, because:
Kustomize imports are not very useful for deterring collisions. If one follows the suggested best practice and imports both java.util.List and java.awt.List, then it's immediately clear there is a collision, so catastrophe avoided. However, if one imports a/deployment.yaml and b/deployment.yaml, it's not really clear if there is a resource collision.
Thus, we believe this drawback doesn't really exist for a tool like kustomize.
Describe alternatives you've considered
Kustomize provides the alternative of CLI commands that support globbing and can refresh the kustomizations.
However, this imposes an additional burden on the user, to track every single place where this must occur.
I'd love to hear your thoughts on this @monopole @Liujingfang1 @Shell32-Natsu
Also cc'ing the author of the original issue @ahmetb
tculp
commented
2 months ago
This is basically the same as https://github.com/kubernetes-sigs/kustomize/issues/119. Reopening, as the issue was closed. The reason for reopening is that we (Arrikto) believe that the reasons given for eschewing this feature don't really apply.
It's also interesting that other use-cases mandating glob-like use have come up from the Kustomize team (although I feel the particular one could benefit from more explicit globbing): https://github.com/kubernetes-sigs/kustomize/issues/3204
Is your feature request related to a problem? Please describe.
I want to automatically pick up new kustomizations inside a folder. For example, we have a structure like this:
and I want to have a kustomization file that automatically imports everything under
user-resources:Describe the solution you'd like
Kustomize should support globbing in resources. This feature is eschewed right now and the given reason is:
I'd like to elaborate why we are not very clear on those arguments.
This is not clear to us. Storing the entire configuration in a VCS means that checking out a specific commit and running
kustomize buildshould produce the same result everytime. That's whykustomizehas explicitly avoided CLI arguments and environment variables. But in the case of globs, the result of globbing the filesystem of a specific commit will always be the same. There is no hidden state here.The problem mentioned in the referenced blog post is that when importing with globs, name collisions may occur. The example given in the blog post is that if one writes:
and the
Listclass is declared by two imports, Java will silently keep the one declared later in the code.However, this doesn't really apply to kustomize, because:
java.util.Listandjava.awt.List, then it's immediately clear there is a collision, so catastrophe avoided. However, if one importsa/deployment.yamlandb/deployment.yaml, it's not really clear if there is a resource collision.Thus, we believe this drawback doesn't really exist for a tool like
kustomize.Describe alternatives you've considered
Kustomize provides the alternative of CLI commands that support globbing and can refresh the kustomizations. However, this imposes an additional burden on the user, to track every single place where this must occur.
I'd love to hear your thoughts on this @monopole @Liujingfang1 @Shell32-Natsu Also cc'ing the author of the original issue @ahmetb