bedag / helm-charts Goto Github PK

Describe the bug
Values.secrets.data.registry.pullSecret expects a string-value, which is not used throughout the chart.

Version of Helm and Kubernetes:

Helm Version: v3.12.0
Kubernetes Version: 1.27

Which chart:

[bedag/common]

What happened:
If no value is given for the pullSecret key, there is no pull secret to be used. If any value is given (i.e. foo or 123), the secret is expected to be called {{ template "library.name" $root }}-registry-pull-secret (defined in the template _pod.yaml).

What you expected to happen:
If the chart expects me to supply a value of type string, I would expect the chart to digest that provided value in some way. If I'm supposed to provide a string, the chart should look for a secret which matches that string (maybe with a pre- or suffix, but nonetheless). Otherwise it should be replaced with a boolean, because that's how this key currently behaves.

How to reproduce it (as minimally and precisely as possible):
Supply any name for a pullSecret and see that the provided value does not influence the name of the expected secret.

Anything else we need to know:
-

Describe the bug
When documentation is provided for a key which happens to be the first object of a dictionary entry, helm-doc will document the object as parentItem[0]. Example from the common Chart:

# -- ingress is used for access from outside of kubernetes
ingress:
  # -- rules is a list of host rules used to configure the Ingress
  rules:
    # -- host is the URL which ingress is listening
    - host: myapp.cluster.local

... will result in the following documentation:

Version of Helm and Kubernetes:

Helm Version: v3.12.0
Kubernetes Version: 1.27

Which chart:

[bedag/common]

What happened:

While working on the common chart, I noticed that certain keys in the documentation don't get properly displayed, because their position is also the start of a dictionary entry.

What you expected to happen:

I would expect the keys to be documented by their proper name.

How to reproduce it (as minimally and precisely as possible):

1. go to the values.yaml in the bedag/common chart
2. see the ingress section, specifically the $ingress.rules.host key
3. look up the key documentation in the README.md under ingress.rules[0]
4. to verify the behaviour, run another make helm-doc

Anything else we need to know:

No

Describe the bug
e2g has only a basic tcp probe. Adding proper health-check like this: OPTIONS icap://127.0.0.1:1344/request ICAP/1.0

Version of Helm and Kubernetes:

Helm Version: **Kubernetes Version**:

Which chart:

[bedag/e2g ]

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

Describe the bug
When defining a name in the bundle.yaml for statefulsets or deployments, and when adding secret env vars in these statefulsets or deployments, the given name is not being used in the secretKeyRef which leads to an error.

Version of Helm and Kubernetes:

Helm Version: v3.4.2
Kubernetes Version: 1.19.6

Which chart:

[bedag/manifests]

What happened:
Wrong secret name in secretKeyRef of the pods spec.containers.env

What you expected to happen:
correct secret name to be used in secretKeyRef

How to reproduce it (as minimally and precisely as possible):
lets say in the bundle we have something like

  - type: "statefulset"
    values: {{ toYaml $.Values.myapp.statefulset | nindent 6 }}
    name: myapp

in the values we have:

myapp:
  statefulset:
    environment:
      - name: MY_SECRET
        value: "donttell"
        secret: true

Then we deploy this in a release called "bla", this leads to a CreateContainerConfigError status of the pod, because in the pods spec.containers.env theres is the wrong secret name being used:

    - name: MY_SECRET
      valueFrom:
        secretKeyRef:
          key: MY_SECRET
          name: bla-fullname-env

Instead of the fullname, the name given in the bundle should be used (if one is set)

Describe the bug
The raw chart described here says the buttatoast repo is a dependency, but raw is not managed by buttatoast.

Version of Helm and Kubernetes:
n.a.

Which chart:
raw

What happened:
helm search repo kubernetli (helm search repo buttahtoast is pretty much the same)
NAME CHART VERSION APP VERSION DESCRIPTION
kubernetli/csgo 0.2.1 1.0.0 Source Server
kubernetli/library 2.0.0 0.1.0 Buttahtoast Helm Library
kubernetli/tavern 0.3.1 1.1.0 Unofficial Tavern Helm Chart

What you expected to happen:
raw to be listed

Anything else we need to know:
not sure if I'm missing something. Also buttahtoast vs kubernetli is confusing.

Is your feature request related to a problem? Please describe.
Currently its not possible to add multiple filtergroup config.

Describe the solution you'd like
Adding Array like story and so for filtergroup. Use a key id in array to identify filtergroup

Describe alternatives you've considered
Mount it as addinalMount.

