search

neondatabase / autoscaling

Postgres vertical autoscaling in k8s
Apache License 2.0
150 stars 20 forks source link

Internal feature: refined compatibility matrix #888

Open Omrigan opened 5 months ago

Omrigan commented 5 months ago

Problem description / Motivation

The compatibility between different versions of different components is currently defined in https://github.com/neondatabase/autoscaling/blob/main/pkg/api/VERSIONING.md

We have a number of problems with it:

  1. Hard to grasp the implication of two version existing in a cluster (see https://github.com/neondatabase/autoscaling/pull/836#discussion_r1511150909)
  2. It is easy to forget to update it

  3. 580 and #761 needs this info to work

  4. Particular code changes might impact the exact release procedure (e.g. changing order, can't rollback one thing without the other, etc), and we want to make the life of a person doing the release as easy as possible
  5. If there are changes to the compute image, there is no way to check we don't have old computes in the cluster

Feature idea(s) / DoD

All the mentioned problems are solved

Implementation ideas

  1. Use the release version as a protocol version, and define compatibility with versions (scheduler==v0.27.0 is compatible with v0.25.0 <= autoscaler-agent >= v0.28.0
  2. Write code in a backward-compatible way, meaning that componentA==v0.(x) always works with v0.(x-1)<=componentB<=v0.(x). We must analyze whether is there a practical rule of such class, so that custom deploy procedures are never needed.