Video summary

Ask an OpenShift Admin (E66) | Ops without apps is meaningless!

Main summary

Key takeaways

Technology

Topic: “Ops without apps is meaningless!”

The session frames OpenShift administration as inseparable from application onboarding and usage. Administrators should focus on enabling developers to successfully run workloads—improving real platform utilization—rather than only managing infrastructure.

Office-hours format: “Ask an OpenShift Admin”

  • The event runs like an OpenShift-focused office-hours session where hosts answer audience questions.
  • If hosts can’t answer directly, they route questions internally to:
    • Product management
    • Engineering
    • Consulting resources

“What’s new” / “What’s next” highlights (recent Red Hat updates)

1) CoreOS layering (roadmap concept)

What it is

  • RHEL CoreOS layering applies the “layering” idea (similar to RPM-OSTree layering) to CoreOS, but via a container-based mechanism.

Why it matters (use cases)

  • Adding host-level requirements like special drivers
  • Installing mandated packages for security/compliance
  • Offering a more flexible alternative to some MachineConfig patterns

Cautions

  • It can make it easier to “break things.”
  • Operators must still design for cloud-native workloads and avoid unintended host changes.

Status

  • Explicitly noted as roadmap (not necessarily shipped) and subject to change.

2) Platform theme shift toward “consistency and security”

Messaging emphasis

  • Improved and more consistent security posture across the platform, including tighter security integrations.

Related items mentioned

  • ACS (described as a cloud service / potentially a cloud service)
  • Dynamic network policies to reduce operational friction
  • Security Operator + ACS integration to deliver security configuration via consistent UI/integration patterns
  • KCP excitement:
    • Abstracting/virtualizing Kubernetes clusters behind a Kubernetes API
    • Developers interact with one API while multiple underlying clusters exist (1-to-many scaling / transparent cluster management)

3) Upgrade path clarifications (OCP update operations)

etcd / FCD blocking issue

  • A reported blocking issue for 4.8 → 4.9 was reportedly resolved in 4.9.28.
  • Effect: stable channel upgrades were re-enabled for affected cases.

Upgrade channels

  • Stable vs fast:
    • Fast is GA and supported, though admins may prefer testing before broader rollout.

Accelerated updates / EUS policy tie-in

  • For upgrades such as 4.8 → 4.10:
    • machine config pool rollouts can be paused while the control plane upgrades
    • nodes then jump ahead after unpausing

Important framing

  • No promises for roadmapped features—this is practical operational guidance.

4) “Bring your own scheduler” via Secondary Scheduler Operator (generally available)

Problem being solved

  • OpenShift previously limited deep scheduler customization/replacement due to risk to control plane pods.

What changed

  • With the Secondary Scheduler Operator (GA):
    • You can run a secondary scheduler for application workloads
    • The primary scheduler continues to handle control plane workloads

Example

  • “Load aware scheduling” (Trimaran mentioned)

Mechanism

  • Secondary scheduler applies via scheduler plugin mechanisms (linked to Kubernetes scheduler plugins).

Plugin categories mentioned

  • Capacity scheduling
  • Co-scheduling
  • Node resource topology
  • (and related scheduler plugin approaches)

Q&A highlights: how-to and operational guidance

CoreOS image/ISO compatibility when adding nodes

  • If you upgraded your OCP cluster and add nodes afterward, it’s generally technically compatible with the existing CoreOS/ISO.
  • New nodes typically:
    • Use ignition config
    • Fetch machine configs
    • Download the CoreOS version as a container onto the host

Recommendation for simplicity

  • Use a CoreOS image/ISO aligned to the same minor OCP release you’re on.
    • Example: deploy new nodes using a CoreOS version matching your current OCP minor.

How to verify versions

  • Use release.txt from mirror.openshift.com.
    • Component version info includes CoreOS container image details.
  • Note: not every OCP release includes a CoreOS update; CoreOS updates occur intermittently.

Scheduler / autoscaling concepts mentioned

  • HPA (Horizontal Pod Autoscaler) and VPA (Vertical Pod Autoscaler)
    • HPA scales based on CPU
    • VPA can bounce pods
  • KEDA
    • Supports scaling to zero
    • Can scale on arbitrary metrics (e.g., Prometheus-backed signals or app-level signals)

Storage provisioning & local storage operator mentions

  • Addressed local storage provisioning approaches, including:
    • HostPath provisioner caveats:
      • does not automatically create underlying paths
    • Mentioned Local Path Provisioner
    • Also referenced “local storage operator” / LVM-based approaches for single-node-style use cases (some operator names partially recalled)
  • General note:
    • availability and provisioning depend on cluster maturity/operator maturity.

Learning resources for OpenShift newcomers

Training

  • learn.openshift.com (redirects to developers.redhat.com)
  • try.openshift.com
  • Red Hat free learning course (DO080 mentioned)

Community support

  • openshift.org / OKD
  • Kubernetes Slack channels
  • OpenShift Commons community
  • Discord mentioned, but the host indicated it wasn’t very active

Main blog-post discussion: Developer onboarding + platform adoption

Core thesis: engage developers to drive utilization

Customers repeatedly asked how to:

  • Engage developers
  • Ensure developers can actually use OpenShift effectively
  • Turn platform capability into business value through improved utilization

Documenting best practices was positioned as a form of “automation” of knowledge transfer.

Christina’s highlighted sections

Beyond resource requirements, the blog emphasized topics such as:

  • Application design
  • CI/CD
  • Code and image promotion
  • Developer onboarding

Developer onboarding is a critical process

  • “Developer onboarding is paramount”
  • Start onboarding from:
    • cost/code/budget/developer needs
    • rather than “just give them a cluster”
  • Use progressive environments and sandboxes so teams learn without risking production.

Onboarding questions as a tool

  • The questions expose gaps in design-phase thinking.
  • Even when developers can’t answer everything, the goal is to use the questions to drive improvements and collaboration.

Bi-directional communication between platform and app teams

Recommended mechanism

  • Regular forums/meetings (weekly/biweekly)
  • Developers share requirements
  • Platform architects/product owners capture demand

Iterative onboarding

  • Day-1 requirements differ from Day-365 requirements.
  • Start with one workload/use case and expand gradually.
    • Example progression: stateless → later stateful capabilities (e.g., storage replication/backup)

DR (disaster recovery): avoiding VM-centric SRM-only thinking

SRM-like expectation (vSphere Site Recovery Manager)

  • SRM reinstantiates VMs.
  • The OpenShift analog implies:
    • “moving workloads”
    • validating the destination environment (auth/DNS/etc.)

Preferred cloud-native approach

  • Active-active or active-passive patterns where the destination environment is pre-built and tested
  • Data replication should be handled using OpenShift/data services (ACM/ODF-style capabilities referenced)

Key takeaway

  • Don’t treat DR as “restore the environment disk elsewhere.”
  • Workloads and platform dependencies differ.

Justifying business value to management via cost/utilization

A business-justification approach was introduced using:

  • Cost management capabilities (noted as “cost management software as a service”)

Goal

  • Demonstrate value by measuring relative cost effectiveness:
    • utilization
    • cluster density (apps per cluster)
    • reduced overhead

Important nuance

  • Ratios matter more than exact dollars (unless chargeback/cross-charging is in place).
  • Shadow IT and developer tagging/cost signals can help explain why teams choose different stacks.
  • Quota/chargeback patterns can discourage waste and enforce customer value.

Main speakers / sources

Speakers

  • Andrew Sullivan — Host, Red Hat Live Streaming
  • Johnny Rickard — Co-host
  • Christina Kiryakadu — Senior Architect, Red Hat Consulting Group (name appeared misspelled in subtitles; introduced as “Christina …”)

Sources referenced in the content

  • Mark Russell (tweet/thread referenced for CoreOS layering)
  • Trimaran (scheduler load-aware scheduling example)
  • Kubernetes SIG scheduler plugins (for scheduler plugin categories/mechanisms)
  • Community/support sources:
    • developers.redhat.com / learn.openshift.com / try.openshift.com
    • OKD
    • Kubernetes Slack channels
    • OpenShift Commons

Rate this summary

Your feedback will help improve summaries.

Improve this summary

Reprocess with a stronger model when the summary feels incomplete or inaccurate.

Pro

Translate summary in another language

Pro

Ask questions to this video

Chat for follow-up questions, clarifications, and source-backed answers.

Coming soon

Share this summary

Share on X/Twitter Share on LinkedIn Share on Reddit

Original video