Should we support this `score-helm` implementation again?

[mathieu-benoit]

This issue is to track, document and discuss the interest of re-enabling and supporting again this score-helm implementation (deprecated in 2024).

Why?

• We are getting more and more asks about this.
• End users want to reuse their existing Helm charts. In this case, they don't want to rewrite their Helm charts with score-k8s's templates.
• The need seems to be to generate values file, not the Helm chart itself.
• As Platform Engineer, I want my Devs to author Score files, not Helm chart values.

What we need to do better from the past?

• The schema of the values file was opiniated and rigid (see example here), not very usable for the end users... that's why we deprecated it before giving Score to the CNCF.
• While this needs to have a default values.yaml schema, the key feature will be to let the end users bring their own values.yaml schema. We can reuse templating language like we have for score-compose and score-k8s in the patch templates features.

What needs to be done?

• Governance
  • Make score-helm compliant and consistent with official Score implementation template #33
  • Dockerfile and CI more secure #37
  • Enable OpenSSF's tools
• Features
  • Like other Score implementations, add the init and generate commands
    • Done in Make score-helm compliant and consistent with official Score implementation template #33
  • Remove the run command
    • Done in Make score-helm compliant and consistent with official Score implementation template #33
  • Default template should generate the default generic values.yaml like illustrated by the helm create command here
  • Set custom template during the init command to override the default template
  • This doesn't need any provisioners, the template will handle the iteration through the resources?
• Other examples to illustrate
  • https://github.com/GoogleCloudPlatform/microservices-demo/tree/main/helm-chart
  • https://github.com/stefanprodan/podinfo/tree/master/charts/podinfo
• Docs
  • First, add it as an experimental Score implementation
  • Later, when becoming more used and mature, let's add it back as an official Score implementation?

[mathieu-benoit]

As an example, given this Score file:

apiVersion: score.dev/v1b1
metadata:
  name: hello-world
containers:
  hello:
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo Hello World!; sleep 5; done"]

This command:

score-helm run -f examples/01-hello/score.yaml -o values.yaml

Will generate this values.yaml:

containers:
  hello:
    args:
      - -c
      - while true; do echo Hello World!; sleep 5; done
    command:
      - /bin/sh
    image:
      name: busybox

[mathieu-benoit]

As a reference, when we do helm create hello-world, here is what's generated:

hello-world/
├── Chart.yaml
├── charts
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── httproute.yaml
│   ├── ingress.yaml
│   ├── service.yaml
│   ├── serviceaccount.yaml
│   └── tests
│       └── test-connection.yaml
└── values.yaml

And here is the content of the values.yaml file:

# Default values for hello-world.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
# This will set the replicaset count more information can be found here: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
replicaCount: 1
# This sets the container image more information can be found here: https://kubernetes.io/docs/concepts/containers/images/
image:
  repository: nginx
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""
# This is for the secrets for pulling an image from a private repository more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
imagePullSecrets: []
# This is to override the chart name.
nameOverride: ""
fullnameOverride: ""
# This section builds out the service account more information can be found here: https://kubernetes.io/docs/concepts/security/service-accounts/
serviceAccount:
  # Specifies whether a service account should be created.
  create: true
  # Automatically mount a ServiceAccount's API credentials?
  automount: true
  # Annotations to add to the service account.
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template.
  name: ""
# This is for setting Kubernetes Annotations to a Pod.
# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
podAnnotations: {}
# This is for setting Kubernetes Labels to a Pod.
# For more information checkout: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
podLabels: {}
podSecurityContext: {}
  # fsGroup: 2000
securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000
# This is for setting up a service more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/
service:
  # This sets the service type more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
  type: ClusterIP
  # This sets the ports more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#field-spec-ports
  port: 80
# This block is for setting up the ingress for more information can be found here: https://kubernetes.io/docs/concepts/services-networking/ingress/
ingress:
  enabled: false
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths:
        - path: /
          pathType: ImplementationSpecific
  tls: []
    # - secretName: chart-example-tls
    #   hosts:
    #     - chart-example.local
# -- Expose the service via gateway-api HTTPRoute
# Requires Gateway API resources and suitable controller installed within the cluster
# (see: https://gateway-api.sigs.k8s.io/guides/)
httpRoute:
  # HTTPRoute enabled.
  enabled: false
  # HTTPRoute annotations.
  annotations: {}
  # Which Gateways this Route is attached to.
  parentRefs:
  - name: gateway
    sectionName: http
    # namespace: default
  # Hostnames matching HTTP header.
  hostnames:
  - chart-example.local
  # List of rules and filters applied.
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /headers
  #   filters:
  #   - type: RequestHeaderModifier
  #     requestHeaderModifier:
  #       set:
  #       - name: My-Overwrite-Header
  #         value: this-is-the-only-value
  #       remove:
  #       - User-Agent
  # - matches:
  #   - path:
  #       type: PathPrefix
  #       value: /echo
  #     headers:
  #     - name: version
  #       value: v2
resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi
# This is to setup the liveness and readiness probes more information can be found here: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /
    port: http
# This section is for setting up autoscaling more information can be found here: https://kubernetes.io/docs/concepts/workloads/autoscaling/
autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80
# Additional volumes on the output Deployment definition.
volumes: []
  # - name: foo
  #   secret:
  #     secretName: mysecret
  #     optional: false
# Additional volumeMounts on the output Deployment definition.
volumeMounts: []
  # - name: foo
  #   mountPath: "/etc/foo"
  #   readOnly: true
nodeSelector: {}
tolerations: []
affinity: {}

[chris-stephenson]

I think there are 2 important point:

• how provisioners play into this.
• make it clear that this is just an entry point for platform teams to drive GitOps type workflows - not necessarily reusing their existing helm charts.