Skip to content
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

Support permutations in Kustomize #1372

Closed
abergmeier opened this issue Jul 19, 2019 · 4 comments
Closed

Support permutations in Kustomize #1372

abergmeier opened this issue Jul 19, 2019 · 4 comments

Comments

@abergmeier
Copy link

We have 8 permutations for a Deployment. Our current permutation fields are:

  • scenario: [scenario1, scenario2]
  • environment: [dev, prd]
  • processor: [normal, fallback]
  • version: [v1]

Now out of these I need to build:

scenario1 - dev - normal   - v1
scenario1 - dev - fallback - v1
scenario1 - prd - normal   - v1
scenario1 - prd - fallback - v1
scenario2 - dev - normal   - v1
scenario2 - dev - fallback - v1
scenario2 - prd - normal   - v1
scenario2 - prd - fallback - v1

Now I would not mind having 8 overlays. The problem I have with kustomize is, that apparently I cannot do:

# Overlay for: scenario1 - dev - normal   - v1
resources:
- ../common    # Has Deployment
- ../scenario1 # apply changes necessary for scenario1
- ../dev       # apply changes for dev
- ../normal    # apply changes for normal
- ../v1        # Apply v1

and I cannot figure out a good way of having these permutations in kustomize.
Is there an elegant way of mapping that out in customize?

@jbrette
Copy link
Contributor

jbrette commented Jul 19, 2019

@abergmeier Could you try this PR. We are trying to see if it really brings benefits. It solves the simple cases of common imports. Could you send a link to the examples you have. There is also Issue 1292 and Issue 1251 on the same subject.

/cc @tkellen @Liujingfang1 @monopole @apyrgio

@abergmeier
Copy link
Author

What I understand is this (please correct me if I am wrong): Kustomize was designed as a strict inheritance based system. Now for more advanced use cases you try to add composition or diamond behavior on top/side of that?

@jbrette
Copy link
Contributor

jbrette commented Jul 19, 2019

@abergmeier kustomize by design is making a copy of the each object that it reads from the resources; field and this is essential (most of the time). Indeed when you do composition or diamond inheritance, kustomize does not see the objects has having a common ancestor or being identical and detect conflicts

Have a look at this permutation example here

@abergmeier
Copy link
Author

@jbrette Due to immaturity of kustomize for this scenario, we decided to go with Terraform and Operators. We might use kustomize in the limited scope, where CRs are concerned (since they are not yet supported by Terraform).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants