Proposed title of this feature request

GitOps-awareness in the OpenShift Console

What is the nature and description of the request?

The OpenShift Console can put any Kubernetes object that has been applied or modified via GitOps procedures delivered via ArgoCD / OpenShift GitOps into the perspective of git history that is associated with it. Thus the user shall get the following abilities:

• discover which objects are "gitops-managed" (i.e. part of a application as defined in ArgoCD)
• discover where the git sources are for the object
• discover which OpenShift GitOps workflow / sync created/modified this object
• see the commit information of latest entry in the git log that modified this object (similar to git-aware IDEs, see screenshot)
  
• get insight into other objects that were part of the commit that created/updated object in the current context
• get the entire git log history of an object in the style of the GitHub history view (see screenshot)
  
• get a shortcut to revert the object in context to a previous state based on git history, in turn triggering a PR (if permissions allow) against the source git repository

Why does the customer need this? (List the business requirements here)

With the advent of GitOps it became easy to get a history for basically any changes in a declarative application deployment in Kubernetes. Thus, any Kubernetes resource involved in that deployment is now versioned. This is an ability that Kubernetes itself does not have since the amount of object versions could easily overwhelm the etcd database underneath the Kubernetes layer. git however is known to scale in this regard very well, easily storing hundreds and thousands of revisions of a particular file without resource consumption and thus offloading this burden from the cluster. GitOps-awareness of the Console brings this benefit into the operational context of OpenShift at ease without switching to the ArgoCD UI.

Today it is hard for user to reason about the history and origin of a Kubernetes resource in isolation via the OpenShift console. Specifically it easy to get the impression that an object can be modified at will, which is not true in GitOps, as the change will be overwritten by the next sync cycle. We solved this for Operator managed workloads in the OpenShift Console but the problem remains for GitOps-style deployments. GitOps-awareness of the Console would prevent these assumptions and help the user find the canonincal source of truth for this object and also incentivise the user to engage in the modification of that object in GitOps-friendly way (by creating a PR). Experimental use in trial-and-error discovery is encouraged while GitOps is enabled by making it trivial to create a reverting PR from within the console. Thus GitOps is not perceived as a barrier to a fast outer loop where the user make direct modifications from within the console (e.g. scaling, labels, env variables, etc)

The relationship of Kubernetes objects among each other are still hard to discover. Work has been done in the Console to mitigate this problem from a application developer perspective using the DevConsole. However the challenge persists for anything else that is not deployed via the application console, which could be anything from cluster configuration, Operator-backed CR interaction to any arbitrary resource that is applied. Because GitOps brings transactions to Kubernetes operations the related resources become related to each other by being part of the same commit. A user can instantly get awareness by looking at the other resources in the commit in the context of a given object to reason about the relationship of these objects, thus getting a better understanding on why they are there, and how to modify them together to create a valid configuration.

List any affected packages or components.

OpenShift Console

• needs to become aware of resource deployed by OpenShift GitOps, either from within the cluster or another cluster
• needs to attach a git identity to the user to impersonate git permissions

OpenShift GitOps

• needs to employ some sort of trackers / labels that the OpenShift Console can pick up to put objects into perspective of git commit history