Hi,

Can you tell us what license this project is under?

Hi there.

I was trying to use the changes from #53 which include support for referencing existing secrets and mounting them in the container filesystem. This however is not working when I reference the v0.41.0 version of the chart (which is the latest) where this change was added.

If I look the released version diff I can see the changes here: afcfc36#diff-bf919b6b281151a677d8090da5f1de872cca2fd7d56a7ec3935555a4e9d583e3

However if I download the chart tarball from here: https://chart.onechart.dev/onechart-0.41.0.tgz

and look at the file: onechart/charts/common/templates/_volumesRef.yaml I don't see the existingFileSecrets change.

So it looks like something's not quite right with that packaged version. Am I missing something?

Thanks in advance!

We use the recreate strategy when a volume is defined.

kubernetes/kubernetes#24198

Issue similar to #58
but I need to mount secret as a file to directory with other, config files.

Current version of onechart does not support args

I am interested in contributing to the project and would like to propose the addition of Horizontal Pod Autoscaling (HPA) support. Before investing time in the development, I want to discuss the feasibility and gather feedback from the maintainers and the community.

hpa:
  enabled: true
  minReplicas: 2
  maxReplicas: 4

    
  metrics:
  - resource:
      name: cpu
      target: 
        type: Utilization
        averageUtilization: 70
    type: Resource
  - resource:
      name: memory
      target: 
        type: Utilization
        averageUtilization: 85
    type: Resource

thank you

Hi Team

Can we add some general guidelines on this project about how to submit pull request and what are the contribution guidelines, if i want to file any bug/issue?

Multiple ingress paths for the same service are not supported

Right now we manually bump the chart version, run make all locally and push to git.
Since the chart repo is hosted on Github Pages, this makes the new version available immediately.

In order to start using git tags and document changes in Github Releases, we should move the release process to Github Actions.

The release experience should be:

• git tag v1.0.0
• git push origin v1.0.0

This will update the chart version and publishes it to Github Pages.

See how a manual release was done in this commit: 35831ac
The changes were achieved by updating the Chart.yaml version field manually to 0.17 and calling make all

Automatic chart version bump is not mandatory, but then we should have a manual process defined.

I use onechart a lot for setting up local integration test environments. Sometimes I need to mount test data from the host but it seems onechart doesn't allow that, unless I'm missing something.

Please make the path variable

https://github.com/gimlet-io/onechart/blob/master/charts/onechart/templates/ingress.yaml#L42

Then using helm template onechart/onechart with ingress keys, I get follownig warning:

networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; 
use networking.k8s.io/v1 Ingress

Hello again!

The bitnami charts have a very useful extraDeploy value, that can be used to add any number of additional, arbitrary resources to a helm release. Would it be possible to have something similar here?

My use case: I need to add a Traefik IngressRoute, a Calico NetworkPolicy, and a SealedSecret.

Cheers,
Loïc

• Values files for OneChart carry all meaningful info that is needed for a containerized deployment to work
• OneChart is a Helm chart. helm template renders the chart into plain text.

The above two statements suggests that we can make a Helm chart that renders KNative serving API yamls. Not Kubernetes yamls, but yamls that KNative and Google Cloud Run understands.

The goal of this issue is to render a basic KNative manifest that is driven by a OneChart values file, like the following:

image:
  repository: nginx
  tag: latest
replicas: 3
containerPort: 5000
vars:
  DUMMY: "test-me"

and after a helm template command, the result can be deployed to Google Cloud Run.

Some info:

• https://ahmet.im/blog/cloud-run-is-a-knative/
• https://knative.dev/docs/reference/api/serving-api/

When we are done, we should review the project by KNative community members: salaboy and tvitale

Specifying ports in values doesn't work as expected.

E.g.:

ports:
  - name: 445
    svcPort: 445

The template tries to fill the name in both the actual name and in targetPort, which doesn't work, as port needs to be a number and name needs to be a string:

Error: INSTALLATION FAILED: Service in version "v1" cannot be handled as a Service: json: cannot unmarshal number into Go struct field ServicePort.spec.ports.name of type string

Instead, maybe support passing targetPort?

ports:
  - name: tcp-445
    svcPort: 445
    targetPort: 445

Offtopic

Name could also be optional:

ports:
  - svcPort: 445
    targetPort: 445

The template could then fill the port name with a concatenation of tcp and the port.

Hi,

Is it be possible to increase readiness probe's initial delay seconds maximum value from 60 seconds [0] to maybe 120 or 180 seconds?

I'm using onechart to run an app which simply doesn't start that fast.

[0] https://github.com/gimlet-io/onechart/blob/master/charts/onechart/values.schema.json#L391

Would it be possible to add the spec.hostNetwork parameter for pods?
This i very helpful for pod whuch need access to the nodes networks.

Thanks!

error when creating \"e13a0f99-0947-4a4d-83aa-ebc252b41580.yaml\": ConfigMap \"myapp-deploy-preview\" is invalid: metadata.labels: Invalid value: \"myapp-deploy/preview\": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')

Will it be possible to specify env for containers in the deployment file?

Since the chart already supports (optional) prometheus rules, would it make sense to support (optional) Prometheus service scraping?

The following is not debugged, just a rough draft to show what I mean:

{{ if .Values.monitor.enabled }}
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: {{ template "robustName" .Release.Name }}
  namespace: {{ .Release.Namespace }}
  labels:
    {{- include "helm-chart.labels" . | nindent 4 }}
  {{- if or .Values.gitRepository .Values.gitSha }}
  annotations:
    {{- if .Values.gitRepository }}
    gimlet.io/git-repository: {{ .Values.gitRepository }}
    {{- end }}
    {{- if .Values.gitSha }}
    gimlet.io/git-sha: {{ .Values.gitSha }}
    {{- end }}
  {{- end }}
