risingwavelabs / helm-charts Goto Github PK

View Code? Open in Web Editor NEW

11.0 5.0 6.0 1.18 MB

Helm Charts for RisingWave

Home Page: https://risingwave.com

License: Apache License 2.0

Smarty 67.25% Shell 27.37% Makefile 5.38%

charts helm kubernetes risingwave risingwave-operator helm-charts

helm-charts's Issues

bug: appversion unconsistency with rw version

Report by some user, the actual rw version is not consistency with app version

Step by step instruction to install operator with helm

Add support for risingwave 1.5

RisingWave v1.5.0 should be supported: https://github.com/risingwavelabs/risingwave/releases/tag/v1.5.0

bug: The State Store use Tencent's COS error

Describe the bug

Use Tencent's COS, but meta, compute, compator node throw exception:

Error message/log

How did you deploy RisingWave?

master helm

The version of RisingWave

No response

Additional context

No response

Support OBS as a state store backend

Reference: risingwavelabs/risingwave#13844

Secrets for passing Etcd credentials

There is an option to pass S3 credentials either directly or use an existing secret, however there is no such option to pass Etcd Credentials with a secret.

metaStore:
  etcd:
    endpoints:
    - <IP>:2379

    authentication:
      enabled: true
      username: username
      password: password

stateStore:
  minio:
    enabled: false

  s3:
    enabled: true
    region: ap-southeast-1
    bucket: risingwave
    authentication:
      useServiceAccount: false
      existingSecretName: s3-secret

Network slowness on aliyun when pulling container images

The pod is pulling container image abnormally because there are other pods pulling it at the same time, which may block the current process. The pods's container images are [ghcr.io/risingwavelabs/risingwave:v1.3.0 ghcr.io/risingwavelabs/risingwave:v1.3.0 ghcr.io/risingwavelabs/risingwave:v1.3.0].

Pod my-risingwave-compactor-58d5c94d5b-jn99t 存在异常：拉取镜像超时

Value of `existingConfigMap` is ignored and static string `risingwave-configuration` is used instead to assign ConfigMap to PODs

Context

There is helm value existingConfigMap, that is annotated as

## @param existingConfigMap Name of existing ConfigMap containing RisingWave configuration.
## The ConfigMap must contain a key named `risingwave.toml`. If set, `configuration` will be ignored.
##

Expectation
I would therefore expect, that configmap, that is created (and whose name is then assigned to value of existingConfigMap ) would be used by RisingWave (and the .toml file included in CM will be used)

Observation

If existingConfigMap is not empty, then disregard of actual value, pod start to look for configmap with name risingwave-configuration

Workaround

Add custom .toml configuration into ConfigMap named risingwave-configuration

Investigation

In configmap.yaml, there is logic, that creates CM with name of risingwave.configurationConfigMapName in case .Values.existingConfigMap is not empty

{{- if empty .Values.existingConfigMap }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "risingwave.configurationConfigMapName" . }}
  labels:
      {{- include "risingwave.labels" . | nindent 4 }}
  {{- $annotations := (include "risingwave.annotations" . ) | trim }}
  {{- if $annotations }}
  annotations:
    {{ nindent 4 $annotations }}
  {{- end }}
data:
  risingwave.toml: |
    {{ .Values.configuration | nindent 4 }}
{{- end }}

In other files (e.g. compactor-deploy.yaml) only value of configurationConfigMapName is used (ignoring .Values.existingConfigMap)

serviceAccount annotations are rendered as labels

When configuring serviceAccount for state store on s3 on eks infrastructure, if serviceAccount.create is true a annotation is used to associate the serviceAccount in eks with aws IAM role for accessing the state store bucket.

However the current helm chart renders the annotations as a label. This makes the serviceAccount resource manifest generated by helm invalid.

For example a rendered manifest will look like:

# Source: risingwave/templates/serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: risingwave
  labels:
    helm.sh/chart: risingwave-0.1.21
    app.kubernetes.io/name: risingwave
    app.kubernetes.io/instance: risingwave
    app.kubernetes.io/version: "v1.2.0"
    app.kubernetes.io/managed-by: Helm
    eks.amazonaws.com/role-arn: arn:aws:iam::1234567890123:role/s3/some-role

notice the eks.amazonaws.com/role-arn key should be a annotation and not a label.

This happens because the template has the following content

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "risingwave.serviceAccountName" . }}
  labels:
    {{- include "risingwave.labels" . | nindent 4 }}
  {{- $annotations := (include "risingwave.annotations" . ) | trim }}
  {{- if $annotations }}
  annotations:
    {{ nindent 4 $annotations }}
  {{- end }}
  {{- with .Values.serviceAccount.annotations }}
    {{- toYaml . | nindent 4 }}
  {{- end }}
{{- end }}

The problem is that the .Values.serviceAccount.annotations is being rendered directly under the metadata.labels section instead of the metadata.annotations section due to how the templating has been written.

Instead the template should be:

{{- if .Values.serviceAccount.create -}}
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ include "risingwave.serviceAccountName" . }}
  labels:
    {{- include "risingwave.labels" . | nindent 4 }}
  {{- $annotations := (include "risingwave.annotations" . ) | trim }}
  annotations:
    {{- if $annotations }}
    {{- nindent 4 $annotations }}
    {{- end }}
    {{- with .Values.serviceAccount.annotations }}
    {{- toYaml . | nindent 4 }}
    {{- end }}
{{- end }}

this will then render as:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: risingwave
  labels:
    helm.sh/chart: risingwave-0.1.22
    app.kubernetes.io/name: risingwave
    app.kubernetes.io/instance: risingwave
    app.kubernetes.io/version: "v1.2.0"
    app.kubernetes.io/managed-by: Helm
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::1234567890123:role/s3/some-role

Connector resource limits are incorrectly applied.

A connector container is scheduled into the same pod as the compute component as specified in the risingwave-compute statefulset.

The helm chart declares values for configuring cpu/memory requests/limits.

However these values are not used by the helm chart.

There are several issues:

.values.metaComponent.resourceLimits.* are used in place of .values.connectorComponent here.
- This means connector component is configured with resource specified for meta component rather than connector. This problem is made worse because compute component is preempted by the connector when under resource contention!
In values.yaml a comment suggest connector should be scheduled into the same pod as both the meta and compute components. However the kubernetes manifests only schedule the connector container on the compute pod.

TODO:

Update resource requests and limits reference for connectorComponent
Either fix comment or schedule connector component on both compute and meta components

Support HPA settings for compute nodes

I wonder wether we can enable HPA feature for compute nodes. From the official docs, I could not find details about it.

install failed when setting harbor secrets

When using harbor secrets, it will failed with the following messages:

Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(Deployment.spec.template.spec.imagePullSecrets[0]): invalid type for io.k8s.api.core.v1.LocalObjectReference: got "string", expected "map"

Maybe there need add a name: prefix?

helm-charts/charts/risingwave/templates/frontend-deploy.yaml

Line 50 in 3cb638b

- {{ . }}