rancher / system-upgrade-controller

In your Kubernetes, upgrading your nodes
Apache License 2.0
677 stars 83 forks source link

Inconsistencies in version and deployment instructions #224

Open aureq opened 1 year ago

aureq commented 1 year ago

Describe the bug Currently, k3s (which I think is part of Rancher) recommends a gitops approach to deploy the system-upgrade-controller (ref).

kubectl apply -f https://raw.githubusercontent.com/rancher/system-upgrade-controller/master/manifests/system-upgrade-controller.yaml

Likewise, this repository adopts a similar YOLO approach. (ref)

# Y.O.L.O.
kustomize build github.com/rancher/system-upgrade-controller | kubectl apply -f - 

I understand what is written in #183 and @dweomer's point of view but it would be great to clarify this so k3s/rancher users aren't given potentially dangerous instructions.

Suggestions Provided I'm correct regarding the k3s repository, here a command that could be used. This will automatically find the correct manifest file as stored in the GitHub release and deploy it.

# requires `jq` and `wget` available
kubectl apply -f "$(wget -q -O - https://api.github.com/repos/rancher/system-upgrade-controller/releases/latest | jq -r '.assets[] | select(.browser_download_url | contains("/system-upgrade-controller.yaml")) | .browser_download_url')"

For this repository, it would be great to clarify the instructions for kustomize simply because many people look for code blocks and do copy/paste (which is not always the right decision).

Thank you for considering this issue and for improving the overall user experience.

dweomer commented 1 year ago

I mean, I made an effort to connote the YOLO-ness of the "potentially dangerous instructions" concomitant with a rather dry reference to "curling to sudo bash". My brand of enablement while also relaying, stegongraphically, big "don't actually do this in prod" energy. 🤷

Anyhow, I no longer work at Rancher/SUSE. Hope this gets cleared up for you! /cc @brandond