Epic Goal

• To enable non-Kubernetes-native users (especially those using click-ops workflows) to effectively manage and troubleshoot nodes, particularly in Virt and Bare Metal scenarios where nodes are not disposable. The goal is to provide a clear, integrated view of node health, status, and associated storage and network configurations, thereby reducing operational friction and risk.

• Parent Jira Tracking for this effort
  https://issues.redhat.com/browse/VIRTSTRAT-527

Design document
https://docs.google.com/presentation/d/1VCThFMMttP5XWpFY32AHDD7uF-CsXmm2u6FeVvEtL1Y/

Why is this important?

• Who benefits?
  Virt administrators and operators responsible for running and maintaining critical virtualized or bare metal workloads.
• What's the difference?
  Today: Users struggle to understand node health, connectivity, and storage information due to scattered or missing data across OpenShift components.
  With this Feature: Users have an integrated view of node-related resources, including VMs, PVCs, storage classes, logs, events, and health data—all accessible from a unified UI.
• Node management on baremetal was identified as a top customer pain point in from UX research, support tickets, and from the field. 

“I get feedback (from customers and analysts) about the experience that, tersely, it is unintuitive, frustrating, and - at best - has a steep learning curve.” -Red Hat field

Scenarios

1. Background, and strategic fit

Today’s OpenShift UI does not meet the expectations of VMware customers, non-Kubernetes-native users managing critical infrastructure. In Virt workloads, nodes are persistent and crucial to service availability—unlike traditional Kube environments where nodes are ephemeral. Improving the node-centric experience is aligned with Red Hat’s strategic focus on user experience, platform reliability, and enterprise-grade virtualization.

Assumptions

• • Target users are less familiar with Kubernetes internals.
  • VMware users prefer a GUI-driven approach (click-ops) over CLI or YAML editing.
  • Storage and networking are top priorities for troubleshooting.
  • Logs and events tied to nodes are critical to operational insight.
    Customer Considerations

• • Need for clear, actionable insights without requiring Kubernetes expertise.
  • Desire for consistency and simplicity across the UI for storage/network observability.
  • Customers expect performance efficiency—no noticeable impact to cluster due to this UI feature.

Acceptance Criteria

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

Dependencies (internal and external)

Previous Work (Optional):

Open questions::

1. This work is speculative and spans several teams the release target depends on the team. We are going to make an specific effort to only target specific information 

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>