until the follow are reviewed and merged can we remove the labels and annotations from the CRD template?

https://github.com/kubernetes-sigs/controller-tools/pull/691 https://github.com/kubernetes-sigs/controller-tools/issues/454

It doesnt make sense to include something which will be rejected at a later point by native tooling. Maybe better to use kustomize and point to how that could work if needed as an option

This is the very minimal implementation. Some notes:

• I can't use a default value for the imagePullSecrets in values.yaml, as this should only be specified by the user if necessary. To let the user know about the feature, I render a comment in values.yaml with an example how to use it.
• I use toJson in the helm expression to get started somewhere
• There could be some refactoring done generally to handle PodSpec uniformly in one place. Currently there is quite a few duplicate code in daemonset.go and deployment.go. For this PR I just kept it like it is, and implemented in handling in an own package
• I tested the generate e2e app chart, and it looked good at the first glace.

Please let me know what you think about it.

Hi, I'm very impressed with helmify, saving me a lot of work, thank you!

One problem... PS C:\dev\Helm\Helmify\One> helm install firstheml mychart Error: parse error at (mychart/templates/mongodb-configmap.yaml:8): unclosed action

that file looks like this apiVersion: v1 kind: Secret metadata: name: {{ include "mychart.fullname" . }}-mongodb-secret labels: {{- include "mychart.labels" . | nindent 4 }} data: mongo-root-password: {{ required "mongodbSecret.mongoRootPassword is required" .Values.mongodbSecret.mongoRootPassword | b64enc | quote }} mongo-root-username: {{ required "mongodbSecret.mongoRootUsername is required" .Values.mongodbSecret.mongoRootUsername | b64enc | quote }}

the .Values file contains mongodbSecret: mongoRootPassword: "" mongoRootUsername: ""

All help much appreciated

Doug

In kustomization.yaml it is possible to generate secrets using secretGenerator:

secretGenerator:
- files:
  - ca.crt
  name: ca
  type: opaque
- envs:
  - envfile.env
  name: my-secret
  type: opaque

I would like the helmify tool to generate the secrets in the Helm Chart output.

The following snippet of YAML results in an invalid credentials.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: spellbook-credentials
type: Opaque
data:
  MQTT_HOST: "Zm9vYmFy"
  MQTT_PORT: "Zm9vYmFy"
  ELASTIC_HOST: "Zm9vYmFy"
  ELASTIC_PORT: "Zm9vYmFy"
  ELASTIC_PROTOCOL: "Zm9vYmFy"
  ELASTIC_PASSWORD: "Zm9vYmFy"
  ELASTIC_FOOBAR_HUNTER123_MEOWTOWN_VERIFY: "Zm9vYmFy"

The resulting output:

apiVersion: v1
kind: Secret
metadata:
  name: {{ include "spellbook.fullname" . }}-credentials
  labels:
  {{- include "spellbook.labels" . | nindent 4 }}
data:
  ELASTIC_FOOBAR_HUNTER123_MEOWTOWN_VERIFY: {{ required "credentials.elasticFoobarHunter123MeowtownVerify
    is required" .Values.credentials.elasticFoobarHunter123MeowtownVerify | b64enc
    | quote }}
  ELASTIC_HOST: {{ required "credentials.elasticHost is required" .Values.credentials.elasticHost
    | b64enc | quote }}
  ELASTIC_PASSWORD: {{ required "credentials.elasticPassword is required" .Values.credentials.elasticPassword
    | b64enc | quote }}
  ELASTIC_PORT: {{ required "credentials.elasticPort is required" .Values.credentials.elasticPort
    | b64enc | quote }}
  ELASTIC_PROTOCOL: {{ required "credentials.elasticProtocol is required" .Values.credentials.elasticProtocol
    | b64enc | quote }}
  MQTT_HOST: {{ required "credentials.mqttHost is required" .Values.credentials.mqttHost
    | b64enc | quote }}
  MQTT_PORT: {{ required "credentials.mqttPort is required" .Values.credentials.mqttPort
    | b64enc | quote }}

Running helm install will error out because of the invalid YAML generated for key names past a certain length:

$ helm install -f ./contrib/k8s/examples/spellbook/values.yaml webrtc-dev-telemetry ./contrib/k8s/charts/spellbook
Error: INSTALLATION FAILED: parse error at (spellbook/templates/credentials.yaml:8): unterminated quoted string

Thanks for your work on this, by the way.

It is considered a best practise to include an imagePullSecrets field in values.yaml so that the consumer of a helm chart can use a private registry, for which a Secret has already been created.

It would be nice if helmify checks if there is anything assigned to the ImagePullSecrets field of a PodSpec (which may be part of a Deployment, DaemonSet, ...). If this is set, helmify should continue as-is.

But if the ImagePullSecret is not set, helmify should include a imagePullSecrets in values.yaml and include it in the PodSpec, if it has been set by the user.

What do you think?

If you got something like this in the kustomize file:

