Uploaded image for project: 'Red Hat Internal Developer Platform'
  1. Red Hat Internal Developer Platform
  2. RHIDP-4003

Add a "namespace/project" drop down to the Topology View

Create Doc EPIC for Fe...Prepare for Y ReleasePrepare for Z ReleaseXMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • 1.2
    • Topology plugin
    • None
    • False
    • Hide

      None

      Show
      None
    • False

      Feature Overview (aka. Goal Summary)

      An elevator pitch (value statement) that describes the Feature in a clear,
      concise way.

      Feature:  Add a "namespace" drop down to the topology view to limit the display to the contents of a single namespace.

      The current version of the topology view can be very confusing to customers.  Many of the customers that I work with are already familiar with the topology view in OCP.  By default, this view is namespace specific.  For example, if you are in the "my-quarkus-app-dev" namespace, you only see pods for that namespace.

      However, the topology view in RHDH combines all pods for a component into a single view.  This is unexpected and a bit jarring at first, as you might expect to see a single pod (e.g. my-quarkus-app-dev), but see all the pods in namespaces associated with the component instead.

      Adding a "Namespace" drop-down would be a more natural analog to the OCP topology view, make the interface less crowded, and reduce confusion.

      Goals (aka. expected user outcomes)

      The observable functionality that the user now has as a result of receiving
      this feature. Include the anticipated primary user type/persona and which
      existing features, if any, will be expanded.

      The primary user would be any RHDH user that would normally interact with the topology view.  Adding a "namespace" filter would de-clutter the view and reduce confusion.

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order
      to be considered complete. If the feature spans across releases then good
      to have scope for each release with acceptance criteria. Be sure to
      include nonfunctional requirements such as security, reliability,
      performance, maintainability, scalability, usability, etc.

      The ability to select a single namespace that will be used as a filter to display assets in the topology view.

      Out of Scope (Optional)

      High-level list of items that are out of scope.

      N/A

      Customer Considerations (Optional)

      Provide any additional customer-specific considerations that must be made
      when designing and delivering the Feature. Initial completion during
      Refinement status.

      N/A

      Documentation Considerations

      Provide information that needs to be considered and planned so that
      documentation will meet customer needs. If the feature extends existing
      functionality, provide a link to its current documentation.

      N/A

              Unassigned Unassigned
              rhn-support-apitt Andrew Pitt
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: