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

Improve cluster edit workflow for clusters created via RKE2 template #3761

Closed
slickwarren opened this issue Aug 10, 2021 · 3 comments
Closed
Assignees
Milestone

Comments

@slickwarren
Copy link
Contributor

on v2.6.0-rc1

Repro steps:

  • create a cluster via rke2 templates
  • go to cluster management -> edit config for the newly created cluster

Issue:
Screen Shot 2021-08-10 at 10 54 29 AM

(see screenshot above) for now, we are just giving this warning when a cluster is deployed via RKE2 template.

Solutions:

  • Option 1 : add a feature flag or some sort of toggle for admin to set, like this:
    • Allow users to edit clusters created via RKE2 template (changes that users make in the cluster will be overridden with the next change to your RKE2 template)
      • with this disabled, the edit button will not be shown for clusters created via RKE2 templates (we should be able to detect this, since we can add the warning for rke2 cluster templates)
      • with it enabled, the work flow will remain the same. We should add to the warning … please contact the rancher admin to make changes to the template for this cluster
@slickwarren slickwarren added this to the v2.6 milestone Aug 10, 2021
@slickwarren slickwarren self-assigned this Aug 10, 2021
@vincent99
Copy link
Contributor

If we were to do something about this issue it would be to detect the situation, find the corresponding app that deployed it and bring you to the upgrade for that instead so that you could do what you "meant" (change the config of how this cluster was deployed) instead of what you "said" (edit this specific cluster resource).

The banner about it being managed is a generic thing that applies to, and is shown for, all resources created from a helm install; it has nothing to do with clusters specifically. Any resource that was created by helm release will normally be overwritten if you use helm again to update it. If you still want to edit that resource directly you can, that is a valid thing to do. We do not normally have the UI pretend to enforce that you not do things that are still valid to do in the backend.

@slickwarren
Copy link
Contributor Author

detect the situation, find the corresponding app that deployed it and bring you to the upgrade for that instead so that you could do what you "meant" (change the config of how this cluster was deployed) instead of what you "said" (edit this specific cluster resource).
I agree that this would work, however for RKE2 templates only admin has access to update the template(s)/chart that deployed a cluster. So I was trying to think of a solution that would prevent unwanted updates from happening while also clarifying to users how to update the template vs. individual cluster updates.

My idea for this was, if user is admin we could expose a new field in the ... hamburger menu on each RKE2 template-deployed cluster, something like Edit RKE2 Template (screenshot below shows the menu I'm referring to)
Screen Shot 2021-08-10 at 1 41 53 PM

We do not normally have the UI pretend to enforce that you not do things that are still valid to do in the backend
I understand that editing a cluster created via rke2 templates is valid for a user, however (please correct me if I'm wrong) I don't understand how this would be useful in terms of the RKE2 template feature. These are the counters I can think of:

  • a user installs a cluster from a template and later decides to update it (say, the k8s version). later, the admin updates the template, say from 1 node to 3. Now, the user has. a cluster with nodes on an older version than expected, if the template is even able to upgrade due to the user's previous edits
  • say I am admin, and I want to use cluster templates to ensure some level of uniformity in the clusters that are deployed. I can limit/hardcode variables through the template. However, after the user goes through the template workflow, they can treat the cluster however they want.
  • This isn't quite the same comparison, but we do have some valid features (i.e. the legacy flag) that we can toggle through the UI

Again, I see that the current workflow is valid in terms of what can be done with clusters/templates but I think the intended uses of RKE2 templates might differ with that (especially considering people who have used rke1 templates and are used to the idea of locking in certain values)

@gaktive
Copy link
Member

gaktive commented Oct 17, 2024

Closing based on age. There have been changes around this page since 2.6.0 so if there are still questions, file a new ticket and link back.

@gaktive gaktive closed this as completed Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants