-
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
add genericGenerator #126
Comments
@sethpollack Can you add some explanation of meaning of each field? I also opened #122 for supporting extensible transformation. It seems to have some overlap with the motivation of |
Sure! This would be a transformation where you can take a base resource A good example would be cronjobs where I may want to create a bunch of them from the same base - just with different names, commands, and schedules. The transformation would just loop through the provided |
Is |
yes |
This feature looks promising to me. I am also thinking about some other use cases that it might support. Say I want to replace a container image name no matter it is in a deployment object or in a pod. How could I define the resource and field path so that it can work? Can you write a brief design doc about this genericGenerator(maybe some other name genericTransformer)? Let have others' opinion on it. |
I think the For example If I have 25 cronjob variations I would need 25 subdirectories with a kustomization and a patch file in each and then do something like your suggestion in #38 to generate them all from the same base resource:
The idea for the
As for the
|
Regardless of the different formats, my understanding based on your examples is that |
correct. |
I can work on a PR for the genericTransformer - once Im done working on the secrets PR. |
No rush on that. I need to think more thoroughly on genericTransformer so that it can serve different usage. |
Ok |
What is your major concern about the above (current way of doing it) ? |
@droot I don't think there is a current way - other than duplicating the entire cronjob for each variant of it. Also I don't think that patches would work anyway since you cant change the name with a patch. |
Let's revisit this request. Recently we added support for multibases with a common base. https://github.com/kubernetes-sigs/kustomize/blob/master/examples/multibases/README.md |
This |
The original request should be able to achieved by multibases support and json patch. Basically, you create a common base for your cronjob. Then create multiple overlays with different prefixes. In those overlays, apply a proper json patch to the cronjob object. |
I've created an example of #126 (comment) for future issue visitors like me. |
hmm I actually think that having genericGenerator is still a great feature to add and is really needed. I totally get the point that this can be done with json patch, but it comes with so much unnecessary overhead. Something like genericGenerator would be much cleaner and more intuitive for this kind of need which is very common. |
@Liujingfang1 Actually genericGenerator is a crucial feature from operations standpoint. Its key difference with anything existing before it is a capability to create new object, instead of modifying existing one. As of now in order to create one modified object, one needs to create a base for specific resource kind, then refer it, and only then patch it. So to create 3 services, you'll have to create one base and then refer it 3 times and patch it 3 times, but it's getting worse if you have other resources have to be managed this way. Anyone who deals with huge fleet of similar applications will run into this issue when there's a need create a bunch of nearly identical (but not identical) resources like Jobs, Services, Deployments, networkPolicies, serviceAccounts just to name a few. Since we have replacement transformer, can we ask to add |
for example:
The text was updated successfully, but these errors were encountered: