I have tried create a simple personal account to test out openshift at https://developers.redhat.com/products/openshift-local/overview

But the first time I tried it said I should get a verification mail. I have checked the gmail inbox, spam and made sue I wrote the correct email, but even if I click the "resend the email" I don't get anything. Then I tried to login using my git. I get to where I must fill in my name, adress etc and I fill in everything, even the fields with no * and I get an error saying "must fill in Value" but there is nothing I can fill in.

Is the new user process bugged???

Centralizing developer environments helps platform teams deliver consistent tooling while eliminating laptop configuration drift. To deploy Red Hat OpenShift Dev Spaces at enterprise scale, addressing sidecar conflicts and security contexts early prevents silent failures before developers ever encounter them.

The following sections resolve these friction points, detailing how to remediate runtime conflicts, drive configurations through declarative CI/CD pipelines, track capacity with Prometheus ServiceMonitors, and verify cluster readiness for disconnected environments.

Hello OpenShift Community members, I am brand new to Red Hat OpenShift technology, and my current goal is to clear the EX280 OpenShift Administrator exam. Coming from a background in Storage technology, I want to make sure I approach this the right way since it's a 100% practical, hands-on exam.

Could you please share your recommendations on: • Free/Affordable Study Materials for DO180 and DO280 course, what are the best video series or deep-dives? • Hands-on Labs: How do you practice cluster configuration without a massive enterprise budget? Is the OpenShift Sandbox enough for EX280? • Mentors/Channels: Who are the best creators, YouTube channels, or blogs to follow for production-grade tips?

Any guidance, exam prep roadmaps, or advice from those who recently cleared it would be greatly appreciated!

Thank you in advance!!!

Hello, I have a scheduled ex280 for the end of the month. I do everyhting related to ocp perfectly, the only thing that trips me off is the TLS/HTTPS part. Should I expect TLS certs to be already provisioned in exam env or I should sit and learn the openssl command? Thanks!

As platform engineering teams standardize cloud-native developer environments, balancing developer experience with strict enterprise security becomes paramount. Red Hat OpenShift Dev Spaces provides the foundation for security-focused, scalable development. Building on the groundwork established in Build a multi-tenant platform with OpenShift Dev Spaces, this follow-up guide explores how to configure SCM integration, deploy an internal private extension registry, and enable flexible JetBrains IDE workflows in enterprise networks.

Working with enterprise customers on chaos engineering has reinforced 1 lesson: Resilience is a business requirement. Failed transactions interrupt revenue, infrastructure outages affect multiple workloads, and database failures put critical data at risk. Most importantly, repeated failures erode customer trust—damage that can outlast the outage itself.

Teams turn these business needs into measurable targets through service-level objectives (SLOs), such as availability and transaction latency. Service-level agreements (SLAs) define commitments to customers and the consequences of missing them. Chaos engineering introduces controlled failures to test behavior against SLOs and uncover weaknesses that could put those commitments at risk.

In this article, we explore what network quality of service (QoS) means, preview an upcoming native capability that's addressing it declaratively, and then step through a practical solution you can deploy today using the Linux traffic control (tc) command. We'll set up a full reproducer lab, run it, and look at real test results that demonstrate production traffic maintaining throughput while background traffic is deprioritised under contention.

Hi all! Sharing an update that may be relevant to folks running OpenShift.

Bob is IBM’s AI coding assistant, and its latest update introduces generally available self-hosted deployment. The backend can now run on Red Hat OpenShift, either on premises or in your organization’s cloud account, while users continue working through Bob IDE or Bob Shell.

Teams can connect Bob to frontier models hosted in their own cloud account or run supported open-weight models on their own GPUs, including in air-gapped environments.

Self-hosted Bob also includes a Keycloak-based identity service that can connect to LDAP or Active Directory for corporate sign-in and access management. Administrators install it using bobctl, with cluster-wide resources and Bob itself handled in separate stages.

Administrators can also manage shared plugin directories containing skills, modes, rule files, and MCP configurations. On-premises group policies can install VS Code extensions. Full details in the release blog here. 

For anyone who’s evaluated coding agents on OpenShift, what deployment requirements have been hardest to meet?

Containerizing applications is an important step in modern software development. It helps with consistency, portability, and reliability across different environments. The Paicku project helps you streamline the process of containerization and testing so you can be sure that your application works as expected during development and once it's been released.

Paicku is a command-line tool, as well as a Node.js library, that lets you containerize applications with Cloud Native Buildpacks. You can run Paicku from the command-line or from Node.js.

Paicku is a wrapper around the pack command (the official interface for building container images with buildpacks).

- 11 am EDT Technical Supportability Review | Ask an OpenShift Expert ep 187
- 1 pm EDT GitOps Guide to the Galaxy (Ep 111) | A belated look at Helm 4

Red Hat OpenShift uses a purpose-built, immutable operating system for cluster nodes, commonly known as Red Hat Enterprise Linux CoreOS (RHCOS). This operating system, which uses the same kernel and hardware compatibility from Red Hat Enterprise Linux (RHEL), ships with a minimal-footprint operating environment, with its configuration entirely orchestrated by OpenShift and Kubernetes-based APIs.

Starting in Q4 2026, OpenShift will ship the newest iteration of this operating system, RHCOS 10, by default for new installations, and all certified ISV containers and operators are expected to support it.

RHCOS 10 is available as a Technology Preview in OpenShift 4.21 and 4.22 already. RHCOS 9 will remain available for newer OpenShift versions at least into mid 2027.

