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

Allow using the same base with multiple overlays or transformations #38

Closed
sethpollack opened this issue May 25, 2018 · 15 comments
Closed

Comments

@sethpollack
Copy link
Contributor

sethpollack commented May 25, 2018

Here is an example https://github.com/sethpollack/kustomize_example

When you run kustomize build cluster_a

You get the following error:

Error: there is already an entry: "extensions_v1beta1_Deployment_example.yaml"

Is that the desired result? Or should they be treated as unique based on the namePrefix that they use?

@sethpollack
Copy link
Contributor Author

@monopole I would love to get your thoughts on this?

@monopole
Copy link
Contributor

monopole commented Jun 5, 2018

IMO, this is a dupe of #18, or a very legitimate complaint about a terrible error message :)

I see you've started on #18, let's see what happens after that.

@monopole
Copy link
Contributor

monopole commented Jun 5, 2018

I'm not sure if this is about namespaces or about a desire to wrap two overlays with a third
kustomization that allows the overlays to be built with one command rather than two. We can clear that up shortly.

@sethpollack
Copy link
Contributor Author

sethpollack commented Jun 5, 2018

I want two deployments with the same name and the same namespace with different prefixes. But the check happens before the prefix transform runs.

but two deployments with the same name in different namespaces would be a similar issue.

@monopole
Copy link
Contributor

monopole commented Jun 5, 2018

Please state the desired end result in yaml :)

@monopole
Copy link
Contributor

monopole commented Jun 5, 2018

Or lets just wait till your #54 is in. The application_test in that PR should define a starting point for further behavior improvements.

@sethpollack
Copy link
Contributor Author

It would look like

apiVersion: v1
kind: Namespace
metadata:
  labels:
    cluster: a
  name: example
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: example
    cluster: a
    env: prod
  name: prod-example
  namespace: example
spec:
  selector:
    matchLabels:
      app: example
      cluster: a
      env: prod
  template:
    metadata:
      labels:
        app: example
        cluster: a
        env: prod
    spec:
      containers:
      - image: nginx
        name: nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: example
    cluster: a
    env: stag
  name: stag-example
  namespace: example
spec:
  selector:
    matchLabels:
      app: example
      cluster: a
      env: stag
  template:
    metadata:
      labels:
        app: example
        cluster: a
        env: stag
    spec:
      containers:
      - image: nginx
        name: nginx

@sethpollack sethpollack changed the title Declare multiple applications with a single kustomization.yaml file Allow using the same base with multiple overlays or transformations Jun 20, 2018
@sethpollack
Copy link
Contributor Author

another example of needing to use the same base multiple times would be #126 if I wanted to create multiple cronjobs I would get the same error

Error: there is already an entry: "batch_v2alpha1_CronJob_example.yaml"

@Liujingfang1
Copy link
Contributor

Liujingfang1 commented Jun 20, 2018

SOLUTION1

You want to be able to deploy multiple deployment objects, say prod-example and stag-example. While kustomize treats them as one object example. You couldn't do this since kustomize identifies an object from the base. It assumes you don't fork/copy this object into a new one.
Let me investigate if we can find a solution.
As a workaround, you can add the label cluster: a to different variants and run kustomize build for each variant.

@Liujingfang1
Copy link
Contributor

@sethpollack I propose a different approach instead of using the same base with multiple overlays. We can have some notion to let kustomize know that it deals with multiple kustomizations instead of only one. Then for each of them, process it as usual. Then we avoid this problem.
The format is like this

kustomizations:
- ./prod
- ./stag

commonLabels:
  cluster: a

@sethpollack
Copy link
Contributor Author

That would work.

@droot
Copy link
Contributor

droot commented Jun 20, 2018

@sethpollack would like to hear your feedback about SOLUTION1 that @Liujingfang1 suggested above.

@sethpollack
Copy link
Contributor Author

sethpollack commented Jun 21, 2018

@droot The goal for me would be to have a single kustomization file that represents my entire cluster.

Also there are other areas where the second solution will help out such as reusing the same base resource multiple times with different patches.

For example if I want several cronjobs with different names, schedules, and commands - with the current setup I would not be able to use patches and would need to copy the entire cronjob for each variant of it.

@Liujingfang1
Copy link
Contributor

#204 should have fixed this problem.

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

4 participants