fission/fission-charts

Repo for fission charts

fission-charts's Issues

extraCoreComponentPodConfig nesting error in deployment-template

templates/deployment.yaml contains the following block at line 697:

---
{{- if .Values.kafka.authentication.tls.enabled }}
...
{{- end }}
{{- if .Values.extraCoreComponentPodConfig }}
{{ toYaml .Values.extraCoreComponentPodConfig | indent 6 -}}
{{- end }}

which leads to the generation of a single extraCoreComponentPodConfig-block after rendering the template whenever it is defined. I'm quite sure the extraCoreComponentPodConfig-block should be inside the kafka.authentication.tls.enabled-block above.

---

For example if my values-file contains this:

extraCoreComponentPodConfig:
  tolerations:
  - key: faas
    operator: Exists
    effect: NoSchedule

the rendered template will contain this:

---
# Source: fission-all/templates/deployment.yaml
tolerations:
      - effect: NoSchedule
        key: faas
        operator: Exists
---

which obviously isn't a valid kubernetes-object.

Tested in fission-all-1.12.0

debugEnv flag support

debugEnv flag is not supported for an executor in the Fission core helm chart, but it is available in the Fission all helm chart (v1.14.1).

It should be available in all installations.

Fission Charts and Repository Enhancements

We would be closely following prometheus-community/helm-charts as a reference and taking Fission charts repo towards those standards.
 

Steps

1. Add detailed README in fission-charts Repo
2. Add README in each chart, it is required for Artifact Hub official releases. This is required to improve user exp and make our charts official on Artifact Hub.
3. Switch default branch to gh-pages from master in charts repo to serve charts Reference
4. Migrated Fission charts source from Fission repository to charts repository, ensure no failures
5. Reduction of common code between fission-all and fission-core helm charts and common templates.
6. Separate charts release and Fission images/app release. This would require further breakdown going ahead.
7. Use chart-releaser-action for releasing charts
8. Use chart-testing for testing of charts, add unit tests

Contributor Notes

• We should ensure there should be clear migration/usage steps mentioned for Fission users.
• All required documentation should be prepared alongside the code.
• We can treat this as a parent issue and link other issues as required.

unable to pass values into helm chart on install

➜ helm install --version v1.19.0 --namespace $FISSION_NAMESPACE fission fission-charts/fission-all --values fission-values.yaml 

Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: Namespace "fission" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "fission"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "fission"

fission-values.yaml:

defaultNamespace: fission
builderNamespace: fission
functionNamespace: fission
additionalFissionNamespaces:
  - prod

Can not specify resources for webhook deployment

Fission/Kubernetes version
Fission: 1.20.1
Kubernetes: 1.24.17

Kubernetes platform (e.g. Google Kubernetes Engine)
EKS

Describe the bug
According to values.yaml you can specify resource requests/limits for the fission webhook deployment. However this does not work in practice because the webhook-service deployment template does not fill these values in.

To Reproduce

Install chart with values.yaml with the resources under webhook: uncommented

Expected result
Webhook deployment should be deployed with resource requests and limits

Actual result
Webhook deployment does not have any resource configuration

Screenshots/Dump file

Additional context