Introduce latest tag: How to upgrade the upgrader?

[jhoelzel]

How can i automatically upgrade the upgrader?

Currently there is no easy way for me to get the current version of the upgrader, except using a shell script. Henceforth no matter what i do, the upgrader will have to be upgraded manually.

The quick fix would be to introduce a latest tag, which in turn would enable other software, like argocd, to simply apply the latest version of it on it's introduction.

What do you think and how do you upgrade the upgrader?

[brandond]

Use of the latest tag is somewhat of an anti-pattern, but we could evaluate publishing it.

A better option might be to use something like keel to update the tag automatically:
https://keel.sh/

[brandond]

You know that GH has that built in right?
https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases#linking-to-the-latest-release

https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml

[jhoelzel]

this redirect does not work on strict systems that dont allow 301. Or simply said, curl https://github.com/rancher/system-upgrade-controller/releases/latest/download/system-upgrade-controller.yaml is blank because of it.

However i did find a solution nonetheless, you guys are already provding the kustomization yaml in / which does exactly that
https://github.com/rancher/system-upgrade-controller/blob/master/kustomization.yaml

however it has been last updated: 2 years ago

[brandond]

We're not going to maintain our own latest tag; GH has that functionality built in and there is tooling available that will work with it. The kustomization is used as part of the release process to build the manifests that are published as artifacts and uses the tag being published; we don't regularly update it in-place.

[jhoelzel]

hm would you change your mind if i provide you with a github workflow that automatically will tag your latest release for you?

as for the kustomize file, its an interesting choice, since it seems to be the documented way to install the operator, right here in the readme:

https://github.com/rancher/system-upgrade-controller#deploying

this could also simply be updated with a workflow.

Furthermore I am interested in the " tooling available that will work with it.", could you please point me in the right direction ?
My goal is it to have a self updating upgrade operator deployed to the cluster. Basically to have the upgrade upgrade itself.

[brandond]

No, having mutable release tags (that mirror the latest pattern used by docker image tags) is not a pattern that I have ever seen any other project observe, nor is it one we want to embrace.

[jhoelzel]

While i understand the stance and i will simply use the manifests provided in the master branch of this repository and let argo catch any rollout errors, here are some projects that do just that:

ArgoCD:
https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Percona Operator for Postgres:
https://raw.githubusercontent.com/percona/percona-postgresql-operator/main/deploy/bundle.yaml

External-DNS
https://github.com/kubernetes-sigs/external-dns/tree/master/kustomize

useable kustomization;

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - https://raw.githubusercontent.com/rancher/system-upgrade-controller/master/manifests/system-upgrade-controller.yaml