deliowales/helm-charts-public

Charts

Go

Node

PHP

❗NOTE: The chart versions above may not necessarily be released yet. You can confirm the latest release version by running

helm search repo delio/{chart name}

helm-charts-public's Issues

[FEATURE]: Bump autoscaling/v2beta2 to autoscaling/v2 for K8S versions >1.23

Is there an existing feature request raised for this?

• I have searched the existing feature requests

What limitations is this causing?

autoscaling/v2beta2 is deprecated for kubernetes >1.23.

Desired behaviour

Deploy hpa without a deprecated version

Describe any possible solutions you've considered.

We need to upgrade this to autoscaling/v2.

Additional context.

No response

[BUG]: no matches for kind "KongIngress"

Is there an existing issue raised for this?

• I have searched the existing issues

Chart version?

v0.0.16

Current behaviour

When running a helm install, it fails to install giving the following error

Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: resource mapping not found for name: "do-not-preserve-host" namespace: "" from "": no matches for kind "KongIngress" in version "configuration.konghq.com/v1"
ensure CRDs are installed first

Expected behaviour

I would expect the install to run and complete without failing

Steps to reproduce

running helm install notification . -f demo-west-values.yaml -n notification --dry-run

Anything else we need to know?

No response

[BUG]: Node apps must be on port 3000

Is there an existing issue raised for this?

• I have searched the existing issues

Chart version?

node-0.1.0

Current behaviour

A node application deploys with the deployment listening on port 3000 but I have an app thats configured to listen on port 4000

Expected behaviour

To be able to over-ride the default container port of 3000

Steps to reproduce

deploy an app using the node 0.1.0 chart and provide a containerPort that is different to 3000, due to

helm-charts-public/charts/node/templates/deployment.yaml

Line 54 in a98e5c2

containerPort: 3000

this is ignored

Anything else we need to know?

No response

[BUG]: incompatible types for comparison - kong.stripPath

Is there an existing issue raised for this?

• I have searched the existing issues

Chart version?

v0.0.15

Current behaviour

When running helm template for service-quicksight in the UAT environment, I am getting the following error message:

Error: template: service-quicksight/charts/microservice/templates/service.yaml:14:11: executing "service-quicksight/charts/microservice/templates/service.yaml" at <eq .Values.service.kong.stripPath "true">: error calling eq: incompatible types for comparison

This is blocking deploying new helm changes for service-quicksight

Expected behaviour

Upgrade successfully

Steps to reproduce

helm template test . -f uat-values.yaml --debug

Anything else we need to know?

This seems to only be affecting service-quicksight at the moment.

[BUG]: Error "An image tag needs to be defined" when trying to deploy to a Demo environment

Is there an existing issue raised for this?

• I have searched the existing issues

Chart version?

v0.0.15

Current behaviour

I've created a values file to deploy a PHP and a Node environment based on a Values template thats been successfully used in the UAT environment. As its not a test environment I've specified the image version in my values file using

application:
   image:
      repository: myapp
      tag: "v1.4.4"

(I've tried the tag with & without speech marks with the same result)
However when I run helm install myapp . --values ./env-myapp.yaml -n myapp --dry-run I get the error

Error: execution error at (tenancy/charts/microservice/templates/deployment-php.yaml:40:20): An image tag needs to be defined.

This also happened for the deployment-node.yaml file.

In the helper.tpl file the error seems to be generated by the line

{{- define "microservice.project.imageURL" -}}
  {{- printf "%s/%s:%s" (include "microservice.cloud.containerRegistryURL" .) .Values.application.image.repository (include "microservice.application.image.tag" . | required "An image tag needs to be defined.") }}
{{- end -}}

But I've double checked and these three values are defined.

Expected behaviour

The chart successfully rollouts using the microservice.application.image.tag value that I have defined

Steps to reproduce

The two key code blocks in the Values.yaml file are:

microservice:
  application:
    image:
      repository: deals
      tag: "1.4.1"

and

  cloud:
    provider: AWS
    environment: "demo"

Anything else we need to know?

This is affecting both PHP and Node based services

[FEATURE]: Ability to have migrations run before pods are deployed

Is there an existing feature request raised for this?

• I have searched the existing feature requests

What limitations is this causing?

Currently, all pods run migrations on boot. Each pods runs migrations by connecting to each schema. For example, we have around 400 schemas for demo, so if there are three pods spinning up thats 1200 connections to the RDS instance. This is obviously bad practice and will undoubtedly cause issues.

Desired behaviour

This needs to be moved into a single job as a pre-requisite before helm deployment and only deploy is migrations are completed successfully.

Describe any possible solutions you've considered.

A helm pre-install hook that is required to run and be successful before the deployment is scheduled.

Additional context.

Helm hooks: https://helm.sh/docs/topics/charts_hooks/
Kubernetes Job: https://kubernetes.io/docs/concepts/workloads/controllers/job/

[DOC]: Documentation around the helm tests

Documentation improvement or addition?

Addition

What would you like documented?

We would like to have some documentation around how the helm tests are done.

Additional context.

No response