-
Feature Request
-
Resolution: Unresolved
-
Undefined
-
None
-
1.2
-
None
-
False
-
-
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