Reimagining Storage Observability for OpenShift Data Foundation

Overview

OpenShift Data Foundation is Red Hat's software-defined storage platform built on top of Ceph.

For administrators, operating ODF means managing a complex web of nodes, devices, storage classes, replication policies, and placement services. While the system functions effectively, the deep structural relationships between these components were completely invisible in the user interface.

Problem

Understanding system health was difficult

When a cluster component failed, storage administrators could not quickly isolate the root cause. Instead, they were forced into a high-friction troubleshooting loop: bouncing between different dashboards, launching the Ceph toolbox, executing complex CLI commands, and manually tracing correlations between pods, nodes, and physical disks. The primary workflow blocker was clear: Users weren't struggling to execute actions. They were struggling to build an accurate mental model of the system health. Existing lists and tables showed what resources existed, but failed to communicate how they connected.

Design goals

• Make hidden infrastructure relationships visible.

• Drastically reduce dependency on CLI-only troubleshooting workflows.

• Expose multiple layers of technical abstraction without causing cognitive overload.

Design Process

Information Architecture

Before creating layout wireframes, I worked closely with core storage engineers and solution architects to map out structural dependencies from the cluster level down to bare metal.
We documented a strict technical hierarchy: Cluster → Zone → Node → Device → Ceph Service.

Later in the process, I ran a small activity with my internal engineering team to carefully evaluate what level of detail belonged at each layer. This eventually became the foundation for our information architecture and drill-down model.

Design Limitations

Looking at existing OpenShift design patterns (such as Developer and Network Topology), I uncovered a fundamental design gap: typical Kubernetes topologies stop at the logical application layer. They were never architected to map downstream to deep physical or virtual hardware infrastructures. This required us to invent new design paradigms within our design system.

Developer topology

Solution

Redefining Drill-Down as Navigation

The new experience shifted the paradigm from a static layout diagram to an active navigational framework for complex infrastructure. The solution introduced:

• Nested Canvas Layers: Allowing progressive disclosure of infrastructure density from zones down to individual drives.

• Functional UI Decorators: Overlaying immediate, real-time health, alert, and actionable markers on top of nodes.

• Contextual Details Panels: Side panels providing deep structural metadata instantly, removing the need to exit the canvas context

Community & Pattern Validation

Because this architecture pushed beyond standard framework constraints, I led design critiques, PatternFly reviews, and design sprints with PatternFly design team members to validate and refine the custom interactions, iconography, and navigation models.

Topology experience

User testing

We benchmarked our interactive design concepts directly with enterprise scale users, including infrastructure teams at Lockheed Martin. Two major validation requirements transformed our ultimate output:

Storage-first visual language

Enterprise admins rejected generic container or application nodes. They needed precise, storage-first representations of OSDs, MONs, MDS services, and disk groups.

Two-way troubleshooting paths

Testing proved that troubleshooting doesn't happen in a linear direction. Admins occasionally track issues hardware-first (Node → Service) or software-first (Service → Node). Beyond the initial release, we planned to extend the model to support both top-down and bottom-up ways of exploring storage resources.

Key Outcomes & Impact

We turned a collection of infrastructure resources into a navigable mental model. The topology reduced the need to start troubleshooting from disconnected resources by giving admins a visual starting point and a path to the underlying resources.

01

Drastic time-to-resolution drops

OpenShift/Storage administrators can pinpoint a failing physical disk within a multi-petabyte cluster in seconds, completely replacing hours of manual CLI correlation workflows.

02

Cohesive experience uniformity

Successfully integrated specialized, deep-infrastructure views into the main platform while expanding the corporate PatternFly open-source design library.

Core takeaway

Highly technical infrastructure platforms rarely face simple usability bugs; they face comprehension deficits. A designer's most vital contribution here is making abstract, complex relationships instantly visible and actionable.