Ability to render just an entry point template

[autouser]

For better templates organization and flexibility I propose to add a possibility to render just one entry point.

Currently we render all templates in alphabetical order. We can add an argument to gen command to specify just one template to render k8t gen [...] --entry=main and let jinja2 to manage dependencies through include and import.

Example:

.
├── 00-namespace.yaml.j2
├── 01-hermes
│   ├── 01-configs.yaml.j2
│   ├── 02-secrets.yaml.j2
│   ├── 03-deploy.yaml.j2
│   └── main.yaml.j2
├── 02-insign
│   ├── 01-configs.yamml.j2
│   ├── 02-secrets.yamml.j2
│   ├── 03-deploy.yamml.j2
│   └── main.yaml.j2
└── main.yaml.j2

# main.yaml.j2
{% include '01-hermes/main.yaml.j2' %}
{% include '02-insign/main.yaml.j2' %}

# 01-hermes/main.yaml.j2
{% include '01-hermes/configs.yaml.j2' %}
{% include '02-hermes/secrets.yaml.j2' %}
{% include '03-hermes/deploy.yaml.j2' %

[sl4vr]

Existing functionality already allows to place templates into directories. So that example above would work without main.yaml.j2 files and still work with environments and cluster overwrites based on full template path, like 01-hermes/01-configs.yaml.j2.

Example:

.k8t
├── templates
│   ├── 01-hermes
│   │   ├── 01-configs.yaml.j2
│   │   ├── 02-secrets.yaml.j2
│   │   └── 03-deploy.yaml.j2
│   └── 02-insign
│       ├── 01-configs.yaml.j2
│       ├── 02-secrets.yaml.j2
│       └── 03-deploy.yaml.j2
└── clusters
    └── clark-at
    	└── environments
			└── templates
				└── 01-hermes
			        ├── 01-configs.yaml.j2
			        ├── 02-secrets.yaml.j2
			        └── 03-deploy.yaml.j2

[autouser]

Existing functionality already allows to place templates into directories. So that example above would work without main.yaml.j2 files and still work with environments and cluster overwrites based on full template path, like 01-hermes/01-configs.yaml.j2.

Example:

.k8t
├── templates
│   ├── 01-hermes
│   │   ├── 01-configs.yaml.j2
│   │   ├── 02-secrets.yaml.j2
│   │   └── 03-deploy.yaml.j2
│   └── 02-insign
│       ├── 01-configs.yaml.j2
│       ├── 02-secrets.yaml.j2
│       └── 03-deploy.yaml.j2
└── clusters
    └── clark-at
    	└── environments
			└── templates
				└── 01-hermes
			        ├── 01-configs.yaml.j2
			        ├── 02-secrets.yaml.j2
			        └── 03-deploy.yaml.j2

The idea is to let k8t templates devs to decide how to customize cluster during overriding.
In the current implementation, if you (hypothetically) add something to hermes service (like xxx.yaml.j2) you'll bring it to the cluster env. If you have several clusters then you need to check all of them.

It's possible to handle the problem with guard values but it'll create more complexity. E.g. you can't be sure that you disable the concrete template because guard can be reused in several templates.

Another problem is macroses. It would be nice to have them shared. But if just add something like 00-shared.yaml.j2 to the root then it's also will be included into the result of generation so you need to control the visibility of the macroses.

Manifest (main) will allow to just disable not required templates and control order of including. You can override only main templates and have a single source of control.

@sl4vr I don't propose to switch to this behaviour completely, we can just add with feature and if it's not needed then users can just use old behaviour

[sl4vr]

In the current implementation, if you (hypothetically) add something to hermes service (like xxx.yaml.j2) you'll bring it to the cluster env. If you have several clusters then you need to check all of them.

Afaik it's intended to do so since root templates are supposed to be present in all clusters and environments

It's possible to handle the problem with guard values but it'll create more complexity. E.g. you can't be sure that you disable the concrete template because guard can be reused in several templates.

But yup, guard values can be used when you want to render something everywhere but in some particular cases. It's pretty handy with current root -> environment -> cluster -> cluster/environment workflow because you can control what will be rendered with just values.yaml. Values can and should be overwritten in nested levels such as cluster, cluster/environment, etc. IMO it's by design. Good point though, that values can be overwritten within templates, k8t could probably warn about such occurrences.

Another problem is macroses. It would be nice to have them shared. But if just add something like 00-shared.yaml.j2 to the root then it's also will be included into the result of generation so you need to control the visibility of the macroses.

I would love to make values.yaml to be Jinja templates, it would seem to resolve the issue you described.

Manifest (main) will allow to just disable not required templates and control order of including. You can override only main templates and have a single source of control.

@sl4vr I don't propose to switch to this behaviour completely, we can just add with feature and if it's not needed then users can just use old behaviour

Probably the only reason I'm reluctant to that is that it won't be clear from file structure anymore what is used and what's not. Anyway I don't say it's bad idea, probably that's a better way to use k8t.

Anyway I just wanted to pointed out existing way to organise templates (as I thought that's what you've been looking for), but what's up to this feature it's better address to @AFriemann.
Also seems related to #28

[autouser]

Probably the only reason I'm reluctant to that is that it won't be clear from file structure anymore what is used and what's not. Anyway I don't say it's bad idea, probably that's a better way to use k8t.

Maybe I see it from devs perspective :) Jinja is very powerful and I was excited to use it's features, especially macroses and imports for code reuse.

Now after your comments I think that maybe the proposed feature will bring some unnecessary complexity 🤔
Let's @AFriemann to say his opinion

[AFriemann]

theoretically this is now possible via the -t/--template-file option. All included templates would have to be specified though.

does that solve your issue @autouser ?

[AFriemann]

a possible solution would be to restrict the templates in a normal run to only the entrypoint - I don't think that would be difficult to add tbh.

[autouser]

theoretically this is now possible via the -t/--template-file option. All included templates would have to be specified though.

does that solve your issue @autouser ?

Nice 👍 Yes, I think it solves the issue. Instead of single manifest file we can you a bash script.