Uploaded image for project: 'OpenShift GitOps'
  1. OpenShift GitOps
  2. GITOPS-3050

GitOps OpenShift Console experience for Admin perspective

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • None
    • GitOps OpenShift Console Admin Plugin
    • False
    • None
    • False
    • To Do

      Epic Goal

      Provide a user interface for OpenShift GitOps in the OpenShift Console Admin perspective that reflects the resource based design that the console is centered around. This interface will enable users to interact with a variety of Argo custom resources directly in the console as follows:

      1. Application
      2. AppProject
      3. ApplicationSet
      4. Rollouts

      This plugin would be not intended as a general replacement for the Argo CD UI since it operates under a different philosophy. Specifically the OpenShift Console is a Kubernetes resource driven view of the cluster and this plugin would adhere to that philosophy. Additionally the Argo CD UI has a large set of features that would be difficult to replicate.

      Rather the goal of this plugin is to enable users to accomplish a significant amount of their workflow in the OpenShift console and only punch out to the Argo CD UI for specific needs.

      A POC level implementation of the plugin can be found at the link below along with additional information about its capabilities and philosophy.

      https://github.com/gnunn-gitops/gitops-admin-plugin

      Having said that, the first step of this Epic should be an analysis to understand whether we should invest in this effort versus other possibilities for user experience. Specifically:

      1. ACM currently provides an Operations experience around Argo CD applications. While it is lacking in some respects (no way to filter on sync/health status, no status in list, no way to sync/refresh the application) these could be addressed. ACM provides the benefit of a fleet wide view of Argo CD Applications
      2. Backstage. Red Hat is currently investing in Backstage heavily via Project Janus. While Backstage has an Argo CD plugin it is quite limited and would likely require additional work. Backstage is great for a Developer level experience.
      3. Environments plugin. The existing plugin for the OpenShift console that is used in the Developer perspective. It provides an environmental based rather then resource based view of Argo CD.

      A demonstration of the POC plugin was given to some members of the field on the GitOps Community of Practice call from June 20th where interest in this being developed further was expressed.

      Meeting recording:[ https://drive.google.com/open?id=1KRyGg7FNYIA5_BcNCk0tA5osvk0FOeNL&usp=gmail|https://drive.google.com/open?id=1KRyGg7FNYIA5_BcNCk0tA5osvk0FOeNL&usp=gmail]
      Transcript:[ https://drive.google.com/open?id=1ZeTEihXbC0A2ptsDWlNDNOIN16crOLA5&usp=gmail|https://drive.google.com/open?id=1ZeTEihXbC0A2ptsDWlNDNOIN16crOLA5&usp=gmail]

      Why is this important?

      • Eliminates the need for users to bounce between different user interfaces providing a consistent experience
      • Further differentiates OpenShift GitOps from Argo CD

      Scenarios

      1. Managing OpenShift GitOps custom resources from the OpenShift console
      2. Addressing the need for a user interface in the console for rollouts

      Acceptance Criteria (Mandatory)

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

      1. OpenShift Dynamic Console SDK

      Previous Work (Optional):

      https://github.com/gnunn-gitops/gitops-admin-plugin

      Open questions::

      1. Resource based Console UI versus ACM versus Backstage versus existing Environments tab
      2. Pure resource based or hybrid resource/API based model. Currently POC is pure resource based however work was done on Hybrid which revealed a number of challenges.

      Done Checklist

      • Acceptance criteria are met
      • Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
      • User Journey automation is delivered
      • Support and SRE teams are provided with enough skills to support the feature in production environment

            saumeyakatyal Saumeya Katyal
            gnunn@redhat.com Gerald Nunn
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: