search

k8ssandra / management-api-for-apache-cassandra

RESTful / Secure Management Sidecar for Apache Cassandra
Apache License 2.0
70 stars 51 forks source link

Improve version management #432

Open emerkle826 opened 8 months ago

emerkle826 commented 8 months ago

Issue:

The Management API version of releases has been controlled by an automated process that triggers on a tag being pushed. The release process publishes artifacts to Cloudsmith.io where the Maven version is overridden on the command line used to publish the artifacts. It is never actually set in the Maven pom.xml files to anything other than 0.1.0-SNAPSHOT. In addition to publishing artifacts in Cloudsmith.io, the jarfiles are also zipped up and attached to a GitHub release. However, the zip bundle contains the jarfiles with a version that is still 0.1.0-SNAPSHOT, making it very difficult to determine which version of the artifact you are using.

Definition of Done

Miles-Garnsey commented 8 months ago

Does the current state also run risks of breaking user clusters because they aren't in control of updates when we do a release? (I think there was a counter-argument to this, can we document it?)

emerkle826 commented 8 months ago

Does the current state also run risks of breaking user clusters because they aren't in control of updates when we do a release?

I'm not sure about breaking things, though I guess it could be possible. In the context of cass-operator and k8ssandra, it's the Docker image tag that is going to control this somewhat. In those contexts, the serverVersion value is usually set to something like 4.0.6. That translates to an image with a tag of 4.0.6, which is currently updated to point to the latest Management API version for Cassandras version 4.0.6. So if some non-backward compatible thing makes it into Management API, then a new release could potentially break things.

However, I also believe the default image pull policy is something like IfNotPresent, so the image probably won't update without some kind of manual intervention, which is potentially a different problem (i.e. users not getting bug fixes that are put into Management API).

We generally guard against non-backward compatible changes, so there is less risk of taking a new version of Management API for a given version of Cassandra/DSE. I think the second issue of not pulling a new image because you already have one is more concerning.

In either case though, a user can override the image coordinates and get more specific (i.e. use a tag suffix of 4.0.6-v0.1.71 for a specific Management API version). And the current state of versioning artifacts isn't affected by this.

The short answer to this is that the current state isn't really at risk of breaking anything on upgrades. This ticket mainly to address the problem of this project's artifacts not being properly versioned on their own (artifacts being jarfiles, not Docker images).

Miles-Garnsey commented 8 months ago

However, I also believe the default image pull policy is something like IfNotPresent, so the image probably won't update without some kind of manual intervention, which is potentially a different problem (i.e. users not getting bug fixes that are put into Management API).

Right, lack of upgrades is an issue, but so is the fact that we sometimes push a bug. That isn't ideal, and it would be nice to have fixed versions by default. Also IfNotPresent doesn't really protect you if the pod is rescheduled on a new node (which is very possibly if scaling).

In either case though, a user can override the image coordinates and get more specific (i.e. use a tag suffix of 4.0.6-v0.1.71 for a specific Management API version). And the current state of versioning artifacts isn't affected by this.

There is an argument that best practice is to fix image versions then I guess. Maybe that's advice that we should be providing to users.

Maybe this is a separate ticket on k8ssandra-operator though to enforce fixed versions per release.

emerkle826 commented 8 months ago

Maybe this is a separate ticket on k8ssandra-operator though to enforce fixed versions per release.

I think we have talked about this in the past, but maybe let's bring it up at the next all-hands or planning meeting.