diff --git a/proposals/24-07-glob-patterns.md b/proposals/24-07-glob-patterns.md new file mode 100644 index 0000000000..7b23813a21 --- /dev/null +++ b/proposals/24-07-glob-patterns.md @@ -0,0 +1,245 @@ + + +# Add glob pattern support in the `resources` key of a user's `kustomization.yaml` + +**Authors**: +- BitForger + +**Reviewers**: +- natasha41575 +- KnVerey + +**Status**: implementable + + +## Summary + + +File path globbing for the `resources` key enables users to maximize their use of Kustomize in their GitOps and CI/CD workflows. It simplifies their `kustomization.yaml` files by allowing them to pass a set of patterns that are equal to, or children of the `kustomization.yaml`'s working directory. + +## Motivation + + +https://github.com/kubernetes-sigs/kustomize/issues/3205 is one of (at least two that I've seen) issues opened looking for this functionality. + +As operational tasks shift to a declarative approach, the need to apply a large set of manifests from a "source of truth" repository is increasingly common. Currently, Kustomize very tediously requires a user to define every individual path for each resource the user wishes to build and apply. When you have multiple sets of services you need to apply, this can very quickly spiral into `kustomization.yaml` files with a 100 or more lines of resources. File-path globbing was a feature in the past, but was removed, much to the communities chagrin. This proposal seeks to reverse that change. + +**Goals:** + +1. Resource resolution based on glob patterns, at the sibling level and below of the main `kustomization.yaml` file + + + +**Non-goals:** + +1. Resource globbing should not accept exclude patterns + +## Proposal + + +A feature flag will be added to the `kustomization.yaml` called `enableGlobbing` or `enableGlobSupport` that accepts a boolean value. When this flag is enabled, a user can pass glob patterns to the `resources` array and kustomize will take the pattern and collect all sibling and child paths that match the provided pattern. + + +### User Stories + + +#### Story 1 + +Scenario summary: As a end user, I want to use a pattern to apply a bunch of manifests + + +Take the below file structure + +``` +. +└── k8s/ + ├── pipelines/ + │ ├── pipeline_1/ + │ │ ├── pipeline.yaml + │ │ ├── task.yaml + │ │ └── nested/ + │ │ └── task.yaml + │ └── pipeline_2/ + │ └── pipeline.yaml + ├── tasks/ + │ ├── shared_task_1.yaml + │ └── shared_task_2.yaml + └── kustomization.yaml +``` + +A user could pass the following to kustomize to apply all the matching files + +```yaml +resources: + - pipelines/**/*.yaml + - tasks/*.yaml +``` + +Kustomize would build all the matching files (using the already defined rules of kustomize, no name collisions, etc). + +Glob support should work on files names, so a pattern like this should work + +``` +tasks/shared_task_*.yaml +``` + +#### Story 2 + +Scenario summary: As a end user, I want to apply a bunch of kustomizations using a pattern + + +``` +. +└── k8s/ + ├── bases/ + │ ├── app_1/ + │ │ ├── kustomization.yaml + │ │ ├── deployment.yaml + │ │ ├── service.yaml + │ │ └── ... + │ └── app_2/ + │ ├── kustomization.yaml + │ ├── deployment.yaml + │ ├── cronjob.yaml + │ └── ... + └── kustomization.yaml +``` + +A user could pass the following in their `kustomization.yaml` + +```yaml +resources: + - bases/**/ +``` + +### Risks and Mitigations + + +There is the risk that a user could unintentionally include manifests if they choose to use the globbing support and they don't intentionally define their patterns to not be overly broad. For every other user, the file path globbing should be disabled by default so it shouldn't have an effect for them. + +### Dependencies + + +Go has a built in filepath package that should be able to support the described use cases. + +### Scalability + + +There may be a performance impact by using glob searching over looking up each individually named resource. These may scale with the amount of globs to lookup. I would have to do some testing to see how that behaved. + +## Drawbacks + +As discussed, this potentially reduces how explicit you are in defining the manifests you want to apply. However, the consensus seems to be that it's a worthwhile trade-off for the convenience added. + + +## Alternatives + + +Currently, the only other approach is to use a script to re-generate the `kustomization.yaml` every time you go to apply a lot of manifests. This is unnecessary complexity for something many other ops tools support. + +## Rollout Plan + + +I don't believe this will need a formal graduation process as the proposal adds the feature behind an option flag in the `kustomization.yaml`. The defualt behavior of the `resources` key would not change. + + + + +- Will the feature be gated by an "alpha" flag? Which one? +- Will the feature be available in `kubectl kustomize` during alpha? Why or why not? + + + + + +