support schema upgrade (#18)

Why

Existing schema-job only runs once. It means that version upgrade won't work if there is a schema change. To support it, we can put version name into the schema-job so k8s cluster would create a new job that upgrades the schema.

Changes

add version into schema job name.

Test

Tested in GCP

Author: shijiesheng

charts/cadence/Chart.yaml

@@ -15,7 +15,7 @@ type: application
 # This is the chart version. This version number should be incremented each time you make changes
 # to the chart and its templates, including the app version.
 # Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 0.1.1
+version: 0.1.2
 
 # This is the version number of the application being deployed. This version number should be
 # incremented each time you make changes to the application. Versions are not expected to

charts/cadence/templates/schema-job.yaml

@@ -1,7 +1,7 @@
 apiVersion: batch/v1
 kind: Job
 metadata:
-  name: cadence-schema-setup
+  name: cadence-schema-setup-v{{ .Values.cassandra.schema.version | replace "." "-" }}
   labels:
     {{- include "cadence.commonlabels" . | nindent 4 }}
 spec:

charts/cadence/values.yaml

@@ -8,9 +8,9 @@ cassandra:
   endpoint: ""
   schema:
     # -- Cassandra schema version of the Cadence keyspace to use. Latest value can be found at https://github.com/uber/cadence/blob/master/schema/cassandra/version.go
-    version: 0.40
+    version: "0.40"
     # -- Cassandra schema version of the Cadence visibility keyspace to use. Latest value can be found at https://github.com/uber/cadence/blob/master/schema/cassandra/version.go
-    visibility_version: 0.9
+    visibility_version: "0.9"
   deployment:
     # -- When enabled, a single instance Cassandra will be deployed as part of the Helm chart
     # -- When disabled, the Cassandra deployment is expected to be provided externally. For production use cases, it is recommended to use an external Cassandra deployment.