When more than one service is defined via the manifests library, all services forward to all the pods of any present deployment, replicaset or statefulset. Since this is almost never desired nor advisable, additional selector labels need to be defined.

The manifests library allows to define and name multiple bundles. It would be nice if services and components defined within such a bundle would feature the bundle.name as a default selector for any component(s) defined in such a bundle, further expanding on the usefulness of grouping functional units into their respective bundles.

Is your feature request related to a problem? Please describe.
No.

Describe the solution you'd like
In the current state, the pullSecret can be turned on or off as a boolean . The name consists of the library.name variable and the suffix -registry-pull-secret, as described in the default values.yaml.

It's desirable in some use cases that the name of the secret can be set as a string.

Describe alternatives you've considered
If it's in one's power, they might change the naming concept of the K8s objects according to the common Chart. Alternatively, you might swallow the pill and rename/workaround the automatically generated secret with whatever mechanisms suit you best.

Additional context
-

Describe the bug
When at least one entry is made under initContainers when rendering a statefulSet from template, the initContainer is rendered as expected in the resulting helm release but is also doubled under the container section. I crated a couple of files to describe the issue. The files were all in yaml originaly but had to be stored with a .txt file extension because of a Github restriction.

Version of Helm and Kubernetes:

Helm Version:
version.BuildInfo{Version:"v3.10.1", GitCommit:"9f88ccb6aee40b9a0535fcc7efea6055e1ef72c9", GitTreeState:"clean", GoVersion:"go1.18.7"} **Kubernetes Version**:
Client Version: v1.28.3 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3 Server Version: v1.23.6

Which chart:
[bedag/helm-charts/charts/common]

What happened:
I rendered a template using this minimal values file example-values.txt.
Pleace notice that init-container-1 exists twice in the resulting helm release resulting-helm-release.txt.

What you expected to happen:
I expected a helm release as an output, as I described in expected-helm-release.txt.
init-container-1 should exist in the initContainer section but not in the container section.

How to reproduce it (as minimally and precisely as possible):

• Clone this repository
• Change working dir to helm-charts/charts/common
• Store a copy of example-values.txt to the working dir
• render the template using the following command
  helm template . -f example-values.txt
• You can optionally pipe the result to a file

Anything else we need to know:
The version of the chart is 10.10.1

Describe the bug

When rendering any chart using the manifests library with Helm 3.5 you might encounter . Current workaround is to use a helm version below 3.5.0.

Therefor it's a breaking change and manifests is currently not supported with Helm 3.5

Version of Helm and Kubernetes:

Helm Version: ``

version.BuildInfo{Version:"v3.5.0", GitCommit:"32c22239423b3b4ba6706d450bd044baffdcf9e6", GitTreeState:"clean", GoVersion:"go1.15.6"}

Kubernetes Version: ``
Not relevant.

Which chart:

[manifests] (All charts using the it as dependency)

What happened:
With the new Helm client version a new sprig version was used. We are suspecting this issue originating from this. Otherwise it could be any bug that wasn't handled properly before.

Is your feature request related to a problem? Please describe.
We see a lot of use cases where Pod Security Policies are used. Therefor we would like it as manifest to the manifests charts. So that it better integrates with Charts already using the manifests chart.

Describe the solution you'd like
Add new resource PSP + documentation and examples.

Describe alternatives you've considered
No alternatives.

Additional context
None

Is your feature request related to a problem? Please describe.
To ensue we provide our users with a solid solution, we need to implement a dedicated chart, which allows us to do helm unit tests when building new releases of the manifests chart. Since the manifests chart has a rather high complexity, it might be possible that there might be bugs etc.

Describe the solution you'd like
Adds a new chart which is called manifests-testing which adds Helm Unit Tests (compatible to the Release Action used in this Repository). Chart Tests all the basic functionalities (functions/manifest outputs) to ensue everything works as intended.

Describe alternatives you've considered
Since manifests is of type library it's not directly possible to have the unit tests directly in the chart itself. Therefor we need a dedicated chart.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
DaemonSets will be used in future chart use cases. Therefor we are already adding it. Since the Manifests chart supports a podtemplate and a daemonset mainly consists of a Pod Spec this new feature does not require a lot development.

Describe the solution you'd like
Add new resource DaemonSet + documentation and examples.

Describe alternatives you've considered
No alternatives.

Additional context
None

Purpose
We need to implement another Template for Housekeeping Issues. Housekeeping Issues are there for the Project functionality and aren't linked to any chart. They could be referencing new Github Actions or whatever. In Addition we should expand the documentation with some more Helm 3 practices.