Protect resources which are managed via GitOps from edits in the UI

[gianfranco-l]

User Story

- As a Giant Swarm user, I want to Protect resources which are managed via GitOps from edits in the UI so that I can prevent unwanted user edits and errors.

Background

A growing amount of Giant Swarm customers wants to manage resources like organizations, workload clusters, and apps via Gitops. Meaning that the definition for these resources is maintained in a git repository, and changes are reconciled automatically to the management cluster and workload clusters.

Tasks

web UI

• Specs for displaying GitOps-managed resources in the web UI #1176

[marians]

Copying from an internal issue: the label indicating that a resource is managed by GitOps is

giantswarm.io/managed-by: flux

[kuosandys]

Some notes from 20th June, 2022 refinement can be found here

[marians]

@ljakimczuk Our own cluster gollum/c68pn does not carry the label giantswarm.io/managed-by: flux on the main cluster resource. Is that a mistake in that cluster, or is the label not reliably found on gitops managed WCs?

[ljakimczuk]

@marians the problem with this label is that it is not set by any operator in terms of GitOps, it must be set manually on resources kept in the repository. So if you need an indicator of something being managed with GitOps, I would rather depend on the Flux labels, for example:

kustomize.toolkit.fluxcd.io/name: ...
kustomize.toolkit.fluxcd.io/namespace: ...

[marians]

@gianfranco-l There is a spec now in #1176 (comment) on how we intend to treat gitops-managed resources in the web UI. Would be great if honey badgers could give is some feedback on this. Implementation is not going to start before September 5.

[gianfranco-l]

@giantswarm/team-honeybadger pls have a look at this and provide feedback. more context here

[ljakimczuk]

@marians I checked the flux docs and according to it we can safely rely on these two labels:

• kustomize.toolkit.fluxcd.io/name for Kustomize-managed resources
• helm.toolkit.fluxcd.io/name for HelmRelease-managed resources

[uvegla]

Those labels from Flux might be useful to display for example which Kustomization manages the resource (maybe there we could link to it and from there we could link to the source and there to the repository). For example:

kustomize.toolkit.fluxcd.io/name: gorilla-clusters-rfjh2
kustomize.toolkit.fluxcd.io/namespace: default

And from the kustomization:

sourceRef:
  kind: GitRepository
  name: workload-clusters-fleet

And from the source:

url: https://github.com/giantswarm/workload-clusters-fleet

Could also lead to displaying the status of these Flux resources like if they are suspended. The status as well but honestly that changes very often for the the UI to keep pulling it, but maybe.

(Copied over relevant parts from: #1176 (comment))

+ You can also get the path from them to the exact path in the repo that is being reconciled.

[marians]

FYI @gusevda The icon is available in Fortawesome under the name gitops.

[marians]

@gusevda just made me aware of some details which weren't covered, or were't consistent in the spec. Some notes.

• If an app is managed through gitops, we don't show the edit functions, and we also don't show any CLI guide to edit the app via the management API. However for a cluster that is managed via gitops, we still showed the CLI guide to set cluster labels. We decided to remove the CLI guide for setting cluster labels in case the cluster is managed via gitops.

• Underneath the list of node pools, we decided that we still show the "Modify node pool" CLI guide, as this one is not specific to any particular node pool. And it's possible that there is a node pool in the list that is not managed via gitops.

• We noticed that for an app that shows the "Upgrade available" indicator, we don't display what the newer versions are that the app can be upgraded to. This will be improved by Installed app details should provide link to catalog and catalog item #1389

Future improvements

In this milestone we leave some cases that are not covered in an ideal way.

• We want to show the GitOps indicator on collapsed App items, too. However we want to account for the case where all apps are managed via gitops. In this case we would rather show a single indicator in top of the list, or near the button "Install app" to nudge users towards installing the app via GitOps, instead of installing it via the UI.

• We might offer CLI guides to work with the kubectl gs gitops command family.