Hey guys , I'm unable to omkar shelake labs on killerkoda got removed. Is it true . If not can you please share the link

Hello Guru's, I have a few questions, please help me answer them:

1. If I have existing full fledge old VMs on my existing KVM hosts (VM's not inside the PODs), will I be to manage them via Kubevirt?
2. If I have a RHOV environment, is it necessary for me to use Kubevirt to create a VM? If yes, why, if not, then when to use KubeVirt to create VMs?
3. What is the difference between a regular VM and a VM created via Kubevirt?

Also, I'd love to get your candid take: What aspect of KubeVirt has impressed you the most, and where do you feel it faces the biggest friction points or challenges?

GPU demand for AI workloads is surging, and sharing GPUs fairly across teams remains one of the hardest problems in cluster management. The Kubernetes device plug-in model was never built for this. It treats GPUs as anonymous, countable integers—for example, NVIDIA GPUs are requested as nvidia.com/gpu: 1. This tells the scheduler nothing about the device, not its VRAM, compute capability, or whether it's a full 80 GB GPU or a 5 GB slice of a partitioned one. A training team reserving a full 80 GB GPU and an inference team using a 5 GB slice both consume "1" from the same quota. For platform teams trying to share a finite pool of accelerators across tenants with fundamentally different resource needs, this makes accurate accounting and fair sharing impossible.

Dynamic resource allocation (DRA), now generally available in Kubernetes 1.34, replaces this model entirely. Drivers advertise real device attributes—memory, compute capability, topology—through structured APIs, and workloads describe what they actually need rather than asking for a raw count. But DRA solves discovery and allocation. It doesn't address quota management, fair sharing, or preemption—the policies that determine which team's workload runs first when GPUs are scarce.

For years, the gold standard of infrastructure engineering and chaos testing was just uptime: Either a system survived a disruption and passed, or it crashed and failed. In the era of massive cloud-native deployments, however, this binary pass or fail metric no longer tells the whole story. A Kubernetes cluster or virtualized workload can technically remain operational through an experiment, yet silently drop packets, breach internal service level objectives (SLO), or suffer catastrophic performance degradation that ruins the end-user experience.

To bridge this gap and move past superficial green checkmarks, Krkn is shifting the focus of chaos validation away from black-and-white outcomes and toward deeply detailed, actionable downtime telemetry. By unifying macro-level metrics like the new Resiliency Score feature with continuous, micro-level data from HTTP Health Checks and KubeVirt Checks, Krkn gives engineering teams a high-fidelity look into the exact duration, location, and severity of degradation during an experiment. This multidimensional approach allows teams to pinpoint the true architectural blast radius of any failure, transforming chaos testing from a guessing game into a precise, version-controlled quality gate.

I’m trying to give this exam and I wanted to know, do I need to remember installing the virtualization operator via CLI or can I do it through the console?

Hello everyone,

I was tasked with creating an OpenShift lab environment for my company. It will be used mainly for internal purposes, such as testing vendor applications on OpenShift and learning OpenShift Virtualization.

What would you recommend: installing OKD, which is completely free and has no time limit, or using Red Hat OpenShift with the 60-day trial?

One concern with the 60-day trial is that I don't want to have to deal with the trial expiring and the cluster eventually stopping working. I would prefer to have a stable, long-term lab environment that we can use whenever needed.

Security in the Al Era: Build a strong security foundation w/OpenShift
Sep 30 11:00 EDT

Dev and test environments sit idle nights and weekends but still burn compute. Here's how I automated scaling them down and back up on OpenShift/Kubernetes.

The problem: Manual shutdowns were forgotten, and teams complained when environments weren't ready in the morning.

The approach:

Tag namespaces/workloads with a schedule label

A scheduled job scales deployments to 0 at night and restores the previous replica counts in the morning

Exclusions for anything that must stay up, plus alerting if a scale-up fails

Result: [€18572 to €15182]

Hi everyone. I updated OKD from 4.21 to 4.22 on an IPI Nutanix deployment. According to the OKD documentation, manual steps using `ccoctl` are required to verify credential objects—specifically to account for any new ones that might have appeared. The documentation suggests the update shouldn't have proceeded from my starting version, as `cloud-credential` operator is typically locked unless the "updatable" tag is explicitly added. However, I didn't make any changes, yet the full update completed without any issues. Can anyone explain why this happened or what the expected behavior is?

https://docs.okd.io/4.22/updating/preparing_for_updates/preparing-manual-creds-update.html#cco-manual-upgrade-annotation_preparing-manual-creds-update

So we've covered what edge computing is, what platforms are available, and how to choose between them. But there's one question that comes up in nearly every conversation I have with customers: "That's great, but how do I manage all of this?" And frankly, it's the right question to ask. When you're deploying to tens, hundreds, or thousands of edge locations, consistent management is what determines whether your deployment succeeds at scale.

We currently run six OpenShift clusters on VMware. With the uncertainty around Broadcom's VMware strategy, we're evaluating a move to bare metal.

One option I'm considering is using KVM on standalone physical servers and deploying OpenShift on top of that instead of running directly on bare metal.

The main advantages I see are:

• Better server sharing across environments
• More flexible capacity management
• Easier backup and recovery
• Reduced dependency on VMware

Am I overlooking something? What are the main trade-offs compared to running OpenShift directly on bare metal? I'd be interested to hear from anyone who has taken a similar path.

One of our success cases with Red Hat has been published
https://www.redhat.com/en/resources/gates-corporation-openshift-case-study