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

Inconsistencies in version and deployment instructions #224

Open
aureq opened this issue Feb 18, 2023 · 1 comment
Open

Inconsistencies in version and deployment instructions #224

aureq opened this issue Feb 18, 2023 · 1 comment

Comments

@aureq
Copy link

aureq commented Feb 18, 2023

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
Copy link
Contributor

dweomer commented Apr 10, 2023

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

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

No branches or pull requests

2 participants