[Question] Predefine values.yaml content

[pmoscode]

Hi,

I have a idea / question / feature request. It would be a great feature, if one could predefine the fields / attributes, which should be exported to values.yaml.

It could be something like a "mapping document" per resource file:

deployment-mapping.yaml:

mappings:
  - key: spec.template.spec.containers[0].ports
    value: config.firstContainer.ports

It could be something like a key / value list. The key describes the yaml path in the resource, the value key describes the corresponding key in the values.yaml

This could give more control over, what will become content of the values.yaml.

Would this be a helpful feature? And I'm open for discussions.

[arttor]

thats a great idea. a couple of questions:

1. helmify accepts list of multiple yamls in stdin. So selector should be able to filter manifests. For example, select spec.template.spec.containers[0].ports for kind=Deployment and name=my-app. how to support it?
2. how to provide mappings to helmify? Only in a file or it will be possible to use envars or flags?

[pmoscode]

Hi, so here my thoughts:

1. it's - indeed - a good question. I guess, there is no 100% bullet-proof approach. What I could imagine:

   • Like you said, a kind/name selector. But the "name" selector can't be an "equals" selector. It has to be some kind of "contains" selector, because some Kube-resource-generators adds a random prefix / suffix to the name (like cdk8s).
   • A less generic, but more "helmify" way could be a dedicated "label" inside metadata. Something like "helmify-selector: deployment-one". But this would require to add this label at time of generation. (This would be something like Helm is doing to know, which resources belongs to it)
   • A third, but less "fancy" way would be: Only allow to use this feature, when using the "-f" flag. Then the resource filenames must match the mapping filename (or some key inside the mapping file) - but I guess, this is a less feasible way.

2. This one is easier: I would separate the resource content and the "mapping" content. The "mapping" content should be a yaml file provided via ENV var or - in addition - overridden via flag. If nothing is provided, helmify behaves like it's now...

[arttor]

• A third, but less "fancy" way would be: Only allow to use this feature, when using the "-f" flag. Then the resource filenames must match the mapping filename (or some key inside the mapping file) - but I guess, this is a less feasible way.

I think that there is no fundamental reason why we should disable this feature based on type of input. It is better to abstract input as a stream of yaml objects. Probably we can filter objects by kind/name/namespace because it is unique object identifier in k8s. And i fully agree that it is a good idea to support wildcards in such filters.

2. This one is easier: I would separate the resource content and the "mapping" content. The "mapping" content should be a yaml file provided via ENV var or - in addition - overridden via flag. If nothing is provided, helmify behaves like it's now...

Agree, i also think that the simpliest way is to provide path to file contiaing mappings as CLI flag.

[pmoscode]

Ok, so now, what next? 😳

[arttor]

I think that it useful feature but unfortunately in don't have capacity to implement it. I can help with answering questions and codereview if someone will implement it.

[pmoscode]

Ah, ok.👍