fix(chart): allow scaling etcd via replicaCount and Helm upgrade

[michaelbeaumont]

Description

The etcd chart dynamically sets this value based on whether Helm is installing or upgrading. We shouldn't pin it to "new"

Motivation and Context

See openebs/mayastor#1732 and fixes openebs/mayastor#1659

It's supposed to be possible to scale etcd via the replica count with Helm.

How Has This Been Tested?

Tested via setting both initialClusterState to "existing" and changing replicaCount.

We then see on etcd-1 something like:

etcd 15:04:14.85
etcd 15:04:14.85 Welcome to the Bitnami etcd container
etcd 15:04:14.85 Subscribe to project updates by watching https://github.com/bitnami/containers
etcd 15:04:14.85 Submit issues and feature requests at https://github.com/bitnami/containers/issues
etcd 15:04:14.85
etcd 15:04:14.85 INFO  ==> ** Starting etcd setup **
etcd 15:04:14.86 INFO  ==> Validating settings in ETCD_* env vars..
etcd 15:04:14.86 WARN  ==> You set the environment variable ALLOW_NONE_AUTHENTICATION=yes. For safety reasons, do not use this flag in a production environment.
etcd 15:04:14.87 INFO  ==> Initializing etcd
etcd 15:04:14.87 INFO  ==> Generating etcd config file using env variables
etcd 15:04:14.88 INFO  ==> There is no data from previous deployments
etcd 15:04:14.88 INFO  ==> Adding new member to existing cluster
etcd 15:04:14.98 INFO  ==> Loading env vars of existing cluster
etcd 15:04:14.99 INFO  ==> Obtaining cluster member ID
etcd 15:04:14.99 INFO  ==> Starting etcd in background
etcd 15:04:28.10 INFO  ==> Stored member ID: 2c17af324709f873
etcd 15:04:28.10 INFO  ==> Stopping etcd

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added unit tests to cover my changes.

[tiagolobocastro]

Ah yes seems they have modified it to the affect, great!
@datacore-tilangovan please take a look

[tiagolobocastro]

@michaelbeaumont seems we should probably add in the release notes users should modify this variable to existing?

[tiagolobocastro]

ping @datacore-tilangovan

[michaelbeaumont]

seems we should probably add in the release notes users should modify this variable to existing?

Honestly not 100% on how exactly Helm will merge values in this case... will it be reset back to empty on upgrade if we remove it in the upstream chart? If not then yes, users should set it to existing

[tiagolobocastro]

seems we should probably add in the release notes users should modify this variable to existing?

Honestly not 100% on how exactly Helm will merge values in this case... will it be reset back to empty on upgrade if we remove it in the upstream chart? If not then yes, users should set it to existing

I tried upgrading with --reset-then-reuse-values and it works, the value is now "existing" :)

I do face an issue where when deleting etcd-0 pod it goes into crashloop:

etcd 21:29:41.61 INFO  ==> Updating member in existing cluster
{"level":"warn","ts":"2024-09-10T21:29:41.649Z","logger":"etcd-client","caller":"[email protected]/retry_interceptor.go:62","msg":"retrying of unary invoker failed","target":"etcd-endpoints://0xc0001d4000/mayastor-etcd-0.mayastor-etcd-headless.mayastor.svc.cluster.local:2379","attempt":0,"error":"rpc error: code = NotFound desc = etcdserver: member not found"}
Error: etcdserver: member not found

But I was able to reproduce even with "new", so I think this is non-related. @datacore-tilangovan any clues here?

[tiagolobocastro]

bors merge

[bors-openebs-mayastor]

Build succeeded:

• continuous-integration/jenkins/branch