authorizedUsers: ["user1", "user2"]

Or like this:

authorizedUsers:
  - user1
  - user2

Then is parsed as the same value directly on the template, like a hardcoded value, instead of creating this array on the values.yaml and using it on the template as every other variable does.

Expected in the template example:

authorizedUsers: {{ toYaml .Values.authorizedUsers | nindent 8 }}

thanks for making/maintaining this tool, fills a much needed gap in Operator-SDK, appreciated.

per the latest helm3 docs it would be nice if there was the option to place crds in their own directory so that users can take advantage of any further changes to how CRDs are handled during the install process. I can also see how this would be cleaner and makes using other validation tooling simpler to use by convention.

I haven't written much go but could have a look if its more than 5 minutes for anyone else.

Hi there,

Thanks for creating this fantastic project! This will definitely enable more usage when users want to use both kustomize and helm charts but also want to maintain single version of truth.

When I tried to use helmify with kubebuilder for my admission controller, I noticed that inject-ca-from field is not correctly converted into helm charts.

Expected:

    cert-manager.io/inject-ca-from: {{ .Release.Namespace }}/{{ include "chart.fullname" . }}-serving-cert

Actual:

    cert-manager.io/inject-ca-from: {{ .Release.Namespace }}/{{ include "chart.fullname" . }}-admission-controller-system/admission-controller-serving-cert

Looks like its namespace and prefix is not correctly trimmed. Somehow appMeta.ChartName() is always chart, so it fails to remove those prefix.

This PR fixes the issue by using appMeta.TrimName() to trim, like other processors.

Let me know if you have any question or comment.

Thanks a lot! Sam

Helmify version: 0.3.15 example chart: https://github.com/fire-ant/consulkv-operator

instructions: clone the example chart and run 'make helm'. the output returns a diff where the labels will not render.

expected result: the go template instruction remains unchanged and is inserted into the labels field of the crd.yaml.

actual result: helmify should render the labels for the crd in 'crds/'

Due to how crds are templated it appears that the labels line of the crd needs to be affixed to include from the _helpers inside the templates directory, alternatively it may be better to handle this templating inside the logic of helmify itself (Im a little unsure of which is better and why)

Hello, arttor, I think daemonset and statefulset are frequently-used resource，and why helmify doesn't support Daemonset and Statefulset? The support for statefulset and daemonset are on plan?

Hi,

I'm a developer in AWS working on k8s ML platform/toolings. I recently came across your helmify tool that seems to solve the same problem we had a while ago.

At first we were deploying our program with kustomize but in our recent release we are supporting both helm and terraform. You can check out our repo: https://github.com/awslabs/kubeflow-manifests

I wonder if we can contribute back to the repo instead of solving the same thing.

It will be helpful if you can:

• Give a brief introduction about yourself
• Who is maintaining the repo? I see there are 13 contributors so far and it seems to be pretty well maintained (last commit was 7 hours ago), but it seems like you do the majority of the commits.
• I see that it's under MIT license, are there other licensing issues you want us to be aware of?

The generated helm chart should allow changing things like:

• annotations
• nodeSelector
• affinity rules
• etc

It would be great if we could support a config file where the user can specify schema/attribute name and field-ref/s and helmify will automatically templatize it.

Example:

vars:
- name: annotations
  optional: true
  objref:
    kind: Deployment
    group: apps
    version: v1
    name: xyz
  fieldrefs:
    - fieldpath: spec.template.metadata.annotation

PS: If this the community and maintainers are interested in I am happy to contribute

Hi, there, could we provide a flag to add a judgment in webhooks and relevant resources(service, volume, etc) while rendering Operator built by kubebuilder?

For our use case, we really want to leverage helmify to keep CRDs and RBAC up to date with changes in the chart kept in the same repository that houses a large set of controllers.

However, we want to maintain the chart (e.g. deployment, values, and so on) ourselves. We would really benefit from individual flags within helmify to control what it generates and what it doesn't (e.g. only do CRDs and RBAC).

The generated Certificate looks like this:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: {{ include "busola-operator.fullname" . }}-serving-cert
  labels:
  {{- include "busola-operator.labels" . | nindent 4 }}
spec:
  dnsNames:
  - '{{ include "{{ .Release.Namespace }}.fullname" . }}-$(SERVICE_NAME).$(SERVICE_NAMESPACE).svc'
  - '{{ include "{{ .Release.Namespace }}.fullname" . }}-$(SERVICE_NAME).$(SERVICE_NAMESPACE).svc.cluster.local'
  issuerRef:
    kind: Issuer
    name: '{{ include "busola-operator.fullname" . }}-selfsigned-issuer'
  secretName: webhook-server-cert

Under spec.dnsNames the template is {{ include "{{ .Release.Namespace }}.fullname" . }} although it should be {{ include "busola-operator.fullname" . }}

I am using helmify version 0.3.7

It works fine when the chart name is different to the namespace name, this only happens when both are the same