Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for user-defined per-keyspace images #524

Merged
merged 3 commits into from
Jan 24, 2024

Conversation

maxenglander
Copy link
Contributor

@maxenglander maxenglander commented Jan 23, 2024

Description

Currently the way to upgrade from mysql 57 to 80 in the operator is to change mysqld image version. This causes operator to do a rolling upgrade of tablets. There's a lot that could go wrong here, and it would be nice if there were an option to do a controlled migration from 57 to 80.

One way this could work in theory is to create a new keyspace configured with mysql 80, and do a MoveTables from the 57 keyspace to the 80. This would allow carefully testing and validating that the upgrade succeeded before doing SwitchTraffic, and in theory would allow switching back to 57 if issues were discovered in 80 after SwitchTraffic.

This PR allows the user to specify per-keyspace images, relaxing this prohibition:

vitess-operator/docs/api.md

Lines 5280 to 5283 in 5bf4279

<p>Images are not customizable by users at the keyspace level because version
skew across the cluster is discouraged except during rolling updates,
in which case this field is automatically managed by the VitessCluster
controller that owns this VitessKeyspace.</p>

Issues

Fixes: #446

Validation

I validated the change by deploying a local build to a local kind cluster, and deploying a VitessCluster with one keyspace inheriting images from the cluster spec, and the other using user-defined overrides.

kind.yaml

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: planetscale-vitess-operator-dev
networking:
  ipFamily: ipv4  # macos only supported v4
nodes:
- role: control-plane
  image: kindest/node:v1.24.15@sha256:7db4f8bea3e14b82d12e044e25e34bd53754b7f2b0e9d56df21774e6f66a70ab
  labels:
    role: master

vitesscluster.yaml

apiVersion: planetscale.com/v2
kind: VitessCluster
metadata:
  name: dev-vitess-cluster
spec:
  images:
    vtadmin: vitess/lite:mysql57
    vtbackup: vitess/lite:mysql57
    vtctld: vitess/lite:mysql57
    vtgate: vitess/lite:mysql57
    vtorc: vitess/lite:mysql57
    vttablet: vitess/lite:mysql57
    mysqld:
      mysql56Compatible: vitess/lite:mysql57
  cells:
  - name: localhost
    gateway:
      authentication:
        static:
          secret:
            name: dev-vitess-cluster-config
            key: users.json
      secureTransport:
        tls:
          certSecret:
            name: dev-vitess-cluster-config
            key: cert.pem
          keySecret:
            name: dev-vitess-cluster-config
            key: key.pem
  keyspaces:
  - name: mysql57
    partitionings:
    - equal:
        parts: 1
        shardTemplate:
          databaseInitScriptSecret:
            name: dev-vitess-cluster-config
            key: init_db.sql
          tabletPools:
          - cell: localhost
            type: replica
            replicas: 1
            vttablet:
              resources:
                requests:
                  cpu: 100m
                  memory: 512Mi
            mysqld:
              resources:
                requests:
                  cpu: 100m
                  memory: 2048Mi
            dataVolumeClaimTemplate:
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 10Gi
  - name: mysql80
    images:
      vtbackup: vitess/lite:mysql80
      vtorc: vitess/lite:mysql80
      vttablet: vitess/lite:mysql80
      mysqld:
        mysql80Compatible: vitess/lite:mysql80
    partitionings:
    - equal:
        parts: 1
        shardTemplate:
          databaseInitScriptSecret:
            name: dev-vitess-cluster-config
            key: init_db.sql
          tabletPools:
          - cell: localhost
            type: replica
            replicas: 1
            vttablet:
              resources:
                requests:
                  cpu: 100m
                  memory: 512Mi
            mysqld:
              resources:
                requests:
                  cpu: 100m
                  memory: 2048Mi
            dataVolumeClaimTemplate:
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 10Gi
  updateStrategy:
    type: Immediate

Results

$ kubectl get deploy vitess-operator -o yaml | grep image:
        image: planetscale/vitess-operator:5030d17
$ kubectl get vitesskeyspace dev-vitess-cluster-mysql57-d246bb11 -o yaml | grep mysql56
      mysql56Compatible: vitess/lite:mysql57
$ kubectl get vitesskeyspace dev-vitess-cluster-mysql80-b833e5b7 -o yaml | grep mysql80Compat
      mysql80Compatible: vitess/lite:mysql80

Signed-off-by: Max Englander <[email protected]>
@maxenglander maxenglander marked this pull request as ready for review January 23, 2024 13:40
@frouioui
Copy link
Member

This is a good enhancement, thank you @maxenglander !

Copy link
Collaborator

@mattlord mattlord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like it! Makes sense to me. I only had some minor comments.

Comment on lines 1179 to 1182
mariadb103Compatible:
type: string
mariadbCompatible:
type: string
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we can remove these from all of the CRDs on main now, but for now I think we can NOT propagate them here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, done

Comment on lines 5560 to 5566
<p>Images are not customizable by users at the keyspace level because version
skew across the cluster is discouraged except during rolling updates,
in which case this field is automatically managed by the VitessCluster
controller that owns this VitessKeyspace.</p>
<p>Images are inherited from the VitessCluster spec, unless the user has
specified keyspace-level overrides. Version skew across the cluster is
discouraged except during rolling updates, in which case this field is
automatically managed by the VitessCluster controller that owns this
VitessKeyspace.</p>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the version here was more about Vitess than MySQL. I think that we're now focusing on MySQL version rather than Vitess version, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah! Yes indeed, just focusing on MySQL.

Hm..with that observation in mind, do you think it would make sense to scope this PR to only allow MySQL image overrides?

Copy link
Contributor Author

@maxenglander maxenglander Jan 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went ahead an removed support for user-definable per-keyspace images for vttablet, vtorc, myqsld exporter along w/ removing support for setting mariadb images.

@frouioui frouioui merged commit a41848c into main Jan 24, 2024
9 checks passed
@frouioui frouioui deleted the maxeng-per-keyspace-images branch January 24, 2024 20:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature request: support controlled mysqld version upgrade with rollback
3 participants