spec:
  endpoints:
  - interval: 60s
    params:
      format:
      - prometheus
    path: /metrics # TBD: Needs to also be templated-with-default
    {{ if .Values.monitor.portName }}
    name: {{ .Values.monitor.portName }}
    {{- else if not .Values.ports }}
    name: http
    {{ else }}
    name: {{ Values.ports[0].name }}
    {{ endif }}
    scheme: {{ .Values.monitor.scheme or "http" }}
    {{ if .Values.monitor.scrapeTimeout }}
    scrapeTimeout: {{ .Values.monitor.scrapeTimeout }}
    {{ end }}
  namespaceSelector:
    matchNames:
    - "{{ .Release.Namespace }}"
  selector:
    {{- include "helm-chart.selectorLabels" . | nindent 4 }}
{{ end }}

My use case tries to fix the warning problem when using regex in the ingress path as described here: kubernetes/ingress-nginx#10200.

So, I want to configure pathType from Prefix to ImplementationSpecific to solve this problem.

It would be nice to be able to use the file configmap on the cron-job chart - even better if multiple are supported.
It would also be nice to be able to not override the command as this causes issues with some images.

Changes

• Allow use of File ConfigMap on cron-job
• Allow use of multiple File ConfigMap
• Allow disabling the custom command on the container

Details

Allow use of File ConfigMap on cron-job

Rather trivial. Only need to use the template exposed on the common chart.

Allow use of multiple File ConfigMap

Also trivial. Only need to add YAML file separator "---" at the beggining of each rendered ConfigMap in the common chart.

Allow disabling the custom command on the container

Proposed addition to values.yml:

overrideCommand: true

Default true to not break exisiting behaviour. Can be set to false to just use the default command of the image.

I already implemented both of these so will be opening a PR.

Usecase: there are a lot of images which are almost perfect, but I'd like to modify the entrypoint.

Instead of maintaining a docker image:

• create a deployment with an initContainer and an empty volume
• the init container could create a custom entrypoint.sh on the volume
• map the volume in the main container (let's say: /scripts)
• you can refer the custom entrypoint in the main container

The init container could be used for example:

• git clone a repo to the volume
• git clone a static website repo (hugo,jekyll) build the html
• serve it with nginx

Alternatively instead of creating the entrypoint.sh in an initscript, you could write the script as a configmap (or maybe as a sealed secret if its sensitive)

I have usecase where i can't mount a directory but only a file.

Application uses a config /etc/tinyproxy.conf. Mounting /etc overrides all other configs. Hence there is need to just map single file.

Possible ways to do this

1. File using subPath from ConfigMap. But Voulmes don't support Config map currently.
   https://stackoverflow.com/questions/44325048/kubernetes-configmap-only-one-file

2. Init Script that can run before Pod Start.

• Here i can mount my files /etc/tiny/tinyproxy.conf.
• Init Script can then copy /etc/tiny/tinyproxy.conf to /etc/tinyproxy.conf before starting Container.

We should add more ifs in the template to not generate nil fields like volumes: bellow.

      containers:
        - name: fosdem-2021
          securityContext:
            {}
          image: "xxx"
          imagePullPolicy: 
          envFrom:
          ports:
            - name: http
              containerPort: 80
              protocol: TCP
          volumeMounts:
          resources:
            limits:
              cpu: 200m
              memory: 200Mi
            requests:
              cpu: 200m
              memory: 200Mi
      volumes:

Hey thanks for your aweseome work!

How about integrating cert-manager into the mix?

DNS-1035 label must consist of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character

Hello,

I have not found an obvious way to add a startupProbe to a deployment, maybe it's something that needs to be added ?

For wildcard deployments we already have a tls-secret and would like to reuse it for multiple deployments. Therefore it would be helpful to have an option like ingress.tls.secretName.

PS: pretty cool approach. I had a short test on creating a cli tool to deploy a local project by building the image, automatically pushing it to some configured registry and deploying it using onechart.

Perhaps by merging onechart/cron-job into onechart/onechart.

Follow the Helm best practice

In most cases, flat should be favored over nested. The reason for this is that it is simpler for template developers and users.

The task is to change

secret:
  enabled: true

to

secretEnabled: true

And enable the secret name to be configurable with the secretName field.

• Flatten secret field
• Add support for secretName, with {{ template "robustName" .Release.Name }}
• Document the changes

Experiment with the approach the NATS chart has.

Instead of supporting every option of the Kubernetes yaml, they offer these two fields in the values file. Essentially these are like Kustomize's overlays.

https://github.com/nats-io/k8s/tree/main/helm/charts/nats#patch
https://github.com/nats-io/k8s/tree/main/helm/charts/nats#merge

Adding for example hostNetwork to OneChart would look like:

container:
  merge:
    hostNetwork: true

https://external-secrets.io/v0.4.4/api-externalsecret/

Ability to reference secrets in external SecretStores.

There are many new features since we updated the chart schema.

The task is to include all features in the scheam.

The best practice has evolved since Onechart was created. Limits are considered harmful in many situations(citation needed).

https://helm.sh/docs/topics/registries/

The task is to modify Onechart's build and CI jobs to publish to an OCI registry. We would like to use the Github Package registry to host onechart.

Since you don't have access to our registry, publish it under your Github account and let us know what we need to replace when we merge.

Please provide a two liner on how to use it: helm repo add, helm repo install.