Belief Registry

Claims

accelerator-device-plugins-daemonsets [IN] OBSERVATION

Device plugins register GPUs in the cluster and can be deployed manually or as DaemonSets.

access-modes-rwo-rwx-rox-rwop [IN] OBSERVATION

PV access modes are ReadWriteOnce (RWO), ReadWriteOncePod (RWOP), ReadOnlyMany (ROX), and ReadWriteMany (RWX); these describe capabilities, not enforced constraints.

acl-audit-log-annotation-key [IN] OBSERVATION

Audit logging for network policies is enabled via the k8s.ovn.org/acl-logging annotation on namespaces (for NetworkPolicy/EgressFirewall) or directly on ANP/BANP CRs.

acl-audit-log-default-rate-limit-20 [IN] OBSERVATION

The default audit log rate limit is 20 messages per second per node.

acl-audit-log-destinations [IN] OBSERVATION

Valid audit log destination values are: null (default), libc, udp:<host>:<port>, and unix:<file>.

acl-audit-log-file-path [IN] OBSERVATION

Audit logs are always written to /var/log/ovn/acl-audit-log.log on each OVN-Kubernetes pod, regardless of additional destination configuration.

acl-audit-logging-ovn-kubernetes-only [IN] OBSERVATION

Network policy audit logging is only available with the OVN-Kubernetes network plugin.

additional-trusted-ca-in-openshift-config [IN] OBSERVATION

The additionalTrustedCA ConfigMap referenced by image.config.openshift.io/cluster must be in the openshift-config namespace

admin-networkpolicy-cluster-scoped-alpha [IN] OBSERVATION

AdminNetworkPolicy and BaselineAdminNetworkPolicy (policy.networking.k8s.io/v1alpha1) are cluster-scoped network policy resources

admin-policy-external-route-api-group [IN] OBSERVATION

AdminPolicyBasedExternalRoute is a cluster-scoped CRD in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes

admin-policy-external-route-bfd-default-false [IN] OBSERVATION

BFD (Bidirectional Forwarding Detection) defaults to false on both static and dynamic hops in AdminPolicyBasedExternalRoute

admin-policy-external-route-dynamic-hop-empty-attachment [IN] OBSERVATION

When networkAttachmentName is empty on a dynamic hop, the system assumes the pod uses HostNetwork and the node IP is used as the gateway

admin-policy-external-route-dynamic-hop-requires-both-selectors [IN] OBSERVATION

Dynamic hops in AdminPolicyBasedExternalRoute require both podSelector and namespaceSelector

admin-policy-external-route-static-dynamic-hops [IN] OBSERVATION

AdminPolicyBasedExternalRoute supports two next-hop types: static (fixed IP) and dynamic (IP derived from gateway pods selected by podSelector and namespaceSelector)

admission-plugins-run-sequentially-in-chain [IN] OBSERVATION

Admission plugins run sequentially in an admission chain; if any plugin rejects a request, the entire chain aborts and returns an error.

affinity-ignored-during-execution [IN] OBSERVATION

"IgnoredDuringExecution" in affinity rules means pods are not evicted if labels change after scheduling — the pod continues running on its current node

affinity-label-selector-operators [IN] OBSERVATION

Pod affinity/anti-affinity label selector operators are: In, NotIn, Exists, DoesNotExist

affinity-topologykey-mandatory [IN] OBSERVATION

The topologyKey field is mandatory for pod affinity and anti-affinity rules

affinity-weight-range-1-100 [IN] OBSERVATION

Preferred affinity/anti-affinity rules use a weight value ranging from 1 to 100

agent-and-assisted-installer-support-bare-metal [IN] OBSERVATION

The Agent-based Installer and Assisted Installer also support bare metal as an installation target, in addition to the standard IPI and UPI methods.

agent-based-installer-fully-disconnected [IN] OBSERVATION

The agent-based installer shares the Assisted Installer's discovery ISO approach but runs fully disconnected without needing a service endpoint.

agent-installer-disconnected [IN] OBSERVATION

The Agent-based Installer is the disconnected-environment equivalent of the Assisted Installer

alerting-pipeline-rules-to-routing [IN] DERIVED

OpenShift alerting operates as a multi-stage pipeline: PrometheusRules define both recording and alerting rules (evaluated at 30s default intervals), AlertRelabelConfigs modify alerts before routing (supporting Replace/Keep/Drop/HashMod/LabelMap actions), Alertmanager routes and groups alerts (with inhibit rules suppressing targets when sources fire), and silences persist across pod restarts only with persistent storage — each stage transforms or filters the alert stream.

alertingrule-must-be-in-openshift-monitoring-ns [IN] OBSERVATION

AlertingRule and AlertRelabelConfig resources must be created in the openshift-monitoring namespace; they use apiVersion monitoring.openshift.io/v1.

alertingrule-namespace-openshift-monitoring [IN] OBSERVATION

AlertingRule resources for Network Observability alerts must be created in the openshift-monitoring namespace

alertingrule-openshift-specific [IN] OBSERVATION

AlertingRule is an OpenShift-specific CRD (monitoring.openshift.io/v1) that only supports alerting rules (NOT recording rules) and auto-creates a corresponding PrometheusRule in the openshift-monitoring namespace.

alertmanagerconfig-v1beta1 [IN] OBSERVATION

AlertmanagerConfig is at API version monitoring.coreos.com/v1beta1 (still beta), unlike most other monitoring CRDs which are v1.

alertrelabelconfig-modifies-before-alertmanager [IN] OBSERVATION

AlertRelabelConfig modifies alerts before Alertmanager routes them, not after.

alibaba-cloud-supported-platform [IN] OBSERVATION

Alibaba Cloud is a supported installation target for OpenShift Container Platform.

allnamespaces-mode-global-operators-group [IN] OBSERVATION

For AllNamespaces install mode, the openshift-operators namespace has a default OperatorGroup called global-operators; no additional OperatorGroup is needed.

allnamespaces-mode-uses-openshift-operators [IN] OBSERVATION

AllNamespaces install mode uses namespace openshift-operators; SingleNamespace mode requires creating an OperatorGroup in the target namespace

allnamespaces-mode-uses-openshift-operators-namespace [IN] OBSERVATION

For AllNamespaces install mode, the Subscription goes in the openshift-operators namespace which already has the global-operators OperatorGroup — no manual OperatorGroup creation needed.

allowed-blocked-registries-mutually-exclusive [IN] OBSERVATION

allowedRegistries and blockedRegistries in image.config.openshift.io/cluster are mutually exclusive — you cannot set both

allowed-registries-must-include-system [IN] OBSERVATION

When using allowedRegistries, you must explicitly include registry.redhat.io, quay.io, and the internal registry (image-registry.openshift-image-registry.svc:5000) — otherwise pods will fail

allowvolumeexpansion-prerequisite [IN] OBSERVATION

The allowVolumeExpansion: true field on a StorageClass is a prerequisite for all PVC expansion and defaults to false.

alternative-topologies-diverge-from-standard-operations [IN] DERIVED

Both hosted control planes and edge/SNO deployments require fundamentally different operational models from standard HA clusters: HCP separates control and data planes across clusters with distinct APIs (NodePool, HyperShift), while edge uses ZTP/TALM fleet management with reduced capability profiles — neither follows the standard MachineSet/MHC/in-cluster-control-plane pattern.

amd-gpu-operator-community-release [IN] OBSERVATION

The AMD GPU Operator is a community release, not a Red Hat-certified/supported Operator.

amd-gpu-operator-install-sequence [IN] OBSERVATION

AMD GPU Operator installation requires three Operators in sequence: Node Feature Discovery (NFD) Operator, then Kernel Module Management (KMM) Operator, then AMD GPU Operator.

amd-gpu-resource-identifier [IN] OBSERVATION

The AMD GPU resource identifier for Kubernetes resource requests and limits is amd.com/gpu.

amd-instinct-mi210-gfx90a [IN] OBSERVATION

The gfx90a architecture identifier corresponds to AMD Instinct MI210 GPUs.

anp-banp-api-group [IN] OBSERVATION

AdminNetworkPolicy and BaselineAdminNetworkPolicy use API group policy.networking.k8s.io/v1alpha1

anp-cluster-scoped-networkpolicy-namespace-scoped [IN] OBSERVATION

AdminNetworkPolicy is cluster-scoped while NetworkPolicy is namespace-scoped

anp-cluster-scoped-v1alpha1 [IN] OBSERVATION

AdminNetworkPolicy (ANP) is a cluster-scoped resource using API version policy.networking.k8s.io/v1alpha1

anp-evaluation-order-anp-np-banp [IN] OBSERVATION

Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy

anp-host-networked-pods-excluded [IN] OBSERVATION

Host-networked pods are excluded from ANP subject and peer selection

anp-ingress-peers-namespaces-pods-only [IN] OBSERVATION

ANP ingress peers support only namespaces and pods; egress additionally supports nodes and networks (CIDR)

anp-max-100-rules-per-direction [IN] OBSERVATION

ANP allows a maximum of 100 ingress rules and 100 egress rules per instance

anp-nodes-networks-egress-only [IN] OBSERVATION

AdminNetworkPolicy nodes and networks peer types are valid for egress rules only

anp-pass-delegates-to-networkpolicy [IN] OBSERVATION

ANP Pass action delegates the traffic decision to namespace-scoped NetworkPolicy, then to BANP if no NetworkPolicy matches

anp-port-default-protocol-tcp [IN] OBSERVATION

In ANP rules, when no port protocol is specified, the default is TCP; when no ports are specified, the rule matches all ports

anp-priority-range-0-1000-lower-higher [IN] OBSERVATION

ANP priority is an integer 0–1000 where lower values mean higher precedence, and two ANPs must not share the same priority

anp-priority-range-0-99 [IN] OBSERVATION

AdminNetworkPolicy priority range is 0–99 (maximum 100 ANP policies); lower value = higher precedence

anp-supports-pass-action [IN] OBSERVATION

AdminNetworkPolicy (ANP) supports three actions in audit logging: allow, deny, and pass; the pass action delegates evaluation to NetworkPolicy or BANP.

anp-three-actions-allow-deny-pass [IN] OBSERVATION

ANP rules support three actions: Allow (overrides NetworkPolicy denials), Deny (blocks traffic), and Pass (delegates to NetworkPolicy then BaselineAdminNetworkPolicy)

ansible-helm-base-images-not-deprecated [IN] OBSERVATION

Ansible-based and Helm-based Operator base images are NOT deprecated in OCP 4.17 — only the SDK CLI tooling is deprecated.

any-platform-upi-installation [IN] OBSERVATION

OpenShift supports "any platform" (platform-agnostic) installation for infrastructure without a dedicated installation method, requiring the administrator to manually provision all infrastructure components (DNS, load balancers, compute, networking).

api-governance-enforces-stability-and-immutability [IN] DERIVED

OpenShift API governance operates through two complementary enforcement mechanisms: a tiered stability model (Level 1–4) with webhook admission control governs API behavioral contracts, while resource-field and platform-level immutability prevents destructive drift after creation — together ensuring that both the API surface and its instantiated resources maintain consistency.

api-governance-spans-stability-and-admission [IN] DERIVED

OpenShift API governance operates across two dimensions: a tiered stability model (Level 1 through Level 4) defines compatibility guarantees and deprecation timelines, while the webhook admission system (TLS-required, 13s hard timeout, CEL match conditions) enforces runtime policy — together they govern both the evolution and the enforcement of the API surface.

api-stability-tiered-guarantee-model [IN] DERIVED

OpenShift APIs follow a tiered stability model: Level 1 provides 12-month/3-release stability (ConsolePlugin, SCC), Level 4 has no guarantees (ICSP), and unassigned groups default to Tier 3.

api-tier1-stable-within-major-release [IN] OBSERVATION

API Tier 1 is stable within a major release and cannot be removed until a subsequent major release.

api-tier2-stable-9-months-or-3-releases [IN] OBSERVATION

API Tier 2 is stable for at least 9 months or 3 minor releases from deprecation announcement, whichever is longer.

api-tier3-default-for-unassigned-groups [IN] OBSERVATION

API Tier 3 is the default tier for API groups without an explicit tier assignment; OperatorHub operators fall into this tier.

apirequestcount-default-users-to-report [IN] OBSERVATION

The default value for numberOfUsersToReport in APIRequestCount spec is 10.

apirequestcount-instance-naming-pattern [IN] OBSERVATION

APIRequestCount (apiserver.openshift.io/v1) instance names must follow the pattern resource.version.group (e.g., pods.v1). This is an OpenShift-specific resource.

apirequestcount-last24h-indexed-by-hour [IN] OBSERVATION

APIRequestCount last24h is indexed by hour of day (0–23), where index 0 = 12:00AM–12:59AM, not a rolling window.

apirequestcount-naming-format [IN] OBSERVATION

APIRequestCount instances are named using the format resource.version.group (e.g., deployments.v1.apps).

apirequestcount-openshift-specific-resource [IN] OBSERVATION

APIRequestCount is an OpenShift-specific resource (apiserver.openshift.io/v1), not part of upstream Kubernetes.

apirequestcount-removedinrelease-field [IN] OBSERVATION

The removedInRelease status field on APIRequestCount indicates in which OpenShift release the tracked API will be removed, used for deprecated API migration planning before upgrades.

apiserver-clientca-openshift-config [IN] OBSERVATION

The APIServer clientCA ConfigMap must reside in the openshift-config namespace with key ca-bundle.crt; serving certificate Secrets must be kubernetes.io/tls type in openshift-config.

apiserver-etcd-encryption-resources [IN] OBSERVATION

Etcd encryption covers: secrets, configmaps, routes, oauthaccesstokens, and oauthauthorizetokens.

apiserver-four-audit-profiles [IN] OBSERVATION

The APIServer supports four audit profiles: Default, WriteRequestBodies, AllRequestBodies, and None.

apiserver-resource-singleton-cluster [IN] OBSERVATION

The APIServer resource (config.openshift.io/v1) is cluster-scoped and the canonical instance is always named cluster.

apiserver-shared-by-three-servers [IN] OBSERVATION

The APIServer config object holds shared settings consumed by kube-apiserver, openshift-apiserver, and oauth-apiserver.

apiserver-tls-modern-not-supported [IN] OBSERVATION

The Modern TLS security profile (TLS 1.3) is not currently supported on the APIServer; maximum available minTLSVersion is VersionTLS12.

apiserver-tls-profiles-mozilla [IN] OBSERVATION

APIServer TLS profiles follow Mozilla Server Side TLS: Old (TLS 1.0), Intermediate (TLS 1.2, recommended), Modern (TLS 1.3, unsupported), Custom (user-defined).

apiservice-name-format-version-dot-group [IN] OBSERVATION

The APIService resource name must follow the format "version.group" (e.g., v1.apps).

apiservice-only-https-supported [IN] OBSERVATION

APIService only supports HTTPS for communication with backing API servers; insecureSkipTLSVerify exists but caBundle is strongly preferred.

apiservice-priority-values-convention [IN] OBSERVATION

Recommended APIService priority values: core *.k8s.io groups at 18000, PaaS platforms like OpenShift at 2000s.

apiservice-required-fields-priority [IN] OBSERVATION

APIService has two required spec fields: groupPriorityMinimum and versionPriority.

apiservice-service-port-default-443 [IN] OBSERVATION

The APIService .spec.service.port defaults to 443 if not specified.

application-delivery-operates-within-governed-immutable-platform [IN] DERIVED

Application packaging and delivery (Helm/Templates → build systems → ImageStreams → registry) operates entirely within the operator-driven immutable platform: applications are built on nodes managed by MCO, stored in registries managed by the Image Registry Operator, and deployed through operators managed by OLM — the application lifecycle never escapes operator governance

application-packaging-and-delivery-model [IN] DERIVED

OpenShift application delivery spans packaging and image production: Helm charts and Templates define application structure with two parallel packaging mechanisms, while dual build systems (Shipwright/BuildConfig) produce container images through ImageStreams and the internal registry — creating a complete define→build→store pipeline.

appliedclusterresourcequota-api-group [IN] OBSERVATION

AppliedClusterResourceQuota belongs to the OpenShift-specific API group quota.openshift.io/v1.

appliedclusterresourcequota-openshift-specific [IN] OBSERVATION

AppliedClusterResourceQuota is an OpenShift-specific extension beyond upstream Kubernetes that enforces resource quotas across multiple namespaces.

appliedclusterresourcequota-project-admin-visibility [IN] OBSERVATION

Project administrators can view AppliedClusterResourceQuota objects in their project without cluster-admin privileges, providing project-scoped visibility of cluster-wide quotas.

appliedclusterresourcequota-read-only [IN] OBSERVATION

AppliedClusterResourceQuota is a read-only projection of ClusterResourceQuota into a project namespace — only GET operations are available, and it is not created directly by users.

appliedclusterresourcequota-readonly-projection [IN] OBSERVATION

AppliedClusterResourceQuota (quota.openshift.io/v1) is a read-only, project-scoped projection of ClusterResourceQuota that lets project admins see which cluster-level quotas apply to their project and current usage.

approve-installplan-command [IN] OBSERVATION

Approve a pending InstallPlan: oc patch installplan <name> -n <namespace> --type merge --patch '{"spec":{"approved":true}}'

argocd-cli-docs-separate-from-ocp [IN] OBSERVATION

The argocd CLI installation docs live under the OpenShift GitOps documentation, not the core OCP documentation.

argocd-max-300-siteconfig-per-application [IN] OBSERVATION

Each ArgoCD application can manage a maximum of 300 SiteConfig CRs.

assisted-installer-jwt-15min [IN] OBSERVATION

JWT tokens for the Assisted Installer REST API are valid for 15 minutes only.

assisted-installer-preflight-validation [IN] OBSERVATION

The Assisted Installer performs pre-flight host validation (CPU, memory, disk, networking) before allowing installation to proceed.

assisted-installer-saas-or-self-hosted [IN] OBSERVATION

The Assisted Installer can run as a hosted SaaS service at console.redhat.com or be self-hosted via the Assisted Installer Operator for disconnected/restricted environments.

assisted-installer-uses-discovery-iso [IN] OBSERVATION

The Assisted Installer uses a discovery ISO that is booted on target hosts to register them with the installer service.

assisted-vs-agent-based-installer [IN] OBSERVATION

Assisted Installer and Agent-based Installer are two distinct on-premise installation methods for OpenShift.

auth-dir-contains-kubeconfig-and-password [IN] OBSERVATION

The auth/ directory under the install assets directory contains both kubeconfig and kubeadmin-password files

authentication-canonical-name-cluster [IN] OBSERVATION

The Authentication resource (config.openshift.io/v1) has a canonical instance name of cluster and is a cluster-scoped singleton.

authentication-default-type-integrated-oauth [IN] OBSERVATION

The default authentication type (spec.type) for the Authentication resource is IntegratedOAuth.

authorization-and-resource-governance-model [IN] DERIVED

OpenShift enforces a comprehensive governance model: dual authorization systems (OpenShift auth + K8s RBAC) control access to resources, while resource quotas force explicit declarations — together creating a contract where both access and consumption are strictly governed.

authorization-review-apis-post-only [IN] OBSERVATION

All authorization review APIs (LocalResourceAccessReview, LocalSubjectAccessReview, ResourceAccessReview, SelfSubjectRulesReview) only support POST — they are create-only resources with no GET/LIST/DELETE operations.

automated-etcd-backup-requires-techpreview [IN] OBSERVATION

Automated etcd backups are a Technology Preview feature requiring the TechPreviewNoUpgrade feature gate, which is irreversible and blocks minor version updates.

autoscaler-default-expander-random [IN] OBSERVATION

The default cluster autoscaler expander strategy is Random; other options are LeastWaste and Priority.

autoscaler-default-utilization-threshold [IN] OBSERVATION

The default autoscaler utilization threshold for scale-down is "0.5" (50%), expressed as a string value.

autoscaler-max-nodes-total-includes-control-plane [IN] OBSERVATION

The maxNodesTotal setting in ClusterAutoscaler must account for all machines including control plane nodes, not just autoscaled compute nodes.

autoscaler-min-replicas-zero-cloud-only [IN] OBSERVATION

MachineAutoscaler minReplicas can be set to 0 on AWS, GCP, Azure, RHOSP, and vSphere only.

autoscaler-priority-expander-configmap-name [IN] OBSERVATION

The priority expander ConfigMap must be named cluster-autoscaler-priority-expander in the openshift-machine-api namespace; higher integer means higher priority.

autoscaler-requires-machine-autoscaler [IN] OBSERVATION

The ClusterAutoscaler requires at least one MachineAutoscaler to be deployed; without it, the cluster autoscaler will never scale.

autoscaler-types-pod-vs-node [IN] OBSERVATION

HorizontalPodAutoscaler scales pod replicas, ClusterAutoscaler sets cluster-wide node scaling policy, and MachineAutoscaler scales specific MachineSets

autoscaling-and-placement-resource-management [IN] DERIVED

OpenShift workload resource management spans two complementary systems: multi-level autoscaling (ClusterAutoscaler→HPA/KEDA→VPA) adjusts capacity at infrastructure and pod levels, while multi-dimensional scheduling (selectors, taints, affinity, topology, gates) places workloads within that capacity — together forming the complete resource allocation model.

autoscaling-placement-within-governance [IN] DERIVED

Workload resource management (multi-level autoscaling + scheduling + storage placement) operates within the governance model: quotas force explicit resource declarations that autoscalers must respect, RBAC controls who configures scaling policies, and project-level self-provisioning governance determines which namespaces workloads can scale into.

aws-alb-operator-ip-mode-disabled-on-ocp [IN] OBSERVATION

IP traffic mode is disabled on OCP for the AWS Load Balancer Controller (only works on EKS).

aws-alb-operator-namespace [IN] OBSERVATION

The AWS Load Balancer Operator runs in the aws-load-balancer-operator namespace.

aws-alb-operator-outposts-alb-yes-nlb-no [IN] OBSERVATION

AWS Outposts supports ALB but not NLB with the AWS Load Balancer Operator.

aws-alb-operator-requires-nodeport [IN] OBSERVATION

The AWS Load Balancer Operator requires service type NodePort — not LoadBalancer or ClusterIP.

aws-alb-operator-rolearn-in-subscription [IN] OBSERVATION

The ROLEARN environment variable is set in the Subscription spec to configure STS for the AWS Load Balancer Operator.

aws-alb-operator-two-iam-roles-for-sts [IN] OBSERVATION

STS clusters require two separate IAM roles for the AWS Load Balancer Operator: one for the Operator and one for the Controller.

aws-alb-operator-x86-only-no-govcloud [IN] OBSERVATION

The AWS Load Balancer Operator only supports x86_64 architecture and does not support AWS GovCloud.

aws-cluster-tag-owned-vs-shared [IN] OBSERVATION

AWS tag kubernetes.io/cluster/<clusterid>=owned means the resource is destroyed with the cluster; shared means it persists after cluster deletion.

aws-default-lb-type-classic [IN] OBSERVATION

Default AWS load balancer type for OpenShift is Classic; NLB must be explicitly set via lbType: NLB in install-config.yaml.

aws-efs-gcp-filestore-not-default-installed [IN] OBSERVATION

AWS EFS and GCP Filestore CSI drivers are NOT installed by default in OCP 4.17 — they must be installed manually.

aws-efs-volume-metrics-disabled-by-default [IN] OBSERVATION

AWS EFS volume metrics in ClusterCSIDriver are disabled by default; the RecursiveWalk option can cause high CPU/memory usage.

aws-lb-default-classic [IN] OBSERVATION

On AWS, the Ingress load balancer type defaults to Classic; can be set to NLB for network load balancing

aws-local-zone-delete-order [IN] OBSERVATION

For AWS Local Zone deployments, deletion order is: cluster first, then Local Zone CloudFormation stack, then VPC stack

aws-local-zone-mtu-1300 [IN] OBSERVATION

MTU between AWS Local Zone / Wavelength Zone EC2 instances and Region instances is typically 1300.

aws-ocp-user-tags-limit-25 [IN] OBSERVATION

OpenShift on AWS allows up to 25 user-defined tags; 25 additional tags are reserved for OpenShift (50 total).

aws-rhel-ami-owner-account-id [IN] OBSERVATION

Red Hat's AWS account ID for RHEL AMI images is 309956199498.

aws-sts-entra-require-manual-operator-approval [IN] OBSERVATION

AWS STS and Microsoft Entra Workload ID clusters must use Manual approval strategy for Operator subscriptions.

azure-disk-encryption-set-three-fields [IN] OBSERVATION

Azure disk encryption set configuration in ClusterCSIDriver requires three fields: name, resourceGroup, and subscriptionID.

azure-disk-only-managed-supported [IN] OBSERVATION

Azure Disk only supports kind: Managed in OpenShift; Shared and Dedicated create unmanaged disks that cannot attach to OCP nodes.

azure-file-no-symlinks-default [IN] OBSERVATION

Azure File does not support symlinks, hard links, extended attributes, sparse files, or named pipes by default; symlinks can be enabled with the mfsymlinks mount option.

azure-file-smb-rwx [IN] OBSERVATION

Azure File uses the SMB (Server Message Block) protocol and supports ReadWriteMany (RWX) access mode.

azure-stack-hub-separate-from-azure [IN] OBSERVATION

Azure Stack Hub is a distinct installation target from standard Azure, with different API endpoints, available VM sizes, and networking constraints.

azure-supports-ipi-and-upi [IN] OBSERVATION

OpenShift on Azure supports both Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI) installation methods.

balance-slb-no-pod-traffic-load-balancing [IN] OBSERVATION

OVS balance-slb mode cannot load-balance OVN-Kubernetes pod traffic because all pods share the same MAC and VLAN; it only benefits VM workloads with distinct MACs.

banp-allow-deny-only-no-pass [IN] OBSERVATION

BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass action, which is ANP-only)

banp-lowest-precedence-fallback [IN] OBSERVATION

BaselineAdminNetworkPolicy applies only when no AdminNetworkPolicy or NetworkPolicy matches the traffic — it is the lowest-priority policy layer

banp-max-100-rules-host-network-excluded [IN] OBSERVATION

BANP allows maximum 100 rules per direction (ingress/egress), and host-networked pods are excluded from subject and peer selection

banp-networks-cidr-max-25-affects-internal [IN] OBSERVATION

The networks CIDR peer in BANP/ANP supports up to 25 CIDRs and affects all traffic including cluster-internal (e.g., 0.0.0.0/0 affects pod-to-pod traffic)

banp-only-allow-deny [IN] OBSERVATION

BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass)

banp-singleton-named-default [IN] OBSERVATION

BaselineAdminNetworkPolicy is a singleton resource that must be named default

bare-metal-edge-maximum-divergence-from-platform-model [IN] DERIVED

Bare metal edge deployments represent the maximum divergence from the standard OpenShift operational model: they combine full-stack infrastructure specialization (BMC, Ironic, MetalLB) with topology-specific constraints (SNO limitations, ZTP fleet management, TALM update gating), requiring the most specialized operational playbook of any deployment pattern.

bare-metal-edge-requires-full-stack-specialization [IN] DERIVED

Bare metal edge deployments require specialized infrastructure at every layer AND fleet-scale lifecycle management: provisioning uses BMC+Ironic+MetalLB (not cloud APIs), while ZTP+TALM handle provisioning and updates at scale with canary failure gating — making bare metal edge the most infrastructure-demanding deployment topology.

bare-metal-hosts-metal3-only [IN] OBSERVATION

Bare metal hosts in the Cluster Inventory dashboard card are only visible in metal3 environments

bare-metal-ipi-requires-redfish-or-ipmi [IN] OBSERVATION

Bare metal IPI installation requires Redfish or IPMI-capable hardware for automated provisioning.

bare-metal-ipi-uses-bmc [IN] OBSERVATION

Bare metal IPI (Installer-Provisioned Infrastructure) automates hardware provisioning via baseboard management controllers (BMC) using Redfish or IPMI protocols.

bare-metal-ipi-uses-bmc-protocols [IN] OBSERVATION

Bare metal IPI installations use Baseboard Management Controller (BMC) protocols such as IPMI and Redfish to manage host provisioning.

bare-metal-no-hypervisor-layer [IN] OBSERVATION

Bare metal installations run directly on physical hardware without a virtualization/hypervisor layer.

bare-metal-provisioning-architecture [IN] DERIVED

Bare metal IPI uses BMC for hardware automation, BareMetalHost resources with root device hints for disk selection, and a Provisioning CR consumed by the cluster-baremetal-operator to manage the metal3 lifecycle.

bare-metal-remediation-two-strategies [IN] OBSERVATION

Bare metal MachineHealthCheck has two mutually exclusive remediation strategies: annotation-based (external-baremetal) and metal3-based (Metal3RemediationTemplate), both using power-cycle rather than reprovisioning.

bare-metal-requires-specialized-infra-at-every-layer [IN] DERIVED

Bare metal clusters require platform-specific infrastructure at both provisioning (BMC automation, BareMetalHost CRs with root device hints, Ironic-backed Provisioning CR) and runtime networking (MetalLB with L2 gratuitous ARP failover or BGP with single-ASN constraint) — neither layer has a cloud-provider equivalent that works automatically.

bare-metal-supported-install-target [IN] OBSERVATION

Bare metal is a first-class supported platform for OpenShift Container Platform installation, deploying directly on physical hardware without a cloud provider or virtualization layer.

bare-metal-upi-manual-provisioning [IN] OBSERVATION

Bare metal UPI (User-Provisioned Infrastructure) requires the administrator to manually prepare machines, networking, DNS, and load balancers before running the OpenShift installer.

bare-metal-vsphere-registry-starts-removed [IN] OBSERVATION

On bare metal, Nutanix, and vSphere, the Image Registry Operator bootstraps as Removed; admin must manually switch to Managed and configure storage.

bare-pods-not-rescheduled [IN] OBSERVATION

Bare pods (not managed by a replication controller) are NOT rescheduled upon node failure.

baremetalhost-lives-in-openshift-machine-api [IN] OBSERVATION

BareMetalHost resources live in the openshift-machine-api namespace by default.

batch-workload-retry-model [IN] DERIVED

OpenShift batch workloads follow a unified retry and scheduling model: Jobs default to 6 retries with exponential backoff capped at 6 minutes, CronJobs add timezone-aware scheduling with three concurrency policies (Allow/Forbid/Replace), and pods default to Always restart with exponential backoff capped at 5 minutes.

batch-workloads-constrained-by-scheduling-and-retry-semantics [IN] DERIVED

Batch workloads in OpenShift must navigate two independent constraint systems: the retry/failure model (backoff limits, pod failure policies, concurrency policies, restart restrictions) governs temporal behavior, while multi-dimensional scheduling constraints (node selectors, taints, affinity, topology, NUMA policy) govern spatial placement — both must be satisfied for a batch job to complete successfully

binding-deprecated-since-v1-7 [IN] OBSERVATION

The Binding (v1) resource is deprecated since Kubernetes v1.7; pod-to-node binding should use the bindings subresource of pods instead.

binding-namespace-scoped [IN] OBSERVATION

Bindings are namespace-scoped resources; the namespace appears in all endpoint paths.

binding-post-only-write-once [IN] OBSERVATION

Bindings support only POST operations — they are write-once and not updatable.

binding-target-only-required-field [IN] OBSERVATION

The only required field on a Binding object is target (an ObjectReference).

binding-v1-deprecated-since-k8s-1.7 [IN] OBSERVATION

The Binding v1 API object has been deprecated since Kubernetes 1.7; the recommended replacement is the bindings subresource of pods.

block-volumes-require-volumedevices [IN] OBSERVATION

Block volumes use volumeMode: Block on PV and PVC, and pods use volumeDevices/devicePath instead of volumeMounts/mountPath, requiring privileged containers.

bluefield2-dpu-to-nic-one-way-only [IN] OBSERVATION

Switching NVIDIA Bluefield-2 from DPU mode to NIC mode is supported, but switching from NIC back to DPU mode is unsupported (one-way only)

bluefield2-multi-device-pci-address-required [IN] OBSERVATION

If multiple Bluefield-2 devices exist on a node, the PCI address must be explicitly specified and must be consistent across all nodes being switched

bluefield2-switch-requires-sriov-operator [IN] OBSERVATION

Switching Bluefield-2 from DPU to NIC mode requires the SR-IOV Network Operator and uses a MachineConfig-deployed systemd service (dpu-switch.service) that triggers a node reboot

bmceventsubscription-namespaced [IN] OBSERVATION

BMCEventSubscription is a namespaced resource (not cluster-scoped).

bmceventsubscription-webhook-mechanism [IN] OBSERVATION

BMCEventSubscription (metal3.io/v1alpha1) forwards BMC hardware events to a user-specified webhook URL, with optional custom HTTP headers stored in a Secret.

bmh-api-group-metal3 [IN] OBSERVATION

BareMetalHost is a Custom Resource with API group metal3.io/v1alpha1, used to manage physical bare-metal servers in OpenShift.

bmh-bmc-secret-keys-username-password [IN] OBSERVATION

BMC credentials Secret for BareMetalHost must contain keys named exactly username and password.

bmh-default-boot-mode-uefi [IN] OBSERVATION

The default boot mode for BareMetalHost is UEFI.

bmh-hardware-profile-deprecated [IN] OBSERVATION

The hardwareProfile field on BareMetalHost is deprecated; use architecture and rootDeviceHints instead.

bmh-live-iso-checksum-ignored [IN] OBSERVATION

For BareMetalHost image format live-iso, checksum fields are ignored; the ISO is live-booted, not written to disk.

bmh-only-required-field-online [IN] OBSERVATION

The only required spec field on a BareMetalHost resource is online (boolean), which controls whether the server should be powered on.

bmh-rootdevicehints-model-vendor-substring [IN] OBSERVATION

In BareMetalHost rootDeviceHints, the model and vendor fields support substring matching; all other fields require exact match.

bmh-software-raid-rules [IN] OBSERVATION

BareMetalHost software RAID supports max 2 devices; the first must be RAID-1, the second can be RAID-0, RAID-1, or RAID-1+0.

bond-cni-failovermac-required-active-backup [IN] OBSERVATION

failOverMac must be set to 1 (mandatory) when using active-backup mode with Bond-CNI in OpenShift.

bond-cni-links-in-container-required [IN] OBSERVATION

linksInContainer must be set to true in the Bond-CNI NetworkAttachmentDefinition to find interfaces inside the container rather than on the host.

bond-cni-only-supports-sriov-vfs [IN] OBSERVATION

OpenShift Bond-CNI is only supported with SR-IOV virtual functions — other CNI types or interface types are not supported for pod-level bonding.

bond-cni-sriov-only [IN] OBSERVATION

The Bond CNI plugin only supports SR-IOV Virtual Functions (VFs) for bonding; it cannot bond arbitrary interfaces.

bond-cni-supported-modes [IN] OBSERVATION

OpenShift Bond-CNI supports only three bonding modes: balance-rr (0), active-backup (1), and balance-xor (2).

bond-cni-trust-mode-for-rr-xor [IN] OBSERVATION

SR-IOV VF trust mode must be set to on when using balance-rr or balance-xor bonding modes.

bond-pod-annotation-requires-three-networks [IN] OBSERVATION

A pod using SR-IOV bonding must list all three networks in the k8s.v1.cni.cncf.io/networks annotation: two SR-IOV networks plus one bond network.

bootkube-etcd-connection-refused-normal [IN] OBSERVATION

During bootstrap, bootkube.service etcd "connection refused" errors are normal and expected — they resolve once control plane nodes join.

bridge-cni-same-host-only [IN] OBSERVATION

The bridge CNI plugin only enables communication between pods on the same host and with the host itself.

brokertemplateinstance-experimental-cluster-scoped [IN] OBSERVATION

BrokerTemplateInstance is an experimental, cluster-scoped resource in the template.openshift.io/v1 API group that links the Template Service Broker to TemplateInstance objects.

build-additional-trusted-ca-deprecated [IN] OBSERVATION

spec.additionalTrustedCA on the Build config resource is deprecated — the correct approach is to use image.config.openshift.io/cluster instead.

build-and-image-delivery-pipeline [IN] DERIVED

OpenShift provides an end-to-end image delivery pipeline: dual build systems (Shipwright + BuildConfig) produce images, ImageStreams provide controlled access with immutable content-addressed storage, and the internal registry can be exposed externally with re-encrypt TLS — connecting build, storage, and distribution.

build-completion-deadline-from-scheduling [IN] OBSERVATION

completionDeadlineSeconds is counted from when the build pod is scheduled, not from when it is created

build-defaults-vs-overrides [IN] OBSERVATION

spec.buildDefaults values can be overridden by individual BuildConfig objects; spec.buildOverrides values cannot be overridden and are forced on all builds.

build-git-proxy-overrides-default-proxy [IN] OBSERVATION

gitProxy overrides defaultProxy for git operations in the Build config; unset gitProxy fields inherit from defaultProxy.

build-mount-trusted-ca-not-persisted [IN] OBSERVATION

When mountTrustedCA is enabled, changes to /etc/pki/ca-trust inside the build are NOT persisted in the output image

build-nodeselector-nil-vs-empty [IN] OBSERVATION

Build nodeSelector: nil inherits cluster defaults; empty map {} overrides/ignores cluster defaults; map with values uses those values and ignores defaults

build-output-kind-imagestream-or-docker [IN] OBSERVATION

Build output to kind must be either ImageStreamTag or DockerImage — no other kinds are valid

build-overrides-imagelabels-overwrite [IN] OBSERVATION

buildOverrides.imageLabels overwrites user-provided labels with the same name; buildDefaults.imageLabels are overridden by user-provided labels.

build-postcommit-failure-fails-build [IN] OBSERVATION

Post-commit hooks run after the last image layer is committed but before pushing to the registry; a non-zero exit code fails the entire build

build-postcommit-no-script-and-command [IN] OBSERVATION

Post-commit hooks cannot specify both script and command simultaneously — this is invalid

build-secrets-truncated-after-s2i-assemble [IN] OBSERVATION

Build-injected secrets are truncated to zero length after the Source-to-Image (S2I) assemble script completes as a security measure

build-strategies-docker-s2i-custom [IN] OBSERVATION

OpenShift BuildConfig supports three active build strategies: Docker (Dockerfile), Source-to-Image (S2I), and Custom

build-strategy-only-required-field [IN] OBSERVATION

spec.strategy is the only required field in a Build or BuildConfig .spec

build-system-openshift-native-duality [IN] DERIVED

OpenShift maintains two coexisting build systems (Shipwright and BuildConfig), both of which are OpenShift-native with no upstream Kubernetes equivalents, and both tightly coupled to ImageStreams — another OpenShift-native concept — creating an OpenShift-specific build-to-image pipeline that diverges entirely from vanilla Kubernetes patterns.

build-triggers-webhook-imagechange-manual [IN] OBSERVATION

BuildConfig can be triggered by webhooks, base image changes, or manual requests.

build-trusted-ca-key-ca-bundle-crt [IN] OBSERVATION

Trusted CA ConfigMaps for builds must use the key ca-bundle.crt and reside in the openshift-config namespace.

buildah-podman-skopeo-daemonless-rootless [IN] OBSERVATION

buildah, podman, and skopeo are daemonless, rootless container tools preferred over Docker in the OCP ecosystem; they produce OCI-standard images.

buildconfig-api-group [IN] OBSERVATION

BuildConfig uses the API group build.openshift.io/v1.

buildconfig-default-history-limit-5 [IN] OBSERVATION

BuildConfig failedBuildsHistoryLimit and successfulBuildsHistoryLimit default to retaining the 5 most recent builds; removing the field retains all

buildconfig-default-runpolicy-serial [IN] OBSERVATION

BuildConfig default RunPolicy is Serial — builds execute one at a time unless changed

buildconfig-four-build-strategies [IN] OBSERVATION

OpenShift BuildConfig supports four build strategies: Source-to-Image (S2I), Docker, Custom, and Pipeline (deprecated, replaced by Tekton).

buildconfig-openshift-native-not-upstream-k8s [IN] OBSERVATION

BuildConfig is a first-class OpenShift API resource for defining builds; it is not present in upstream Kubernetes.

buildconfig-three-strategies [IN] OBSERVATION

BuildConfig objects support three build strategies: Docker, Source-to-Image (S2I), and custom.

buildconfig-three-trigger-types [IN] OBSERVATION

BuildConfig supports three trigger types: ConfigChange (rebuild on BC edit), ImageChange (rebuild when base image updates), and Webhook (rebuild on git push from GitHub, GitLab, Bitbucket, or generic).

builder-service-account-runs-builds [IN] OBSERVATION

The builder service account runs builds and needs appropriate permissions.

buildlog-cli-command [IN] OBSERVATION

Build logs are retrieved via CLI using oc logs build/<build-name> -n <namespace>

buildlog-compatibility-level-1 [IN] OBSERVATION

BuildLog (build.openshift.io/v1) is Compatibility Level 1, guaranteed stable within a major release for at least 12 months or 3 minor releases

buildlog-is-build-subresource [IN] OBSERVATION

BuildLog is a sub-resource of Build, not an independently created resource — its API endpoint is nested under /apis/build.openshift.io/v1/namespaces/{namespace}/builds/{name}/log

buildrequest-clone-and-instantiate-endpoints [IN] OBSERVATION

BuildRequest clone endpoint is POST /apis/build.openshift.io/v1/namespaces/{namespace}/builds/{name}/clone; instantiate endpoint is POST /apis/build.openshift.io/v1/namespaces/{namespace}/buildconfigs/{name}/instantiate

buildrequest-docker-strategy-build-args [IN] OBSERVATION

dockerStrategyOptions.buildArgs passes Docker ARG values at build request time; sourceStrategyOptions.incremental overrides incremental build setting per-request

buildrequest-four-webhook-types [IN] OBSERVATION

BuildRequest supports four webhook trigger types: GitHub, GitLab, Bitbucket, and Generic

buildrequest-lastversion-optimistic-locking [IN] OBSERVATION

BuildRequest lastVersion field provides optimistic concurrency — if the BuildConfig's version doesn't match, the build won't be generated

buildrequest-triggers-builds [IN] OBSERVATION

BuildRequest is the mechanism behind oc start-build — it is a transient request object (not persistent) used to pass parameters to the build generator

builds-deployments-resolve-to-sha [IN] OBSERVATION

When a build/deployment references an image stream tag, OpenShift resolves it to an exact image SHA at build/deploy time, providing deterministic deployments.

builds-distinct-from-legacy-buildconfig [IN] OBSERVATION

Builds for Red Hat OpenShift is distinct from the legacy OpenShift Build/BuildConfig API (S2I, Docker, Custom strategies) and is a modern replacement/alternative.

builds-operator-is-shipwright [IN] OBSERVATION

Builds for Red Hat OpenShift is the Red Hat productized version of the upstream Shipwright project, installed as a separate operator via OLM.

builds-run-as-pods-subject-to-quotas [IN] OBSERVATION

Builds run as pods in the namespace — they consume cluster resources and are subject to quotas.

builds-uses-tekton-taskruns [IN] OBSERVATION

Builds for Red Hat OpenShift uses Tekton TaskRuns under the hood to execute builds.

bundle-exactly-one-csv [IN] OBSERVATION

An Operator bundle must contain exactly one ClusterServiceVersion (CSV) and at least one channel.

cannot-add-health-checks-to-existing-pod-via-cli [IN] OBSERVATION

You cannot add or edit health checks for an existing pod via the CLI — you must edit the DeploymentConfig object or use the Developer web console.

cannot-modify-br-ex-via-nncp-post-install [IN] OBSERVATION

The br-ex bridge and its interfaces cannot be modified via NodeNetworkConfigurationPolicy after cluster installation.

capacity-aware-scheduling-requires-csidriverspec-opt-in [IN] OBSERVATION

Capacity-aware scheduling must be explicitly enabled via CSIDriverSpec.StorageCapacity on the CSI driver.

catalog-priority-higher-wins [IN] OBSERVATION

When the same package exists in multiple CatalogSources, higher spec.priority value wins (default is 0)

catalogsource-default-namespace-marketplace [IN] OBSERVATION

CatalogSources are typically created in the openshift-marketplace namespace

catalogsource-grpc-image-overrides-address [IN] OBSERVATION

For grpc CatalogSources, the image field takes precedence over address — if both are set, address is ignored

catalogsource-grpc-image-standard [IN] OBSERVATION

CatalogSource spec.sourceType: grpc with spec.image is the standard way to add custom operator catalogs

catalogsource-priority-higher-wins [IN] OBSERVATION

CatalogSource priority field (int32, default 0) controls dependency resolution preference — higher value wins; ties broken lexicographically by name

catalogsource-securitycontextconfig-values [IN] OBSERVATION

CatalogSource grpcPodConfig.securityContextConfig accepts legacy or restricted values; use legacy for older catalog images that cannot run non-root

catalogsource-sourcetype-required-field [IN] OBSERVATION

sourceType is the only required spec field for CatalogSource (operators.coreos.com/v1alpha1); valid types are grpc and configmap

catalogsource-types-grpc-configmap [IN] OBSERVATION

CatalogSources can be of type grpc (index image) or configmap.

catalogsources-live-in-openshift-marketplace [IN] OBSERVATION

Default CatalogSources are located in the openshift-marketplace namespace.

cco-credentials-mode-four-values [IN] OBSERVATION

The Cloud Credential Operator (CCO) credentialsMode field supports four values: "" (Default), "Mint", "Passthrough", and "Manual".

cco-credentials-mode-install-config [IN] OBSERVATION

The Cloud Credential Operator mode is set via credentialsMode in install-config.yaml.

cco-default-mode-probes-credentials [IN] OBSERVATION

CCO Default mode ("") dynamically probes the root credential's capabilities and is only supported on AWS, Azure, and GCP.

cco-manual-mode-for-sts-workload-identity [IN] OBSERVATION

CCO Manual mode is required for short-lived token approaches such as AWS STS, GCP Workload Identity, and Azure Managed Identity.

cco-manual-mode-upgrade-reconciliation [IN] OBSERVATION

When CCO is in Manual mode, cloud credentials must be manually reconciled with every cluster upgrade.

cco-non-aws-azure-gcp-passthrough-only [IN] OBSERVATION

Non-AWS/Azure/GCP platforms only support "Passthrough" credential mode in the Cloud Credential Operator.

cco-upgradable-false-manual-credentials [IN] OBSERVATION

The Cloud Credential Operator Upgradable status defaults to False for clusters with manually maintained credentials; z-stream updates are not blocked but minor version updates are.

ccoctl-aws-delete-separate-from-destroy [IN] OBSERVATION

ccoctl aws delete --name=<name> --region=<region> is a separate cleanup step from openshift-install destroy cluster, removing IAM roles, policies, OIDC provider, and S3 bucket created for STS

ccoctl-linux-only-binary [IN] OBSERVATION

The ccoctl utility is a Linux-only binary that must match the release image architecture of the target cluster.

ccoctl-supported-clouds [IN] OBSERVATION

The ccoctl utility supports cloud subcommands for aws, azure, gcp, ibmcloud, and nutanix.

certmanager-cluster-wide-single-install [IN] OBSERVATION

The cert-manager Operator for Red Hat OpenShift is a cluster-wide service; it must not be installed in multiple namespaces, and the community cert-manager must never run simultaneously with the Red Hat operator.

certmanager-metrics-port-9402 [IN] OBSERVATION

cert-manager webhook and cainjector expose Prometheus metrics on port 9402 at the /metrics endpoint.

certmanager-networkpolicy-disabled-by-default [IN] OBSERVATION

cert-manager NetworkPolicy hardening is disabled by default and must be explicitly enabled in the CertManager CR.

certmanager-seven-issuer-types [IN] OBSERVATION

cert-manager Operator supports seven issuer types: ACME, CA, Self-signed, Vault (fully tested), and Venafi, NCM, Google CAS (partially tested).

certmanager-two-certificate-request-methods [IN] OBSERVATION

cert-manager has two certificate request methods: CertificateRequest (requires admin approval) and Certificate (automatic issuance from a referenced Secret via issuerRef).

check-cco-mode-command [IN] OBSERVATION

The command oc get cloudcredentials cluster -o=jsonpath={.spec.credentialsMode} determines the CCO credential mode.

check-cluster-mtu-command [IN] OBSERVATION

The command to check current cluster network MTU is oc describe network.config cluster.

check-platform-type-command [IN] OBSERVATION

The command to check cluster platform type is oc get infrastructure cluster -o jsonpath='{.status.platform}'.

cicd-strategic-transition-from-jenkins-to-tekton [IN] DERIVED

OpenShift CI/CD is in active strategic transition: Jenkins is deprecated in favor of OpenShift Pipelines (Tekton), but the platform still provides multiple CI/CD solutions simultaneously (Pipelines, GitOps, Shipwright builds) rather than a single integrated pipeline, reflecting a deliberate multi-tool strategy during the transition period

cli-ga-tier1-tp-tier3-dp-tier4 [IN] OBSERVATION

GA CLI flags/commands are Tier 1; Tech Preview CLI elements are Tier 3; Developer Preview CLI elements are Tier 4.

cli-manager-custom-index-url-pattern [IN] OBSERVATION

The CLI Manager custom Krew index URL pattern is https://$ROUTE/cli-manager.

cli-manager-namespace [IN] OBSERVATION

The CLI Manager Operator requires the namespace openshift-cli-manager-operator.

cli-manager-operator-tech-preview [IN] OBSERVATION

The CLI Manager Operator is a Technology Preview feature, not supported for production use.

cli-manager-plugin-api [IN] OBSERVATION

CLI Manager plugins are defined as custom resources with API group config.openshift.io/v1alpha1, kind Plugin.

cloud-private-ip-config-admin-changes-overwritten [IN] OBSERVATION

CloudPrivateIPConfig is internally managed by the network plugin; manual changes by cluster-admins are overwritten on the next reconciliation cycle

cloud-private-ip-config-egressip-mechanism [IN] OBSERVATION

CloudPrivateIPConfig (cloud.network.openshift.io/v1) is the underlying implementation mechanism for EgressIP on cloud platforms

cloud-private-ip-config-name-is-ip [IN] OBSERVATION

CloudPrivateIPConfig CR name must be the requested private IP address itself, and it supports both IPv4 and IPv6

cloudcredential-resource-cluster-scoped-named-cluster [IN] OBSERVATION

The CloudCredential resource is cluster-scoped (not namespaced) and is typically named cluster.

cluster-admin-required-operatorhub-install [IN] OBSERVATION

cluster-admin role is required to install Operators from OperatorHub

cluster-api-cannot-manage-control-plane [IN] OBSERVATION

The Cluster API cannot manage control plane machines — only compute machines.

cluster-api-ipam-api-group [IN] OBSERVATION

The Cluster API IPAM resources (IPAddress and IPAddressClaim) use the API group ipam.cluster.x-k8s.io/v1beta1 in OpenShift 4.17.

cluster-api-namespace-openshift-cluster-api [IN] OBSERVATION

Cluster API resources live in the openshift-cluster-api namespace, managed by the Cluster CAPI Operator.

cluster-api-requires-techpreviewnoupgrade [IN] OBSERVATION

Enabling Cluster API requires the TechPreviewNoUpgrade feature set, which is irreversible and blocks minor version updates.

cluster-api-supported-providers [IN] OBSERVATION

Cluster API in OCP 4.17 supports AWS, Google Cloud, RHOSP, and VMware vSphere.

cluster-api-tech-preview-417 [IN] OBSERVATION

The Cluster API is a Technology Preview feature in OCP 4.17, providing an alternative to the Machine API for compute machine management.

cluster-api-transition [IN] OBSERVATION

OpenShift is transitioning toward upstream Cluster API (CAPI), which may coexist with or replace the traditional Machine API.

cluster-autoscaler-api-version [IN] OBSERVATION

ClusterAutoscaler uses API version autoscaling.openshift.io/v1; MachineAutoscaler uses autoscaling.openshift.io/v1beta1.

cluster-autoscaler-name-must-be-default [IN] OBSERVATION

The ClusterAutoscaler resource name must be "default" and only one can exist per cluster.

cluster-certs-expire-one-year [IN] OBSERVATION

Cluster certificates expire one year after installation; expired control plane certs are auto-retrieved but CSRs must still be manually approved.

cluster-config-api-group [IN] OBSERVATION

OpenShift cluster configuration resources (APIServer, Infrastructure, Network, OAuth, Proxy, Scheduler, DNS, Authentication, Ingress) are managed via the config.openshift.io/v1 API group.

cluster-id-command [IN] OBSERVATION

Cluster ID is retrieved via oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}'

cluster-id-web-console-location [IN] OBSERVATION

Cluster ID is visible in the web console at Home → Overview → Details → Cluster ID

cluster-level-vs-app-level-backup [IN] OBSERVATION

Cluster-level backup uses etcd snapshots to protect cluster state (API objects, configuration); application-level backup uses OADP/Velero to protect workloads and persistent volumes.

cluster-network-service-network-immutable [IN] OBSERVATION

clusterNetwork, serviceNetwork, and networkType on the Network config are immutable after installation

cluster-networking-spans-discovery-and-data-plane [IN] DERIVED

OpenShift cluster networking operates across two complementary layers: the DNS discovery layer (CoreDNS DaemonSet with deterministic 10th-address allocation and strict forwarding zone rules) and the multi-CNI data plane (OVN-Kubernetes primary + Multus secondary with NAD-based pod attachment) — both must be healthy for workloads to communicate.

cluster-node-tuning-operator-runs-daemonset [IN] OBSERVATION

The cluster-node-tuning-operator distributes Tuned rules to containerized TuneD daemons running as a DaemonSet on every node.

cluster-observability-operator-separate-from-monitoring-stack [IN] OBSERVATION

The Cluster Observability Operator (COO) is a separate, independently installable operator distinct from the built-in OpenShift monitoring stack (Prometheus, Alertmanager).

cluster-operators-managed-by-cvo [IN] OBSERVATION

Cluster Operators are managed by the Cluster Version Operator (CVO), not by OLM. OLM handles optional add-on Operators only.

cluster-resource-override-operator-uses-deployment [IN] OBSERVATION

The Cluster Resource Override Operator now uses a Deployment instead of a DaemonSet, and its pods can be moved to infrastructure nodes.

cluster-resource-quota-selects-by-annotation-or-label [IN] OBSERVATION

ClusterResourceQuota applies quotas across multiple projects selected by annotation (openshift.io/requester) or label selector.

cluster-samples-operator-deprecated-417 [IN] OBSERVATION

The Cluster Samples Operator is deprecated as of OCP 4.17; only existing S2I builder image streams and templates continue receiving updates

cluster-samples-operator-openshift-namespace [IN] OBSERVATION

The Cluster Samples Operator manages sample image streams and templates in the openshift namespace.

cluster-storage-operator-default-sc [IN] OBSERVATION

The Cluster Storage Operator may install a default storage class depending on the platform; this operator-owned class cannot be deleted or modified beyond annotations/labels.

cluster-vs-app-backup-distinction [IN] OBSERVATION

Cluster backup (etcd/control plane) and application backup (OADP/Velero) are distinct procedures in OpenShift.

clusterautoscaler-cluster-scoped [IN] OBSERVATION

ClusterAutoscaler is a cluster-scoped resource (one per cluster) that controls node-level autoscaling.

clusterautoscaler-default-expander-random [IN] OBSERVATION

ClusterAutoscaler default expander is Random; available options are LeastWaste, Priority, and Random

clusterautoscaler-gpu-limit-uses-accelerator-label [IN] OBSERVATION

ClusterAutoscaler GPU limits match GPU type via the cluster-api/accelerator node label

clusterautoscaler-ignore-daemonsets-default-false [IN] OBSERVATION

ClusterAutoscaler ignoreDaemonsetsUtilization defaults to false — DaemonSet pod resources are included in scale-down calculations by default

clusterautoscaler-is-cluster-scoped-singleton [IN] OBSERVATION

ClusterAutoscaler is a cluster-scoped singleton resource that controls cluster-level autoscaling decisions (adding/removing nodes).

clusterautoscaler-limits-cores-nodes-memory-gpu [IN] OBSERVATION

ClusterAutoscaler can set scaling limits on cores, nodes, memory, and GPU, and can be configured to scale up only (not down).

clusterautoscaler-prerequisite-for-machineautoscaler [IN] OBSERVATION

ClusterAutoscaler must exist before MachineAutoscalers can function

clusterautoscaler-scaledown-enabled-required [IN] OBSERVATION

scaleDown.enabled is the only required field under .spec.scaleDown in ClusterAutoscaler

clusterautoscaler-singleton-cluster-scoped [IN] OBSERVATION

ClusterAutoscaler is a cluster-scoped singleton resource — only one instance per cluster, not namespaced

clusterautoscaler-singleton-named-default [IN] OBSERVATION

The ClusterAutoscaler is a singleton resource — it only responds to a resource named default. MachineAutoscaler targets MachineSets.

clusterautoscaler-skip-local-storage-default-true [IN] OBSERVATION

ClusterAutoscaler skipNodesWithLocalStorage defaults to true — nodes with EmptyDir/HostPath pods are protected from scale-down by default

clustercsidriver-name-must-match-csi-driver [IN] OBSERVATION

The ClusterCSIDriver object name must equal the CSI driver name it manages — this is a hard constraint.

clustercsidriver-storageclassstate-values [IN] OBSERVATION

ClusterCSIDriver storageClassState has three values: Managed (default, continuously reconciles), Unmanaged (stops reconciling), and Removed (deletes previously created storage classes).

clusterextension-replaces-subscription-operatorgroup [IN] OBSERVATION

ClusterExtension (olm.operatorframework.io/v1alpha1) is a single cluster-scoped API object that replaces the previous Subscription + OperatorGroup multi-object approach from classic OLM

clusterextension-version-strategies [IN] OBSERVATION

ClusterExtension supports three version strategies: channel (auto-update), exact version (pinned, requires manual CR edit to update), and version range (comparison string like ">1.11.1")

clustergroupupgrade-cr-remediates-policies [IN] OBSERVATION

ClusterGroupUpgrade CRs (via TALM) are used to remediate and roll out policy changes to managed spoke clusters.

clusterlogforwarder-controls-log-destination [IN] OBSERVATION

The ClusterLogForwarder custom resource controls where logs are forwarded/sent.

clusteroperator-shortname-co [IN] OBSERVATION

The oc get clusteroperators command (short name co) lists all cluster operators and their status.

clusteroperator-three-standard-conditions [IN] OBSERVATION

The three standard ClusterOperator condition types are Available, Progressing, and Degraded.

clusteroperator-version-after-rollout [IN] OBSERVATION

An operator reports a new version in its ClusterOperator resource only after it has finished rolling out to all operands, not when the rollout starts.

clusterresourcequota-openshift-specific [IN] OBSERVATION

ClusterResourceQuota is an OpenShift-specific resource (quota.openshift.io/v1), not available in vanilla Kubernetes.

clusterresourcequota-required-fields [IN] OBSERVATION

ClusterResourceQuota spec requires two fields: quota (resource limits) and selector (which projects are affected).

clusterresourcequota-scale-dozens [IN] OBSERVATION

ClusterResourceQuota selectors should target active projects on the scale of dozens — performance degrades with too many actively-creating projects contending on the resource.

clusterresourcequota-selector-both-must-match [IN] OBSERVATION

When a ClusterResourceQuota selector specifies both label and annotation selectors, a project must match both to be subject to the quota.

clusterresourcequota-spans-namespaces [IN] OBSERVATION

ClusterResourceQuota is an OpenShift object that defines resource quotas across multiple namespaces via label or annotation selectors.

clusterrole-aggregation-via-label-selectors [IN] OBSERVATION

ClusterRoles support aggregation rules that dynamically compose permissions by selecting other ClusterRoles via label selectors; built-in roles like admin, edit, and view use this mechanism.

clusterrole-aggregationrule-overwrites-rules [IN] OBSERVATION

When a ClusterRole has an AggregationRule set, direct edits to the rules field are overwritten by the controller — rules become controller-managed.

clusterrole-cluster-scoped-not-namespaced [IN] OBSERVATION

ClusterRole (rbac.authorization.k8s.io/v1) is a cluster-scoped resource — it is not created within a namespace.

clusterrole-empty-apigroups-means-both [IN] OBSERVATION

In an OpenShift PolicyRule, an empty apiGroups field means both Kubernetes and OpenShift API groups are assumed (permits actions in either).

clusterrole-nonresourceurls-only-with-clusterrolebinding [IN] OBSERVATION

The nonResourceURLs field in a ClusterRole PolicyRule only takes effect when the ClusterRole is referenced from a ClusterRoleBinding, not from a namespaced RoleBinding.

clusterrole-openshift-api-group [IN] OBSERVATION

OpenShift has its own ClusterRole API at authorization.openshift.io/v1, distinct from the Kubernetes rbac.authorization.k8s.io/v1 ClusterRole API.

clusterrole-policyrule-verbs-only-required [IN] OBSERVATION

In a ClusterRole PolicyRule, verbs is the only required field.

clusterrolebinding-namespace-on-user-group-is-error [IN] OBSERVATION

Setting the namespace field on a User or Group subject in a ClusterRoleBinding is an error; namespace is only valid for ServiceAccount subjects.

clusterrolebinding-requires-subjects-roleref [IN] OBSERVATION

A ClusterRoleBinding requires both subjects and roleRef fields; userNames and groupNames are legacy backward-compatibility fields that newer clients should not use.

clusterrolebinding-roleref-immutable [IN] OBSERVATION

The roleRef field on a ClusterRoleBinding is required and immutable — to change the referenced role, you must delete and recreate the binding.

clusterrolebinding-subject-serviceaccount-core-apigroup [IN] OBSERVATION

In a ClusterRoleBinding subject, ServiceAccount uses apiGroup "" (core API group), while User and Group use rbac.authorization.k8s.io.

clustertask-deprecated-pipelines-110 [IN] OBSERVATION

ClusterTask functionality is deprecated as of OpenShift Pipelines 1.10 and planned for removal.

clusterversion-architecture-single-to-multi-only [IN] OBSERVATION

The architecture field in ClusterVersion desiredUpdate only supports transitioning from single architecture to Multi; it cannot be reversed.

clusterversion-baseline-capability-default-vcurrent [IN] OBSERVATION

The baselineCapabilitySet in ClusterVersion defaults to vCurrent.

clusterversion-channel-controls-updates [IN] OBSERVATION

The channel field on ClusterVersion controls which update stream the cluster subscribes to (e.g., stable-4.17, fast-4.17, candidate-4.17).

clusterversion-conditional-vs-available-updates [IN] OBSERVATION

availableUpdates are unconditionally recommended; conditionalUpdates are recommended only if the cluster meets specific conditions (evaluated via PromQL).

clusterversion-config-openshift-api [IN] OBSERVATION

ClusterVersion (config.openshift.io/v1) tracks the cluster's current and desired version — key for upgrades.

clusterversion-force-bypasses-verification [IN] OBSERVATION

The force flag on desiredUpdate in ClusterVersion bypasses image verification and upgradeable checks.

clusterversion-history-command [IN] OBSERVATION

ClusterVersion history is viewed with oc describe clusterversions/version or via the web console at Administration → Cluster Settings → Details tab.

clusterversion-history-has-size-limit [IN] OBSERVATION

ClusterVersion history has a size limit — oldest z-stream updates in previous minor versions are pruned first.

clusterversion-history-states [IN] OBSERVATION

ClusterVersion update history entries have state Completed (fully applied) or Partial (not fully applied or failed).

clusterversion-image-overrides-version [IN] OBSERVATION

When image is specified in desiredUpdate on ClusterVersion, the version field is silently ignored.

clusterversion-requires-cluster-admin [IN] OBSERVATION

Querying the ClusterVersion resource requires cluster-admin privileges.

clusterversion-resource-api-group [IN] OBSERVATION

The ClusterVersion resource is in the config.openshift.io/v1 API group with Kind ClusterVersion and is cluster-scoped (no namespace).

clusterversion-single-object-named-version [IN] OBSERVATION

There is only one ClusterVersion object per cluster and its resource name is version.

cmdline-crash-nohz-full-must-match-cpu-isolated [IN] OBSERVATION

The cmdlinecrash nohzfull CPU set must match cpu.isolated in the PerformanceProfile.

cmo-config-via-configmaps [IN] OBSERVATION

The Cluster Monitoring Operator (CMO) is configured via ConfigMaps, not CRDs.

cno-default-cluster-network-cidr [IN] OBSERVATION

Default cluster network CIDR is 10.128.0.0/14 with hostPrefix 23; default service network is 172.30.0.0/16.

cno-gatewayconfig-changeable-post-install [IN] OBSERVATION

The gatewayConfig field is the exception to post-install immutability — it can be changed at runtime.

cno-ip-forwarding-restricted-default-new-installs [IN] OBSERVATION

IP forwarding defaults to Restricted for new OCP 4.14+ installs and Global for upgrades to 4.14+.

cno-ipsec-modes-disabled-external-full [IN] OBSERVATION

IPsec configuration supports three modes: Disabled, External (external traffic only), and Full (pod traffic and external traffic).

cno-namespace-openshift-network-operator [IN] OBSERVATION

The Cluster Network Operator runs in the openshift-network-operator namespace.

cno-object-name-always-cluster [IN] OBSERVATION

The Cluster Network Operator configuration object is always named cluster.

cno-ovn-kubernetes-only-supported-cni [IN] OBSERVATION

OVN-Kubernetes is the only supported network plugin for new OpenShift Container Platform installations.

cno-ovn-kubernetes-uses-geneve-port-6081 [IN] OBSERVATION

OVN-Kubernetes uses Geneve (Generic Network Virtualization Encapsulation) as the overlay network on default port 6081.

cno-post-install-only-clusternetwork-modifiable [IN] OBSERVATION

After installation, only the clusterNetwork IP address range can be modified; serviceNetwork and networkType are read-only.

cnv-based-on-kubevirt [IN] OBSERVATION

OpenShift Virtualization is based on the KubeVirt upstream open-source project

cnv-do-not-create-vms-in-openshift-namespaces [IN] OBSERVATION

VMs should not be created in openshift-* namespaces; use custom namespaces without the openshift prefix

cnv-eus-update-procedure-8-steps [IN] OBSERVATION

EUS-to-EUS update procedure: (1) pause worker MCP, (2) disable workload updates, (3) update OCP to odd version, (4) update OpenShift Virt, (5) update OCP to target EUS, (6) update OpenShift Virt again, (7) re-enable workload updates, (8) unpause MCP

cnv-golden-images-namespace [IN] OBSERVATION

Golden images are stored in the openshift-virtualization-os-images namespace by default, customizable via spec.commonBootImageNamespace in the HyperConverged CR

cnv-guest-serial-console-log-disabled-by-default [IN] OBSERVATION

Guest system serial console log access is disabled by default in OpenShift Virtualization, controlled via spec.virtualMachineOptions.disableSerialConsoleLog in the HyperConverged CR

cnv-hostpath-provisioner-no-live-migrate [IN] OBSERVATION

VMs using hostpath provisioner storage cannot be live migrated; workaround is setting evictionStrategy: None and runStrategy: Always

cnv-installed-via-operatorhub [IN] OBSERVATION

OpenShift Virtualization is installed as an Operator via OperatorHub, not built into the base platform

cnv-instancetype-cpu-memory-required-no-override [IN] OBSERVATION

Instance type cpu and memory are required attributes and cannot be overridden when creating a VM from an instance type

cnv-instancetype-namespaced-vs-cluster [IN] OBSERVATION

VirtualMachineInstancetype is namespaced and VirtualMachineClusterInstancetype is cluster-wide; same pattern for preferences (VirtualMachinePreference vs VirtualMachineClusterPreference)

cnv-instancetype-naming-convention [IN] OBSERVATION

Pre-defined instance type naming convention: <series><version>.<size> (e.g., u1.medium, cx1.2xlarge)

cnv-instancetype-series-definitions [IN] OBSERVATION

Pre-defined instance type series: U (Universal, burstable, 1:4), O (Overcommitted, 1:4), CX (Compute-exclusive, dedicated CPU, 1:2), GN (NVIDIA GPU, 1:4), M (Memory-intensive, 1:8), N (Network-intensive, dedicated CPU, 1:2)

cnv-live-migration-requires-rwx [IN] OBSERVATION

OpenShift Virtualization live migration requires shared storage with RWX (ReadWriteMany) access mode

cnv-livemigrate-default-workload-update-method [IN] OBSERVATION

LiveMigrate is the default and only enabled workload update method for OpenShift Virtualization; Evict must be explicitly added

cnv-log-verbosity-hyperconverged-cr [IN] OBSERVATION

OpenShift Virtualization log verbosity is configured per-component in the HyperConverged CR at spec.logVerbosityConfig.kubevirt with values 1–9

cnv-machine-type-not-auto-changed-on-update [IN] OBSERVATION

VM machineType is not automatically changed during OpenShift Virtualization updates; the VM must be shut down before changing it

cnv-migration-timeout-5min-unschedulable [IN] OBSERVATION

During workload updates, VMI migration times out after 5 minutes if Unschedulable and 15 minutes for any other pending reason

cnv-must-gather-default-parallel-5 [IN] OBSERVATION

The default number of parallel processes for OpenShift Virtualization must-gather is 5, controlled by the PROS environment variable

cnv-must-gather-image [IN] OBSERVATION

The must-gather image for OpenShift Virtualization is registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v<version>

cnv-must-gather-instancetypes-not-default [IN] OBSERVATION

Instance types information is not collected by default with must-gather; it requires the explicit --instancetypes flag

cnv-must-gather-ns-mandatory-with-vm [IN] OBSERVATION

The NS environment variable is mandatory when using the VM variable with must-gather for OpenShift Virtualization

cnv-per-vm-log-overrides-cluster [IN] OBSERVATION

Per-VM guest log settings take precedence over cluster-wide defaults in OpenShift Virtualization

cnv-pods-namespace-openshift-cnv [IN] OBSERVATION

OpenShift Virtualization pods (virt-api, virt-controller, virt-handler, virt-launcher, virt-operator) run in the openshift-cnv namespace

cnv-prometheus-retention-7-days-minimum [IN] OBSERVATION

Prometheus retention should be set to a minimum of 7 days before collecting OpenShift Virtualization support data

cnv-requires-bare-metal-or-nested-virt [IN] OBSERVATION

OpenShift Virtualization requires bare-metal or supported nested-virtualization infrastructure; not supported on all cloud providers without specific enablement

cnv-runstrategy-and-running-mutually-exclusive [IN] OBSERVATION

runStrategy and spec.running are mutually exclusive on a VirtualMachine resource

cnv-runstrategy-values [IN] OBSERVATION

VirtualMachine runStrategy values: Always (restarts if stopped), Halted (VM stopped), RerunOnFailure (restarts only on failure), Manual (manual start/stop via virtctl)

cnv-stable-channel-automatic-approval-recommended [IN] OBSERVATION

The recommended update settings for OpenShift Virtualization are the stable channel with Automatic approval strategy

cnv-update-ocp-first-then-cnv [IN] OBSERVATION

OpenShift Virtualization cannot be updated to the next minor version without first updating OCP to that minor version

cnv-version-must-match-ocp-version [IN] OBSERVATION

OpenShift Virtualization minor version must match the OpenShift Container Platform minor version (e.g., 4.17 on 4.17)

compatibility-level-1-means-12-months-or-3-releases [IN] OBSERVATION

Compatibility Level 1 means an API is stable for at least 12 months or 3 minor releases, whichever is longer

compatibility-level-1-stability [IN] OBSERVATION

Compatibility Level 1 APIs in OpenShift are stable for a minimum of 12 months or 3 minor releases within a major release

compatibility-level-1-stability-guarantee [IN] OBSERVATION

OpenShift Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.

compatibility-level-1-stable [IN] OBSERVATION

Compatibility Level 1 on OpenShift-specific APIs means stable for at least 12 months or 3 minor releases.

compatibility-level-1-stable-12-months [IN] OBSERVATION

Compatibility Level 1 APIs in OpenShift are stable within a major release for at least 12 months or 3 minor releases.

compatibility-level-1-stable-12-months-3-releases [IN] OBSERVATION

Compatibility Level 1 OpenShift APIs are stable within a major release for at least 12 months or 3 minor releases.

compatibility-level-1-stable-12mo-3minor [IN] OBSERVATION

Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.

compatibility-level-definitions [IN] OBSERVATION

Compatibility Level 1 means stable for 12 months or 3 minor releases (whichever is longer); Compatibility Level 2 means stable for 9 months or 3 minor releases.

complete-networking-discovery-data-and-addressing [IN] DERIVED

OpenShift networking is a unified three-layer architecture: DNS discovery (CoreDNS DaemonSet with deterministic IP allocation), multi-CNI data plane (OVN-Kubernetes + Multus for secondary interfaces), and dual-stack IPv4/IPv6 addressing — where the addressing layer imposes platform-specific constraints back onto the data plane.

complete-software-delivery-from-build-to-console [IN] DERIVED

OpenShift provides a unified software delivery model covering both application and operator lifecycles: application images flow through build systems → ImageStreams → registry → deployment, while operators flow through FBC catalogs → OLM chain → CSV → deployment, and both terminate in console UI integration via plugins.

component-route-certs-openshift-config [IN] OBSERVATION

Serving certificate secrets for component routes must be type kubernetes.io/tls in the openshift-config namespace

componentstatus-deprecated-since-k8s-1.19 [IN] OBSERVATION

ComponentStatus is deprecated since Kubernetes v1.19 and remains only for backward compatibility.

componentstatus-deprecated-since-v1-19 [IN] OBSERVATION

ComponentStatus (v1) is deprecated since Kubernetes v1.19.

componentstatus-only-healthy-condition-type [IN] OBSERVATION

The only valid condition type for ComponentStatus is "Healthy", with status values "True", "False", or "Unknown".

componentstatus-read-only-cluster-scoped [IN] OBSERVATION

ComponentStatus is a read-only, cluster-scoped resource with only GET endpoints (no create, update, or delete).

conditional-updates-not-recommended-flag [IN] OBSERVATION

Conditional (not-recommended) updates can be viewed with oc adm upgrade --include-not-recommended and applied with --allow-not-recommended

confidential-containers-use-tee [IN] OBSERVATION

Confidential containers extend sandboxed containers with hardware-level trusted execution environments (TEEs) such as AMD SEV and Intel TDX for data protection.

config-api-23-resources [IN] OBSERVATION

The Config APIs in OpenShift 4.17 contain approximately 23 cluster-wide configuration resources under config.openshift.io/v1 (and helm.openshift.io/v1beta1).

config-api-changes-trigger-operator-reconciliation [IN] OBSERVATION

Changes to Config API resources trigger reconciliation by Cluster Operators

config-api-group-name [IN] OBSERVATION

The primary API group for OpenShift cluster configuration resources is config.openshift.io.

config-api-objects-cluster-scoped [IN] OBSERVATION

Config API objects under config.openshift.io are cluster-scoped (not namespaced) and apply platform-wide.

config-api-objects-examples [IN] OBSERVATION

Config API objects include Infrastructure, Ingress, DNS, Proxy, Network, OAuth, Scheduler, APIServer, and FeatureGate

config-apis-group-config-openshift-io [IN] OBSERVATION

Config API objects in OpenShift live under the config.openshift.io API group and are typically cluster-scoped singletons named cluster

config-drift-marks-node-degraded [IN] OBSERVATION

Configuration drift (when a node's actual config doesn't match its MCP's machine config) causes the MCD to mark the node degraded; the node remains online but cannot be updated.

config-openshift-io-api-group [IN] OBSERVATION

Cluster-wide configuration resources live under the config.openshift.io API group

config-operator-bootstrap-initial-config [IN] OBSERVATION

The Config Operator (operator.openshift.io/v1) is a bootstrap-level operator that creates the initial configuration of other cluster components.

config-operator-cloud-sync-aws-azure-only [IN] OBSERVATION

The Config Operator handles cloud configuration migration and synchronization specifically for AWS and Azure (not all cloud providers).

configmap-binarydata-base64 [IN] OBSERVATION

ConfigMaps use the binaryData field for non-UTF8 content, stored as Base64-encoded values.

configmap-binarydata-requires-v1.10 [IN] OBSERVATION

ConfigMap binaryData field requires apiserver and kubelet v1.10 or later.

configmap-data-binarydata-keys-must-not-overlap [IN] OBSERVATION

Keys in a ConfigMap's data and binaryData fields must not overlap; this is enforced at validation.

configmap-envfrom-injects-all-keys [IN] OBSERVATION

Using envFrom with configMapRef injects all keys from a ConfigMap as environment variables, while env with configMapKeyRef injects individual keys.

configmap-immutable-prevents-data-updates [IN] OBSERVATION

Setting immutable: true on a ConfigMap prevents updates to data and binaryData; the ConfigMap must be deleted and recreated to change data.

configmap-key-naming-rules [IN] OBSERVATION

ConfigMap keys must contain only alphanumeric characters, -, _, or ..

configmap-must-exist-before-pod [IN] OBSERVATION

ConfigMaps must be created before pods that reference them, unless the reference is marked optional: true.

configmap-namespace-scoped [IN] OBSERVATION

ConfigMaps in OpenShift/Kubernetes are namespace-scoped and can only be referenced by pods in the same project.

configmap-no-encryption [IN] OBSERVATION

ConfigMaps do not provide encryption; Secrets should be used for sensitive data.

configmap-only-api-created-pods [IN] OBSERVATION

Only pods created via the API server (CLI, replication controllers) can use ConfigMaps — not pods from --manifest-url, --config flag, or node REST API.

configmap-volume-mount-keys-as-files [IN] OBSERVATION

When a ConfigMap is mounted as a volume, each key becomes a filename and each value becomes the file content.

connected-cluster-definition [IN] OBSERVATION

A "connected cluster" is one that reports data to Red Hat via Telemetry and the Insights Operator

console-api-changes-dynamic-no-restart [IN] OBSERVATION

Console API CRD changes are picked up dynamically — no console restart is needed

console-api-compatibility-level-1-resources [IN] OBSERVATION

ConsolePlugin and ConsoleSample have Compatibility Level 1 (stable 12 months or 3 minor releases)

console-api-compatibility-level-2-duration [IN] OBSERVATION

Console API resources at Compatibility Level 2 are stable for a minimum of 9 months or 3 minor releases within a major release

console-api-eight-crds [IN] OBSERVATION

Eight Console API CRDs exist: ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample

console-api-group-config-openshift-io [IN] OBSERVATION

The Console config API group is config.openshift.io/v1, not console.openshift.io.

console-api-group-resources [IN] OBSERVATION

The console.openshift.io/v1 API group includes ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample, ConsoleLink, ConsoleExternalLogLink, and ConsoleCLIDownload resources.

console-api-href-requires-https [IN] OBSERVATION

All Console API resources that accept URLs (ConsoleLink, ConsoleCLIDownload, ConsoleExternalLogLink) require HTTPS — HTTP URLs are not allowed

console-api-resource-types [IN] OBSERVATION

Console API resource types include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, and ConsoleYAMLSample

console-api-resources-list [IN] OBSERVATION

Key Console API resources include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, and ConsoleYAMLSample

console-apis-api-group [IN] OBSERVATION

All Console API custom resources belong to the console.openshift.io/v1 API group

console-apis-group-console-openshift-io [IN] OBSERVATION

Console API resources belong to the console.openshift.io/v1 API group and are OpenShift-specific (not in upstream Kubernetes)

console-apis-openshift-specific [IN] OBSERVATION

Console APIs are OpenShift-specific and do not exist in upstream Kubernetes

console-config-singleton-named-cluster [IN] OBSERVATION

The Console resource (config.openshift.io/v1) is a cluster-scoped singleton always named cluster.

console-custom-logo-configmap-openshift-config [IN] OBSERVATION

Custom console logos are stored in a ConfigMap in the openshift-config namespace, not in the operator spec directly.

console-custom-route-secret-keys [IN] OBSERVATION

Custom console route TLS secrets must contain keys tls.crt and tls.key and be stored in the openshift-config namespace.

console-customization-resources [IN] OBSERVATION

Console customization uses resources ConsoleLink, ConsoleNotification, and ConsoleCLIDownload along with the Console operator config (operator.openshift.io/v1)

console-default-kubeadmin-user [IN] OBSERVATION

The default administrative user after installation is kubeadmin with a generated password stored in auth/kubeadmin-password

console-default-url-pattern [IN] OBSERVATION

The default console route follows the pattern https://console-openshift-console.apps.<cluster_domain>

console-deployment-namespace [IN] OBSERVATION

The web console is served by the console-openshift-console deployment in the openshift-console namespace

console-logout-redirect-required-for-sso [IN] OBSERVATION

The spec.authentication.logoutRedirect field on the Console config is required when using SSO identity providers (OpenID, RequestHeader, OAuth) to enable single logout (SLO).

console-openshift-io-v1-tier2 [IN] OBSERVATION

console.openshift.io/v1 is Tier 2, not Tier 1.

console-operator-optional [IN] OBSERVATION

The Console Operator can be disabled without affecting cluster supportability or upgradeability.

console-operator-singleton-named-cluster [IN] OBSERVATION

The Console operator resource is a singleton cluster-scoped resource named cluster.

console-perspective-visibility-states [IN] OBSERVATION

Console perspective visibility can be set to Enabled, Disabled, or AccessReview (gated on RBAC access review checks).

console-plugin-integration-model [IN] DERIVED

Console extensibility follows a defined model: plugins must use HTTPS backends, register via OLM, respect the singleton Console config resource, and maintain Level 1 API stability.

console-plugins-enabled-via-spec-plugins-array [IN] OBSERVATION

Console plugins are enabled by adding their name to the spec.plugins array on the Console operator resource.

console-plugins-registered-via-olm [IN] OBSERVATION

Operator bundles can declare ConsolePlugin resources to register UI extensions through OLM integration

console-runs-on-control-plane [IN] OBSERVATION

The web console runs as pods on control plane nodes in the openshift-console project, managed by the console-operator pod

console-spec-route-deprecated-use-ingress [IN] OBSERVATION

The Console operator spec.route field is deprecated; spec.ingress is the modern alternative for custom console URLs.

console-two-perspectives [IN] OBSERVATION

The web console has two main perspectives: Administrator and Developer, each tailored to different user roles

console-url-from-status-not-configurable [IN] OBSERVATION

The console URL is found in status.consoleURL and is derived from the console route — it is not user-configurable.

console-url-retrieve-command [IN] OBSERVATION

The web console URL can be retrieved with oc whoami --show-console

consoleclidownload-cluster-scoped [IN] OBSERVATION

ConsoleCLIDownload is a cluster-scoped resource (no namespace) used to register CLI tool download links in the web console

consoleclidownload-links-require-https [IN] OBSERVATION

ConsoleCLIDownload link href values must use HTTPS (absolute secure URLs)

consoleclidownload-required-fields [IN] OBSERVATION

ConsoleCLIDownload requires three spec fields: description, displayName, and links

consoleexternalloglink-namespace-filter-js-regex [IN] OBSERVATION

ConsoleExternalLogLink namespaceFilter uses JavaScript RegExp syntax (not Go or POSIX regex)

consoleexternalloglink-pod-logs-tab [IN] OBSERVATION

ConsoleExternalLogLink links appear on the Logs tab of the pod details page in the web console

consoleexternalloglink-template-variables [IN] OBSERVATION

ConsoleExternalLogLink hrefTemplate supports variables: ${resourceName}, ${resourceUID}, ${containerName}, ${resourceNamespace}, ${resourceNamespaceUID}, and ${podLabels} (JSON-encoded)

consolelink-applicationmenu-section-required [IN] OBSERVATION

When ConsoleLink location is ApplicationMenu, the applicationMenu.section field is required to determine the menu grouping

consolelink-cluster-scoped [IN] OBSERVATION

ConsoleLink is a cluster-scoped resource, even when targeting specific namespace dashboards

consolelink-four-locations [IN] OBSERVATION

ConsoleLink supports four valid location values: ApplicationMenu, HelpMenu, UserMenu, NamespaceDashboard

consolelink-namespacedashboard-default-all [IN] OBSERVATION

When ConsoleLink location is NamespaceDashboard and no namespaceDashboard filter is specified, the link appears in all namespaces

consolelink-scopes-cluster-namespace-appmenu [IN] OBSERVATION

ConsoleLink can add links at three scopes: cluster-level, namespace-level, or application menu

consolenotification-cluster-scoped [IN] OBSERVATION

ConsoleNotification is a cluster-scoped custom resource (no namespace required) in the console.openshift.io/v1 API group.

consolenotification-compat-level-2 [IN] OBSERVATION

ConsoleNotification has Compatibility Level 2: stable within a major release for at least 9 months or 3 minor releases.

consolenotification-link-href-https [IN] OBSERVATION

ConsoleNotification link href must be an absolute secure URL (HTTPS).

consolenotification-location-values [IN] OBSERVATION

ConsoleNotification valid location values are exactly three: BannerTop, BannerBottom, BannerTopBottom.

consolenotification-text-only-required-field [IN] OBSERVATION

The only required field in the ConsoleNotification spec is text.

consoleplugin-backend-must-use-https [IN] OBSERVATION

ConsolePlugin backend services must use HTTPS with service serving certificates.

consoleplugin-compat-level-1 [IN] OBSERVATION

ConsolePlugin has Compatibility Level 1: stable for at least 12 months or 3 minor releases within a major release.

consoleplugin-cr-api-group [IN] OBSERVATION

The ConsolePlugin custom resource uses API group console.openshift.io/v1 to register dynamic plugins with the web console

consoleplugin-displayname-required-1-128-chars [IN] OBSERVATION

ConsolePlugin displayName is required and must be 1-128 characters.

consoleplugin-dynamic-plugins-ga [IN] OBSERVATION

ConsolePlugin is the primary mechanism for extending the web console with dynamic plugins, introduced in OCP 4.10+ and GA in 4.12+

consoleplugin-extends-console-dynamically [IN] OBSERVATION

ConsolePlugin dynamically loads code from an in-cluster service to extend the OpenShift web console

consoleplugin-i18n-loadtype-values [IN] OBSERVATION

ConsolePlugin localization loadType values are Preload, Lazy, or empty string (defaults to Lazy).

consoleplugin-only-service-backend-type [IN] OBSERVATION

ConsolePlugin only supports Service as a backend type.

consoleplugin-primary-web-console-extension [IN] OBSERVATION

The ConsolePlugin resource is the primary mechanism for extending the OpenShift web console with dynamic plugins (OCP 4.12+)

consoleplugin-proxy-url-pattern [IN] OBSERVATION

ConsolePlugin proxy URL pattern is /api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>.

consolequickstart-access-review-hides [IN] OBSERVATION

ConsoleQuickStart quick starts are hidden (not just disabled) when accessReviewResources checks fail.

consolequickstart-cluster-scoped [IN] OBSERVATION

ConsoleQuickStart is a cluster-scoped resource in the console.openshift.io/v1 API group.

consolequickstart-compat-level-2 [IN] OBSERVATION

ConsoleQuickStart has Compatibility Level 2: stable for 9 months or 3 minor releases within a major release.

consolequickstart-required-spec-fields [IN] OBSERVATION

ConsoleQuickStart required spec fields are description, displayName, durationMinutes, introduction, and tasks.

consolesample-compat-level-1 [IN] OBSERVATION

ConsoleSample has Compatibility Level 1: stable for at least 12 months or 3 minor releases.

consolesample-default-port-8080 [IN] OBSERVATION

ConsoleSample default HTTP service port is 8080 unless overridden via targetPort.

consolesample-git-public-repos-only [IN] OBSERVATION

ConsoleSample Git imports are limited to public repositories on GitHub, GitLab, and Bitbucket only.

consolesample-required-spec-fields [IN] OBSERVATION

ConsoleSample required spec fields are abstract, description, source, and title.

consolesample-two-source-types [IN] OBSERVATION

ConsoleSample supports two source types: GitImport (from a Git repo) and ContainerImport (from a container image).

consoleyamlsample-cluster-scoped [IN] OBSERVATION

ConsoleYAMLSample is a cluster-scoped resource in the console.openshift.io/v1 API group.

consoleyamlsample-required-spec-fields [IN] OBSERVATION

ConsoleYAMLSample required spec fields are description, targetResource, title, and yaml.

consoleyamlsample-snippet-boolean [IN] OBSERVATION

ConsoleYAMLSample snippet boolean field distinguishes between complete resource definitions (false) and insertable fragments (true) in the web console editor.

container-image-version-must-match-ocp [IN] OBSERVATION

Container image versions must match the OCP version — newer container images are not backward compatible with earlier OCP versions.

container-logging-stdout [IN] OBSERVATION

All container logging in OpenShift should go to stdout for collection by the centralized logging system

container-runtime-required-on-nodes [IN] OBSERVATION

A container runtime must be installed on each node for pods to run.

container-runtime-search-registries-pod-specs-only [IN] OBSERVATION

containerRuntimeSearchRegistries works only with Podman and CRI-O, and only in pod specs (not builds or image streams)

container-security-operator-namespace [IN] OBSERVATION

The Container Security Operator is installed in the openshift-operators namespace by default.

container-security-operator-queries-registry [IN] OBSERVATION

The Container Security Operator does not scan images itself — it queries the source container registry (which must run Clair scanning) for vulnerability information.

containerruntimeconfig-api-group [IN] OBSERVATION

ContainerRuntimeConfig belongs to API group machineconfiguration.openshift.io/v1 and is a cluster-scoped resource.

containerruntimeconfig-configures-crio [IN] OBSERVATION

ContainerRuntimeConfig is the declarative, supported approach to customize CRI-O settings on cluster nodes without writing raw MachineConfig resources.

containerruntimeconfig-default-overlaysize-10gb [IN] OBSERVATION

ContainerRuntimeConfig default overlaySize (max container image size) is 10GB.

containerruntimeconfig-for-crio [IN] OBSERVATION

ContainerRuntimeConfig is the dedicated CR for managing CRI-O container runtime settings (e.g., pidslimit, logsize_max), separate from MachineConfig.

containerruntimeconfig-loglevel-values [IN] OBSERVATION

ContainerRuntimeConfig valid logLevel values are: fatal, panic, error, warn, info, debug.

containerruntimeconfig-logsizemax-min-8192 [IN] OBSERVATION

ContainerRuntimeConfig logSizeMax must be >= 8192 if set to a positive value (to match conmon's read buffer); negative values mean no limit.

containerruntimeconfig-nil-selector-selects-no-pools [IN] OBSERVATION

A nil machineConfigPoolSelector in ContainerRuntimeConfig selects no pools — you must explicitly label-match to apply the config.

containerruntimeconfig-pidslimit [IN] OBSERVATION

ContainerRuntimeConfig pidsLimit parameter controls per-container process limits for workload isolation and security.

control-plane-machine-delete-requires-cpms [IN] OBSERVATION

Control plane machines must not be deleted unless the cluster uses a control plane machine set (CPMS).

control-plane-not-managed-by-compute-machinesets [IN] OBSERVATION

Control plane machines cannot be managed by compute machine sets; they require control plane machine sets instead.

control-plane-not-scaled-via-machinesets [IN] OBSERVATION

Control plane machines are not scaled via MachineSets; they are managed by the ControlPlaneMachineSet.

control-plane-static-pod-operators [IN] OBSERVATION

KubeAPIServer, KubeControllerManager, and KubeScheduler operators all use the same revision-based static pod deployment model on control plane nodes

control-plane-vs-worker-nodes [IN] OBSERVATION

Control plane nodes run the API server, etcd, and controllers; worker nodes run application workloads.

controllerconfig-additional-trust-bundle [IN] OBSERVATION

The additionalTrustBundle field in ControllerConfig propagates custom CA certificates to all node trust stores (e.g., for proxied environments or private registries).

controllerconfig-api-group [IN] OBSERVATION

The ControllerConfig resource belongs to the machineconfiguration.openshift.io/v1 API group and is cluster-scoped.

controllerconfig-base-os-container-image-replaces-osimageurl [IN] OBSERVATION

The baseOSContainerImage field is the required new-format OS update image in ControllerConfig; osImageURL is deprecated.

controllerconfig-deprecated-fields [IN] OBSERVATION

ControllerConfig deprecated fields: etcdDiscoveryDomain (use Infra.Status.EtcdDiscoveryDomain), platform (use Infra.Status.PlatformStatus.Type), osImageURL (use baseOSContainerImage).

controllerconfig-required-spec-fields [IN] OBSERVATION

ControllerConfig required spec fields are: baseOSContainerImage, cloudProviderConfig, clusterDNSIP, images, ipFamilies, kubeAPIServerServingCAData, releaseImage, rootCAData.

controllerrevision-apps-v1-namespaced [IN] OBSERVATION

ControllerRevision is in the apps/v1 API group and is a namespaced resource.

controllerrevision-data-immutable-after-creation [IN] OBSERVATION

ControllerRevision's data field is immutable after creation; the API server rejects mutation attempts.

controllerrevision-immutable-after-creation [IN] OBSERVATION

ControllerRevision (apps/v1) is immutable after creation — the API server rejects mutations to the Data field. Used by DaemonSet and StatefulSet controllers for update and rollback.

controllerrevision-revision-required-field [IN] OBSERVATION

The revision field (integer) is the only required field on a ControllerRevision.

controllerrevision-used-by-daemonset-statefulset [IN] OBSERVATION

ControllerRevisions are used by DaemonSet and StatefulSet controllers for update/rollback; Deployments use ReplicaSets for revision tracking instead.

coo-has-custom-crds [IN] OBSERVATION

The Cluster Observability Operator introduces its own custom resources (CRDs) and API surface for managing observability configuration.

coo-independent-versioning [IN] OBSERVATION

The Cluster Observability Operator has its own independent versioning separate from the OpenShift platform version.

coo-installed-via-olm [IN] OBSERVATION

The Cluster Observability Operator is installed via OLM (Operator Lifecycle Manager) through OperatorHub.

coo-manages-observability [IN] OBSERVATION

The Cluster Observability Operator (COO) is the central operator for configuring and managing observability features on OCP 4.20+.

coo-provides-ui-plugins [IN] OBSERVATION

The Cluster Observability Operator provides UI plugins that extend the OpenShift web console with observability dashboards and views.

coo-separate-from-cmo [IN] OBSERVATION

The Cluster Observability Operator (COO) is a separate, optional operator from the built-in Cluster Monitoring Operator (CMO) and is not part of the default OpenShift installation.

coo-separate-operator-from-monitoring-stack [IN] OBSERVATION

The Cluster Observability Operator (COO) is a separate operator that must be explicitly installed; it is not part of the default OpenShift monitoring stack.

coo-separately-installed-operator [IN] OBSERVATION

The Cluster Observability Operator (COO) is a separately installable operator, not part of the default OpenShift cluster monitoring stack.

coo-supports-ui-plugins [IN] OBSERVATION

The Cluster Observability Operator supports UI plugins that extend the OpenShift web console with observability views and dashboards.

core-v1-resources-no-group-prefix [IN] OBSERVATION

Core v1 resources (Pod, Service, ConfigMap, Secret, Namespace, Node, PV, PVC) have no API group prefix.

cors-apiserver-config-resource [IN] OBSERVATION

CORS additional allowed origins are configured on the apiserver.config.openshift.io/cluster resource via spec.additionalCORSAllowedOrigins, which accepts a list of Golang regular expressions.

cors-applies-api-and-oauth [IN] OBSERVATION

The additionalCORSAllowedOrigins setting applies to both the API server and the OAuth server.

cors-default-only-web-console [IN] OBSERVATION

By default, only the OpenShift web console hostname is allowed to make cross-origin JavaScript requests to the API server.

cpms-active-cannot-be-made-inactive [IN] OBSERVATION

Once a ControlPlaneMachineSet state is set to Active, it cannot be made Inactive — the resource must be deleted instead.

cpms-api-version-v1 [IN] OBSERVATION

The ControlPlaneMachineSet API is machine.openshift.io/v1, while the Machines it manages are machine.openshift.io/v1beta1.

cpms-failure-domain-platforms [IN] OBSERVATION

ControlPlaneMachineSet failure domains are supported on AWS, Azure, GCP, OpenStack, vSphere, and Nutanix.

cpms-lifecycle-hooks [IN] OBSERVATION

ControlPlaneMachineSet lifecycle hooks: preDrain blocks draining and all subsequent events; preTerminate blocks termination only (actioned after drain completes).

cpms-replicas-immutable-3-or-5 [IN] OBSERVATION

ControlPlaneMachineSet replicas field is immutable after cluster installation and only supports values of 3 or 5.

cpms-selector-immutable [IN] OBSERVATION

The ControlPlaneMachineSet selector is immutable after creation and must match template labels.

cpms-strategy-types [IN] OBSERVATION

ControlPlaneMachineSet supports two update strategy types: RollingUpdate (default) and OnDelete.

cpu-limits-throttle-memory-limits-oom [IN] OBSERVATION

CPU limits are enforced via throttling (pods are NOT terminated for exceeding CPU); memory limits are enforced via kernel OOM kill.

cpu-manager-default-policy-none [IN] OBSERVATION

CPU Manager default policy is none, which uses shared CFS quota scheduling.

cpu-manager-static-requires-guaranteed-integer [IN] OBSERVATION

CPU Manager static policy grants exclusive CPUs only to Guaranteed QoS pods with integer CPU requests; fractional CPU pods fall back to the shared pool.

cpu-partitioning-install-time-only [IN] OBSERVATION

Workload partitioning (cpuPartitioningMode: AllNodes) can only be enabled at OpenShift install time and cannot be enabled later.

crd-additional-printer-columns-requires-name-type-jsonpath [IN] OBSERVATION

CRD additionalPrinterColumns requires name, type, and jsonPath fields to customize kubectl get table output.

crd-conversion-strategies-none-or-webhook [IN] OBSERVATION

CRD conversion strategies are None (only changes apiVersion) or Webhook (calls external webhook); webhook requires preserveUnknownFields: false.

crd-exactly-one-storage-version [IN] OBSERVATION

Exactly one CRD version must have storage: true; this is the version used when persisting to etcd.

crd-max-8-selectable-fields [IN] OBSERVATION

CRDs allow a maximum of 8 selectable fields per version, which must be string, boolean, or integer types.

crd-name-format-plural-dot-group [IN] OBSERVATION

CRD name must follow the format <plural>.<group> (e.g., crontabs.stable.example.com); this is enforced.

crd-scope-cluster-or-namespaced [IN] OBSERVATION

CRD scope can only be Cluster or Namespaced.

crd-status-subresource-separates-spec-status [IN] OBSERVATION

The CRD status subresource ensures PUT/POST/PATCH to the main resource ignores .status changes, and PUT to /status ignores everything except .status.

credentials-mode-required-with-scps [IN] OBSERVATION

When AWS account has SCPs (Service Control Policies) enabled, credentialsMode must be explicitly set to Mint, Passthrough, or Manual in install-config.yaml.

credentialsrequest-openshift-cloud-credentials [IN] OBSERVATION

CredentialsRequest (cloudcredential.openshift.io/v1) is an OpenShift-specific CRD for managing cloud provider credentials, connected to the Cloud Credential Operator (CCO)

cri-o-only-container-engine [IN] OBSERVATION

CRI-O is the only container engine in OpenShift clusters (not Docker); it can use runC or crun as the container runtime.

cri-o-runs-on-every-ocp-node [IN] OBSERVATION

CRI-O is the container engine running on every worker and control plane node in OpenShift Container Platform clusters.

crio-container-runtime-on-ocp [IN] OBSERVATION

CRI-O (not Docker) is the container runtime engine on all OpenShift Container Platform cluster nodes.

crio-supports-multiple-runtimes [IN] OBSERVATION

CRI-O supports multiple OCI runtimes including runc (default) and kata, allowing per-workload runtime selection.

cronjob-backoff-limit-default-6 [IN] OBSERVATION

Job backoffLimit defaults to 6 retries before marking a Job as failed

cronjob-batch-v1-api-group [IN] OBSERVATION

CronJob is batch/v1 (fully GA since Kubernetes 1.21 / OCP 4.8+), not batch/v1beta1

cronjob-concurrency-policy-default-allow [IN] OBSERVATION

CronJob concurrencyPolicy defaults to Allow; other values are Forbid (skip if previous running) and Replace (cancel running and start new)

cronjob-concurrency-policy-values [IN] OBSERVATION

CronJob concurrencyPolicy accepts three values: Allow (default), Forbid, or Replace.

cronjob-history-defaults-3-success-1-failed [IN] OBSERVATION

CronJob history limits default to 3 successful jobs (successfulJobsHistoryLimit) and 1 failed job (failedJobsHistoryLimit).

cronjob-history-limits-defaults [IN] OBSERVATION

CronJob failedJobsHistoryLimit defaults to 1; successfulJobsHistoryLimit defaults to 3

cronjob-suspend-does-not-stop-running-jobs [IN] OBSERVATION

Setting suspend: true on a CronJob prevents new Jobs from being created but does NOT stop already-running Jobs

cronjob-timezone-iana [IN] OBSERVATION

CronJob timeZone field uses IANA tz database names; if the timezone becomes invalid, the controller stops creating Jobs and emits an UnknownTimeZone event

cronjob-ttl-zero-immediate-deletion [IN] OBSERVATION

ttlSecondsAfterFinished: 0 means the Job is eligible for deletion immediately after finishing

cronjobs-must-be-idempotent [IN] OBSERVATION

CronJobs may fail to create a job or create duplicates, so jobs must be idempotent.

cross-project-image-pull-role [IN] OBSERVATION

Cross-project image access is granted by binding system:image-puller role to system:serviceaccount:<project>:<sa> in the target namespace.

csi-communication-unix-domain-sockets [IN] OBSERVATION

CSI controller containers and driver containers communicate via UNIX Domain Sockets — no CSI traffic leaves the pod.

csi-controller-five-containers [IN] OBSERVATION

The external CSI controller is a Deployment with 5 containers: snapshotter, resizer, attacher, provisioner, and the CSI driver itself.

csi-controllers-run-on-infra-nodes [IN] OBSERVATION

CSI controller pods should run on infrastructure nodes to protect storage credentials.

csi-ephemeral-no-label-defaults-privileged [IN] OBSERVATION

Without the security.openshift.io/csi-ephemeral-volume-profile label on a CSIDriver, the driver defaults to privileged profile, meaning ephemeral volumes only work in privileged namespaces.

csi-inline-ephemeral-supported-drivers [IN] OBSERVATION

CSI inline ephemeral volumes are supported only by Shared Resource, Azure File, and Secrets Store CSI drivers.

csi-migration-versions [IN] OBSERVATION

CSI automatic migration from in-tree plugins: AWS EBS (OCP 4.12+), Azure Disk (4.11+), Azure File (4.13+), GCE PD (4.14+), vSphere (4.14+).

csi-standard-api-replaces-in-tree-plugins [IN] OBSERVATION

CSI (Container Storage Interface) is the standard vendor-agnostic API for storage in OCP, replacing in-tree volume plugins.

csi-storage-capacity-is-namespaced [IN] OBSERVATION

CSIStorageCapacity is a namespaced resource in the storage.k8s.io/v1 API group.

csi-storage-capacity-nodetopology-immutable [IN] OBSERVATION

The nodeTopology field on CSIStorageCapacity is immutable; if unset, storage is inaccessible; if empty, storage is accessible from all nodes.

csi-storage-capacity-storageclassname-required-immutable [IN] OBSERVATION

The storageClassName field on CSIStorageCapacity is required and immutable.

csidriver-attach-required-immutable [IN] OBSERVATION

The attachRequired and volumeLifecycleModes fields on CSIDriver are immutable after creation.

csidriver-cluster-scoped-resource [IN] OBSERVATION

The CSIDriver resource (storage.k8s.io/v1) is a cluster-scoped (non-namespaced) Kubernetes object.

csidriver-default-fsgrouppolicy [IN] OBSERVATION

The default fsGroupPolicy for CSIDriver is ReadWriteOnceWithFSType — fsGroup is only applied when fstype is defined and access mode is ReadWriteOnce.

csidriver-volume-lifecycle-modes [IN] OBSERVATION

CSIDriver supports two volume lifecycle modes: Persistent (default, standard PV/PVC) and Ephemeral (inline volumes tied to pod lifecycle).

csinode-allocatable-count-max-volumes [IN] OBSERVATION

The CSINode allocatable.count field sets the maximum number of unique volumes a node can use for a given CSI driver; if unset, it is unbounded.

csinode-auto-created-by-kubelet [IN] OBSERVATION

CSINode objects are automatically created by the kubelet via the node-driver-registrar sidecar — CSI drivers do not create them directly.

csinode-name-matches-node-name [IN] OBSERVATION

CSINode name must match the Kubernetes node name, and the CSINode has an OwnerReference to the corresponding Node object.

csinode-nodeid-maps-to-storage-system [IN] OBSERVATION

The CSINode nodeID field allows Kubernetes to map its node names to storage system node identifiers (e.g., "node1" in Kubernetes maps to "nodeA" in the storage backend).

csisnapshotcontroller-manages-csi-volume-snapshots [IN] OBSERVATION

The CSISnapshotController operator manages CSI volume snapshot functionality and works with VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent resources.

csisnapshotcontroller-singleton-named-cluster [IN] OBSERVATION

The CSISnapshotController operator resource canonical instance is named cluster in the operator.openshift.io/v1 API group.

csr-three-signer-names [IN] OBSERVATION

CertificateSigningRequests have three signer names: kubernetes.io/kube-apiserver-client-kubelet (kubelet client certs), kubernetes.io/kubelet-serving (kubelet serving TLS certs), and kubernetes.io/kube-apiserver-client (generic API server client certs)

csv-api-group-v1alpha1 [IN] OBSERVATION

The ClusterServiceVersion (CSV) resource belongs to the operators.coreos.com/v1alpha1 API group.

csv-install-strategy-deployment [IN] OBSERVATION

The CSV install strategy type is typically "deployment", with the install spec containing deployments, permissions, and clusterPermissions.

csv-installmodes-four-types [IN] OBSERVATION

CSV installModes supports four types: OwnNamespace, SingleNamespace, MultiNamespace, and AllNamespaces.

csv-rbac-permissions-location [IN] OBSERVATION

RBAC rules are embedded in the CSV under spec.install.spec.permissions (namespace-scoped) and spec.install.spec.clusterPermissions (cluster-scoped).

csv-related-images-must-use-digest [IN] OBSERVATION

The relatedImages field in a CSV must use digest (SHA) references, not tags — important for disconnected/air-gapped environments.

csv-replaces-skips-upgrade-graph [IN] OBSERVATION

The CSV replaces field names the CSV version being replaced (establishing upgrade path), while skips allows skipping intermediate versions in the upgrade graph.

csv-required-spec-fields-displayname-install [IN] OBSERVATION

The required spec fields for a ClusterServiceVersion are displayName and install; the install block requires a strategy field.

csv-status-allnamespaces-copied [IN] OBSERVATION

For AllNamespaces install mode, the CSV status shows Succeeded in openshift-operators and Copied in other namespaces.

csv-succeeded-means-installed [IN] OBSERVATION

A ClusterServiceVersion (CSV) in Succeeded phase means the Operator is installed and running

custom-mcps-inherit-worker [IN] OBSERVATION

Custom MCPs inherit from the worker pool; non-inheriting custom pools are unsupported by the MCO.

custom-metrics-autoscaler-built-on-keda [IN] OBSERVATION

The Custom Metrics Autoscaler Operator is built on KEDA (Kubernetes-based Event Driven Autoscaler) and extends the HPA — it does not replace HPA

custom-metrics-autoscaler-separate-install [IN] OBSERVATION

The Custom Metrics Autoscaler Operator is an optional, separately installed Operator with its own version lifecycle distinct from core OpenShift

custom-project-request-template-configurable [IN] OBSERVATION

Cluster admins can configure a custom project request template to control default resources (quotas, limit ranges, network policies) provisioned with every new project

cvo-applies-manifests-in-runlevels [IN] OBSERVATION

The CVO applies release image manifests in separate stages called Runlevels, proceeding only when all manifests and Operators in the active Runlevel reach a stable condition.

cvo-bootstraps-etcd-operator [IN] OBSERVATION

The Cluster Version Operator (CVO) comes online during bootstrap and installs the etcd Operator and other cluster components

cvo-manages-cluster-operators-olm-manages-addons [IN] OBSERVATION

Two separate Operator management systems exist: the CVO manages cluster Operators (installed by default), and OLM manages add-on Operators (optional, via OperatorHub). OLM does not manage cluster Operators.

daemonset-apps-v1-api-group [IN] OBSERVATION

DaemonSets belong to the apps/v1 API group (not the deprecated extensions group)

daemonset-default-update-strategy-rollingupdate [IN] OBSERVATION

DaemonSet default update strategy is RollingUpdate (not OnDelete); maxSurge defaults to 0, maxUnavailable defaults to 1, and they cannot both be 0

daemonset-pods-never-evicted-by-default [IN] OBSERVATION

DaemonSet pods get default tolerations for unreachable and not-ready with no tolerationSeconds, meaning they are never evicted.

daemonset-requires-disable-default-node-selector [IN] OBSERVATION

DaemonSets require disabling the default project node selector (openshift.io/node-selector: "") on the namespace, or pods will be incorrectly scheduled with frequent recreates.

daemonset-restart-policy-always-only [IN] OBSERVATION

The only allowed restartPolicy for DaemonSet pod templates is "Always"

daemonset-revision-history-limit-default-10 [IN] OBSERVATION

DaemonSet revisionHistoryLimit defaults to 10

daemonset-runs-one-pod-per-node [IN] OBSERVATION

A DaemonSet ensures a Pod runs on every (or selected) node(s) in the cluster.

daemonset-update-does-not-affect-existing-pods [IN] OBSERVATION

Updating a DaemonSet pod template does not affect existing pod replicas — old pods must be deleted manually.

daemonsets-pod-on-every-node [IN] OBSERVATION

DaemonSets ensure a pod runs on every node (or a subset via node labels); used for DNS, monitoring, and similar infrastructure.

daemonsets-run-pod-on-every-node [IN] OBSERVATION

DaemonSets ensure a copy of a Pod runs on all (or selected) nodes, commonly used for node-level agents like logging, monitoring, and networking.

dashboard-five-cards [IN] OBSERVATION

The cluster dashboard has five cards: Details, Cluster Inventory, Status, Cluster Utilization, and Activity

dashboard-home-overview-path [IN] OBSERVATION

The OCP cluster dashboard is accessed at Home → Overview in the web console

dashboard-utilization-five-metrics [IN] OBSERVATION

Cluster Utilization card tracks five metrics: CPU time, memory, storage, network, and pod count

dataimage-bare-metal-only [IN] OBSERVATION

DataImage is specific to bare-metal provisioning and does not apply to cloud-based or virtualized deployments.

dataimage-only-required-field-url [IN] OBSERVATION

The DataImage resource (metal3.io/v1alpha1) has only one required spec field: url, specifying the data image to attach to a BareMetalHost.

dc-no-triggers-adds-configchange [IN] OBSERVATION

If no triggers are defined on a DeploymentConfig, a ConfigChange trigger is added by default; an empty triggers field (triggers: []) means manual-only deployments.

default-catalog-namespace-openshift-marketplace [IN] OBSERVATION

The default catalog source namespace for OperatorHub catalogs is openshift-marketplace.

default-catalog-sources-four-shipped [IN] OBSERVATION

OpenShift ships with four default catalog sources: redhat-operators, certified-operators, community-operators, redhat-marketplace

default-cluster-network-cidr [IN] OBSERVATION

The default cluster network is 10.128.0.0/14 with a /23 host prefix, providing 510 pod IPs per node.

default-clusterroles-list [IN] OBSERVATION

OpenShift ships with default ClusterRoles: admin, edit, view, cluster-admin, and self-provisioner.

default-imagepullpolicy-by-tag [IN] OBSERVATION

Default imagePullPolicy: :latest tag → Always; any other tag → IfNotPresent.

default-max-pods-per-node-250 [IN] OBSERVATION

The default maximum number of pods per node in OpenShift is 250.

default-mcps-master-worker [IN] OBSERVATION

The two default Machine Config Pools are master and worker; custom MCPs for control plane are not supported.

default-pod-eviction-timeout-5-minutes [IN] OBSERVATION

When a node becomes unreachable, pods are scheduled for eviction after 5 minutes by default (tolerationSeconds=300 added automatically).

default-replicas-3-control-3-compute [IN] OBSERVATION

Default control plane replicas are 3 (or 1 for single-node OpenShift); default compute replicas are 3 with a minimum of 2.

default-route-uses-reencrypt [IN] OBSERVATION

Enabling defaultRoute on the Image Registry Operator creates an external route with re-encrypt TLS termination.

default-service-network-cidr [IN] OBSERVATION

The default service network is 172.30.0.0/16.

default-storageclass-annotation [IN] OBSERVATION

The annotation to mark a StorageClass as default is storageclass.kubernetes.io/is-default-class: "true".

degraded-does-not-cause-workload-failure [IN] OBSERVATION

ClusterOperator condition Degraded does not cause workload failure as long as Available is True.

delete-istag-two-methods [IN] OBSERVATION

Image stream tags can be deleted with either oc delete istag/<name>:<tag> or oc tag -d <name>:<tag>.

delete-machine-annotation [IN] OBSERVATION

The annotation machine.openshift.io/delete-machine=true marks a specific machine for priority deletion, overriding the MachineSet deletion policy.

delete-oauthaccesstoken-revokes-session [IN] OBSERVATION

Deleting an OAuthAccessToken (oc delete oauthaccesstoken <name>) effectively revokes a user's session.

delete-operator-order-subscription-then-csv [IN] OBSERVATION

To fully delete an Operator: delete the Subscription first, then delete the CSV; may also need to clean up CRDs and operand resources

delete-user-also-delete-identities [IN] OBSERVATION

When deleting a user, associated Identity objects may also need to be deleted to fully clean up authentication state.

deleting-imagestreamtag-removes-spec-and-status [IN] OBSERVATION

Deleting an ImageStreamTag resource removes both the spec and status entries for that tag.

deployment-favors-availability-dc-favors-consistency [IN] OBSERVATION

In CAP theorem terms, Deployment favors availability (controller manager with leader election); DeploymentConfig favors consistency (deployer pod won't be replaced if node goes down).

deployment-uses-replicasets-dc-uses-rc [IN] OBSERVATION

Deployment objects use ReplicaSets as building blocks; DeploymentConfig objects use ReplicationControllers.

deploymentconfig-deprecated-ocp-414 [IN] OBSERVATION

DeploymentConfig is an OpenShift-specific workload resource deprecated in favor of Kubernetes Deployments starting in OCP 4.14.

deploymentconfig-deprecated-ocp414 [IN] OBSERVATION

DeploymentConfig is deprecated as of OpenShift Container Platform 4.14; Deployment objects should be used for new installations.

deploymentconfig-deprecated-use-deployment [IN] OBSERVATION

DeploymentConfig (apps.openshift.io/v1) is deprecated in favor of Kubernetes Deployments (apps/v1).

deploymentconfig-legacy-apps-openshift [IN] OBSERVATION

DeploymentConfig (apps.openshift.io/v1) is OpenShift-specific and legacy; Deployment (apps/v1) is the standard Kubernetes resource.

deploymentconfig-native-image-triggers [IN] OBSERVATION

DeploymentConfigs and BuildConfigs have image change trigger fields built into their API spec, unlike standard Kubernetes resources which require annotations.

deploymentconfig-openshift-specific [IN] OBSERVATION

DeploymentConfig is an OpenShift-specific resource distinct from Kubernetes Deployment.

deploymentconfig-used-replicationcontrollers [IN] OBSERVATION

OpenShift DeploymentConfig (now deprecated) used ReplicationControllers internally, while Deployments use ReplicaSets.

deploymentconfig-uses-replicationcontrollers [IN] OBSERVATION

DeploymentConfig creates ReplicationControllers for each deployment, whereas Deployment uses ReplicaSets.

deploymentrequest-exclude-triggers [IN] OBSERVATION

DeploymentRequest excludeTriggers field provides fine-grained control over which triggers fire during instantiation, overriding the triggers that latest would otherwise process

deploymentrequest-force-paused-invalid-error [IN] OBSERVATION

You cannot force a deployment on a paused DeploymentConfig — DeploymentRequest returns an Invalid error

deploymentrequest-openshift-specific [IN] OBSERVATION

DeploymentRequest (apps.openshift.io/v1) is OpenShift-specific, not part of upstream Kubernetes; it triggers deployments via the instantiate subresource of DeploymentConfig

deploymentrequest-required-fields [IN] OBSERVATION

DeploymentRequest required fields are name, latest, and force; the endpoint is POST /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/instantiate

descheduler-does-not-schedule-replacements [IN] OBSERVATION

The descheduler only evicts pods; it does not schedule replacement pods — the scheduler handles rescheduling.

descheduler-protected-namespaces [IN] OBSERVATION

The descheduler cannot evict pods in openshift-* or kube-system namespaces, nor static pods, mirror pods, stand-alone pods, or DaemonSet pods.

dev-spaces-based-on-eclipse-che [IN] OBSERVATION

Red Hat OpenShift Dev Spaces is Red Hat's productized, supported distribution of Eclipse Che, providing browser-based containerized development environments on OpenShift.

dev-spaces-own-version-numbering [IN] OBSERVATION

OpenShift Dev Spaces has its own version numbering (3.x) independent of OpenShift Container Platform versions.

dev-spaces-uses-devfiles [IN] OBSERVATION

Dev Spaces workspace configurations use the devfile specification.

developer-preview-vs-tech-preview [IN] OBSERVATION

Developer Preview is unsupported and opt-in (may render cluster unsupportable, can be removed at any time); Technology Preview is partially supported but not production-ready.

disable-default-catalogsources-command [IN] OBSERVATION

Disabling all default catalog sources: oc patch operatorhub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

disaster-recovery-diverges-despite-unified-platform-model [IN] DERIVED

Disaster recovery is the deepest point of topology divergence in the otherwise unified platform model: standalone clusters use etcd snapshot/restore, hosted control planes require separate encryption key backup and etcdutl (not etcdctl), and SNO accepts downtime — contradicting the platform's goal of operational uniformity across topologies

disaster-recovery-shares-immutability-constraint [IN] DERIVED

Disaster recovery and normal operations share the same immutability enforcement: etcd backup/restore operates under version governance (no rollback, forward-only) while node configuration flows exclusively through the MCO pipeline — both prohibit direct manipulation, making the immutable delivery model the universal access pattern.

disaster-recovery-varies-by-topology [IN] DERIVED

Disaster recovery procedures diverge across topologies: standalone clusters use etcd snapshot/restore via oc debug+chroot under version governance, while hosted control planes require separately-saved encryption keys and use etcdutl (not etcdctl) with --skip-hash-check — but both share the same irreversibility constraint that backup is last-resort, not rollback.

disaster-recovery-within-version-governance [IN] DERIVED

Disaster recovery is constrained by the same version governance that controls normal operations: etcd backup/restore is last-resort only (not rollback), rollback is unsupported, and version coupling (OCP→CNV→HCP ordering) means a restore to a prior state may create version mismatches that cannot be corrected — making prevention through proper update governance critical.

disconnected-cluster-delivery-pipeline [IN] DERIVED

Disconnected (air-gapped) OpenShift clusters require a specialized content delivery pipeline: oc-mirror generates IDMS manifests for image mirroring, the installer must be extracted from mirrored content, FBC catalogs replace registry-dependent SQLite catalogs, and MCO applies registry configuration to nodes — creating an end-to-end offline supply chain from operator catalogs through node configuration.

disconnected-day2-requires-mirrored-content [IN] OBSERVATION

Both initial installation and day-2 operations (updates, operator installation) require mirrored content in disconnected environments

disconnected-image-mirror-redirect-icsp-idms [IN] OBSERVATION

In disconnected environments, ImageContentSourcePolicy (ICSP) or ImageDigestMirrorSet (IDMS) redirect image pulls to a mirror registry

disconnected-image-mirroring-tools [IN] OBSERVATION

oc-mirror or oc adm catalog mirror are used to populate a local registry with required images for disconnected installations

disconnected-samples-operator-defaults-removed [IN] OBSERVATION

In disconnected installations, the Cluster Samples Operator defaults to Removed status; it must be set to Managed to install image streams.

disk-encryption-tpm-pcr1-pcr7 [IN] OBSERVATION

Disk encryption with TPM in OCP uses PCR 1 (UEFI state) and PCR 7 (secure boot state) to bind encryption keys; this is a Technology Preview feature.

distributed-tracing-backed-by-jaeger-tempo-otel [IN] OBSERVATION

OpenShift distributed tracing is backed by Red Hat OpenShift distributed tracing platform (based on Jaeger/Tempo) and the OpenTelemetry Collector

distributed-tracing-not-enabled-by-default [IN] OBSERVATION

Distributed tracing in OpenShift is a configurable platform feature that is not enabled by default — it requires operator installation and configuration

distributed-tracing-three-capabilities [IN] OBSERVATION

Distributed tracing provides three key capabilities: store, analyze, and visualize transaction data across microservices

dns-basedomain-privatezone-publiczone-immutable [IN] OBSERVATION

The DNS config fields baseDomain, publicZone, and privateZone are immutable after initial creation.

dns-ca-bundle-configmap-openshift-config [IN] OBSERVATION

DNS TLS CA bundle ConfigMaps must be in openshift-config namespace with key ca-bundle.crt (PEM encoded).

dns-cache-default-ttls [IN] OBSERVATION

Default DNS cache TTLs are positive = 900 seconds (15 minutes) and negative = 30 seconds.

dns-cache-positive-ttl-900s-negative-30s [IN] OBSERVATION

Default DNS cache TTLs are positiveTTL=900s and negativeTTL=30s when fields are omitted.

dns-cannot-specify-cluster-domain-as-zone [IN] OBSERVATION

The cluster domain (e.g., cluster.local) cannot be specified as a zone in .spec.servers.

dns-cluster-ip-10th-address-service-cidr [IN] OBSERVATION

The cluster DNS IP is the 10th address in the service CIDR range (e.g., 172.30.0.10 for 172.30.0.0/16).

dns-cluster-local-invalid-forwarding-zone [IN] OBSERVATION

cluster.local cannot be used as a forwarding zone in spec.servers.zones.

dns-config-vs-dns-operator-different-api-groups [IN] OBSERVATION

The DNS config object uses API group config.openshift.io/v1, distinct from the DNS operator object under operator.openshift.io.

dns-default-master-toleration-removal-risks-outage [IN] OBSERVATION

Removing the default node-role.kubernetes.io/master toleration from DNS pods risks cluster DNS outage if all worker nodes go down.

dns-forward-policy-defaults-differ [IN] OBSERVATION

DNS forward policy defaults differ: Random for .spec.servers entries, Sequential for .spec.upstreamResolvers.

dns-forward-policy-random-servers-sequential-upstream [IN] OBSERVATION

DNS forward policy defaults differ: Random for spec.servers, Sequential for spec.upstreamResolvers.

dns-max-15-upstreams-per-forwardplugin [IN] OBSERVATION

Maximum of 15 upstreams per forwardPlugin in DNS forwarding configuration.

dns-nil-publiczone-no-public-records [IN] OBSERVATION

If publicZone is nil on the DNS config, no public DNS records are created (relevant for private/disconnected clusters).

dns-node-resolver-daemonset-image-registry [IN] OBSERVATION

The node-resolver DaemonSet adds an entry for image-registry.openshift-image-registry.svc to /etc/hosts on every node so the container runtime can resolve the image registry.

dns-operator-coredns-daemonset [IN] OBSERVATION

The DNS Operator deploys CoreDNS as a DaemonSet on all nodes with default domain cluster.local.

dns-operator-deploys-coredns-daemonset [IN] OBSERVATION

The DNS Operator deploys CoreDNS as a DaemonSet (not a Deployment) in the openshift-dns namespace.

dns-operator-manages-coredns [IN] OBSERVATION

The DNS Operator (operator.openshift.io/v1) manages CoreDNS as the cluster-wide name resolution service in OpenShift.

dns-operator-namespace-openshift-dns-operator [IN] OBSERVATION

The DNS Operator runs in the openshift-dns-operator namespace; CoreDNS pods run in openshift-dns.

dns-over-tls-port-853 [IN] OBSERVATION

DNS-over-TLS uses port 853 by default (per RFC 7858) and requires the serverName field to be set.

dns-platform-config-only-aws [IN] OBSERVATION

The DNS config spec.platform currently only supports AWS as a named platform type, with privateZoneIAMRole for cross-account DNS management.

dns-service-discovery-architecture [IN] DERIVED

OpenShift DNS follows a deterministic architecture: CoreDNS runs as a DaemonSet (not Deployment) managed by the DNS Operator, the cluster DNS IP is algorithmically derived as the 10th address in the service CIDR, cluster.local is reserved and cannot be used as a forwarding zone, and the full cluster DNS name follows <metadata.name>.<baseDomain> — making DNS both predictable and constrained.

dns-unmanaged-blocks-cluster-upgrades [IN] OBSERVATION

Setting DNS Operator managementState to Unmanaged blocks cluster upgrades.

dnsrecord-default-ttl-30-seconds [IN] OBSERVATION

DNSRecord default TTL is 30 seconds when recordTTL is set to zero; on AWS, TTL is ignored for Alias targets but applies to CNAME targets.

dnsrecord-internal-operator-resource [IN] OBSERVATION

The DNSRecord resource (ingress.operator.openshift.io/v1) is an internal operator resource not intended for cluster admin manipulation.

dnsrecord-is-namespaced [IN] OBSERVATION

The DNSRecord resource is namespaced, not cluster-scoped.

dnsrecord-management-policy-managed-unmanaged [IN] OBSERVATION

The dnsManagementPolicy field on DNSRecord controls whether the ingress operator manages DNS records; valid values are Managed (default) and Unmanaged.

do-not-edit-cno-managed-nad [IN] OBSERVATION

NetworkAttachmentDefinition CRs managed by the Cluster Network Operator must not be manually edited

do-not-modify-clusterversion-directly [IN] OBSERVATION

Administrators should not directly modify the ClusterVersion object — use oc CLI or web console instead.

docker-runtime-deprecated-k8s-120 [IN] OBSERVATION

Docker as a container runtime is deprecated in Kubernetes 1.20, but Docker-built images still work with all container runtimes including CRI-O.

docker-strategy-requires-elevated-privileges [IN] OBSERVATION

Docker strategy builds require elevated privileges and may be restricted in multi-tenant clusters.

dockerimagelayers-manifests-mutually-exclusive [IN] OBSERVATION

In Image objects, dockerImageManifests[] and dockerImageLayers[] are mutually exclusive — manifest lists vs single images

dpdk-1gi-hugepages-require-kernel-args [IN] OBSERVATION

1Gi hugepages require kernel arguments: default_hugepagesz=1GB, hugepagesz=1G, hugepages=16

dpdk-intel-vfio-pci-mellanox-netdevice [IN] OBSERVATION

For DPDK workloads, Intel NICs use deviceType: vfio-pci (vendor 8086) while Mellanox NICs use deviceType: netdevice with isRdma: true (vendor 15b3)

dpdk-pod-required-capabilities [IN] OBSERVATION

DPDK/RDMA pods require three security capabilities: IPCLOCK, SYSRESOURCE, and NET_RAW

dpdk-requires-hugepages-and-static-cpu-manager [IN] OBSERVATION

DPDK applications require hugepages (2Mi or 1Gi, mounted as emptyDir with medium HugePages) and exclusive CPUs via kubelet's static CPU Manager policy (set equal requests and limits for Guaranteed QoS)

drain-ignore-daemonsets-flag [IN] OBSERVATION

oc adm drain requires --ignore-daemonsets=true when DaemonSet-managed pods exist on the node.

dual-stack-ip-order-must-match [IN] OBSERVATION

In dual-stack configurations, IPv4 and IPv6 addresses must be listed in the same order across all network parameters (clusterNetwork, serviceNetwork, machineNetwork).

dual-stack-networking-with-constraints [IN] DERIVED

OpenShift supports dual-stack IPv4+IPv6 addressing but with constraints: OVN-Kubernetes allows only a single service network block, UDN has specific MTU minimums per IP family, and OpenShift Virtualization cannot run on single-stack IPv6.

dual-stack-same-interface-required [IN] OBSERVATION

Dual-stack networking requires both IP families (IPv4 and IPv6) to use the same network interface for the default gateway.

dynamic-plugin-disable-query-param [IN] OBSERVATION

Users can disable console plugins via the disable-plugins query parameter in the browser URL

dynamic-plugin-enable-path [IN] OBSERVATION

Dynamic plugins are enabled/disabled by cluster admins via Administration → Cluster Settings → Configuration → Console (operator.openshift.io)

dynamic-plugin-helm-deploy-command [IN] OBSERVATION

Dynamic plugins are deployed via Helm using helm upgrade -i <name> charts/openshift-console-plugin -n <namespace> --create-namespace --set plugin.image=<image>

dynamic-plugin-i18n-namespace-prefix [IN] OBSERVATION

Dynamic plugin i18n namespace must be prefixed with plugin__ and match the ConsolePlugin resource name

dynamic-plugin-no-redhat-support [IN] OBSERVATION

Custom dynamic plugin code is not supported by Red Hat — only cooperative community support is available

dynamic-plugin-patternfly-version-alignment [IN] OBSERVATION

Dynamic plugins require PatternFly 4.x for OCP ≤4.14 and PatternFly 5.x for OCP ≥4.15

dynamic-plugin-proxy-auth-values [IN] OBSERVATION

The proxy authorization field in a ConsolePlugin CR accepts values UserToken (forwards user's OCP token) or None

dynamic-plugin-proxy-url-pattern [IN] OBSERVATION

Service proxy endpoint for dynamic plugins follows the pattern /api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>

dynamic-provisioned-volumes-delete-policy [IN] OBSERVATION

Dynamically provisioned volumes always use the Delete reclaim policy.

dynamic-provisioning-requires-storageclass [IN] OBSERVATION

Dynamic provisioning requires a StorageClass — it creates PVs on-demand, eliminating the need for admin pre-provisioning.

dynamically-provisioned-volumes-delete-policy [IN] OBSERVATION

Dynamically provisioned persistent volumes always use the Delete reclaim policy.

ebpf-agent-layer3-not-layer2 [IN] OBSERVATION

The eBPF agent operates at OSI layers 3-4 and cannot capture traffic on layer-2-only bridge interfaces like br-int or br-ex

ebpf-manager-alpha-channel-community-operators [IN] OBSERVATION

The eBPF Manager Operator uses the alpha channel from the community-operators catalog source.

ebpf-manager-bpfman-namespace-privileged [IN] OBSERVATION

The eBPF Manager Operator is installed in the bpfman namespace with privileged pod security enforcement.

ebpf-manager-operator-tech-preview [IN] OBSERVATION

The eBPF Manager Operator is a Technology Preview feature — not supported for production use.

ebpf-maps-accessed-via-csi-volume-mounts [IN] OBSERVATION

Applications access eBPF maps via CSI volume mounts, so application pods do not need privileged access.

ebpf-programs-packaged-oci-images [IN] OBSERVATION

eBPF programs managed by the eBPF Manager Operator are packaged as OCI container images.

edge-compute-pool-noschedule-taint [IN] OBSERVATION

Edge compute pool nodes (Local Zones / Wavelength Zones) have a NoSchedule taint by default; workloads require explicit tolerations.

edge-computing-first-class-ocp-deployment [IN] OBSERVATION

Edge computing is a first-class deployment model in OpenShift Container Platform with dedicated documentation, tooling, and specialized topologies.

edge-computing-targets-far-edge [IN] OBSERVATION

Edge computing in OpenShift targets far-edge use cases (e.g., cell towers, retail locations, industrial sites), not near-edge or regional data centers.

edge-disconnected-fleet-delivery [IN] DERIVED

Edge fleet deployments combine ZTP provisioning with disconnected content delivery: ZTP/GitOps provisions clusters at scale while oc-mirror/IDMS/FBC pipelines deliver images and operators without direct registry access, creating a fully autonomous edge lifecycle from provisioning through software delivery.

edge-fleet-management-pipeline [IN] DERIVED

Edge cluster lifecycle follows a managed pipeline: ZTP with GitOps provisions fleets at scale, TALM orchestrates updates with canary-first failure-gating, SNO provides the minimal topology, and vDU workloads require specific BIOS-level firmware constraints — creating an end-to-end edge operations model.

edge-routes-tls-at-router [IN] OBSERVATION

Edge routes provide TLS termination at the router level (HAProxy Ingress Controller). Created with oc create route edge <name> --service=<service>.

edge-zone-default-ebs-gp2 [IN] OBSERVATION

Default EBS volume type for AWS Local Zone and Wavelength Zone compute pools is gp2, unlike non-edge compute pools.

egress-firewall-default-allow [IN] OBSERVATION

EgressFirewall default behavior is allow — without an EgressFirewall or when no rule matches, all egress traffic is permitted

egress-firewall-dns-wildcard-single-level [IN] OBSERVATION

EgressFirewall dnsName wildcards match only one label level — *.example.com matches sub1.example.com but not sub2.sub1.example.com

egress-firewall-namespace-scoped-ovn [IN] OBSERVATION

EgressFirewall is namespace-scoped (not cluster-scoped) and uses the k8s.ovn.org/v1 API group (OVN-Kubernetes specific)

egress-firewall-ordered-first-match-wins [IN] OBSERVATION

EgressFirewall rules are evaluated in order (first match wins) with three mutually exclusive destination selectors: cidrSelector, dnsName, or nodeSelector

egress-firewall-protocols-tcp-udp-sctp [IN] OBSERVATION

EgressFirewall supports three protocols for port filtering: tcp, udp, and sctp

egressfirewall-api-group-ovn [IN] OBSERVATION

The EgressFirewall CR uses the API group k8s.ovn.org/v1 in OVN-Kubernetes.

egressfirewall-broken-config-drops-all [IN] OBSERVATION

A broken EgressFirewall configuration causes all external traffic to be dropped.

egressfirewall-cluster-admin-only [IN] OBSERVATION

Only cluster administrators can create, edit, or delete EgressFirewall resources.

egressfirewall-default-allow [IN] OBSERVATION

EgressFirewall default behavior is allow when no rule matches or no EgressFirewall exists; rules are evaluated in order (first match wins)

egressfirewall-deny-all-blocks-api-server [IN] OBSERVATION

A deny-all rule (0.0.0.0/0) in EgressFirewall blocks API server access; API server IPs must be explicitly allowed.

egressfirewall-dns-polling-30min-default [IN] OBSERVATION

DNS-based EgressFirewall rules poll for IP changes based on TTL with a default interval of 30 minutes.

egressfirewall-filter-types [IN] OBSERVATION

EgressFirewall rules can filter outbound traffic by DNS name, IP address, or CIDR range.

egressfirewall-first-match-wins [IN] OBSERVATION

EgressFirewall rules are evaluated in order; the first matching rule wins and subsequent rules are ignored for that connection.

egressfirewall-host-network-pods-unaffected [IN] OBSERVATION

Pods with host networking enabled are not affected by EgressFirewall rules.

egressfirewall-max-8000-rules [IN] OBSERVATION

Maximum of 8,000 rules per EgressFirewall object.

egressfirewall-one-per-namespace [IN] OBSERVATION

Only one EgressFirewall custom resource is allowed per namespace when using OVN-Kubernetes.

egressfirewall-one-per-project-named-default [IN] OBSERVATION

Only one EgressFirewall CR is allowed per project, and it must be named default.

egressfirewall-requires-ovn-kubernetes [IN] OBSERVATION

EgressFirewall requires the OVN-Kubernetes network plugin (API group k8s.ovn.org/v1).

egressfirewall-routes-bypass [IN] OBSERVATION

Traffic going through OpenShift Routes bypasses EgressFirewall rules; users with Route CR permissions can bypass restrictions.

egressip-api-group-ovn [IN] OBSERVATION

EgressIP uses API group k8s.ovn.org/v1 and is specific to the OVN-Kubernetes network plugin

egressip-cluster-scoped [IN] OBSERVATION

EgressIP is a cluster-scoped resource (not namespaced)

egressip-dual-stack-support [IN] OBSERVATION

EgressIP supports dual-stack with both IPv4 and IPv6 addresses in the same resource

egressip-fixed-source-ip [IN] OBSERVATION

EgressIP (k8s.ovn.org/v1) provides a fixed source IP for egress traffic from matching pods

egressip-podselector-omit-behavior [IN] OBSERVATION

When EgressIP podSelector is omitted, the egress IP applies to all pods in matched namespaces

egressip-required-fields [IN] OBSERVATION

EgressIP requires both spec.egressIPs (list of IPs) and spec.namespaceSelector in the spec; podSelector is optional

egressip-selector-intersection [IN] OBSERVATION

When both namespaceSelector and podSelector are set on an EgressIP, they are intersected — pods must match both

egressip-status-shows-node-mapping [IN] OBSERVATION

EgressIP .status.items[] is read-only and shows the node-to-IP mapping for assigned egress IPs

egressqos-dscp-marking [IN] OBSERVATION

EgressQoS assigns DSCP (Differentiated Services Code Point) values to egress traffic from pods for QoS differentiation

egressqos-dscp-only-required-field [IN] OBSERVATION

In each EgressQoS rule, dscp is the only required field; dstCIDR and podSelector are optional

egressqos-namespace-scoped [IN] OBSERVATION

EgressQoS is a namespace-scoped resource in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes

egressqos-omit-dstcidr-all-traffic [IN] OBSERVATION

When dstCIDR is omitted from an EgressQoS rule, the DSCP marking applies to all egress traffic regardless of destination

egressqos-rules-ordered [IN] OBSERVATION

EgressQoS traffic is checked against rules in order; matching traffic gets the DSCP value from the first matching rule

egressrouter-api-group [IN] OBSERVATION

EgressRouter uses API group network.operator.openshift.io/v1 and is managed by the Cluster Network Operator

egressrouter-creates-three-resources [IN] OBSERVATION

Creating an EgressRouter CR automatically creates three resources with the same name: a Service, a Pod, and a NetworkAttachmentDefinition (NAD)

egressrouter-macvlan-default-bridge [IN] OBSERVATION

EgressRouter macvlan default mode is Bridge; the master interface is optional if inferable from the IP

egressrouter-no-fallbackip-rejects [IN] OBSERVATION

If EgressRouter has redirect rules but no fallbackIP, connections on undefined ports are rejected

egressrouter-only-redirect-macvlan [IN] OBSERVATION

EgressRouter only supports mode Redirect (DNAT-based) and only supports macvlan as the network interface type

egressrouter-redirect-protocols [IN] OBSERVATION

EgressRouter redirect rules support TCP, UDP, and SCTP protocols; targetPort defaults to port if omitted

egressservice-loadbalancerip-single-node [IN] OBSERVATION

When EgressService sourceIPBy=LoadBalancerIP, traffic is pinned to a single node shown in .status.host; when sourceIPBy=Network, status host is "ALL"

egressservice-matches-loadbalancer-ip [IN] OBSERVATION

EgressService (k8s.ovn.org/v1) makes egress source IP equal to the LoadBalancer Service's ingress IP

egressservice-network-field-vrf [IN] OBSERVATION

EgressService network field enables routing egress through an alternate network/VRF rather than the default routing table

egressservice-nodeselector-only-loadbalancerip [IN] OBSERVATION

EgressService nodeSelector field only applies when sourceIPBy=LoadBalancerIP

egressservice-ovn-namespaced [IN] OBSERVATION

EgressService is a namespaced CRD in the k8s.ovn.org/v1 API group, specific to OVN-Kubernetes

egressservice-sourceipby-modes [IN] OBSERVATION

EgressService sourceIPBy has two modes: LoadBalancerIP (uses LB ingress IP as source) and Network (uses node interface IP)

emptydir-usage-counts-toward-pod-ephemeral-limit [IN] OBSERVATION

EmptyDir volume usage counts toward the pod's overall ephemeral storage consumption and limits.

enable-default-route-patch-command [IN] OBSERVATION

The default external route for the registry is enabled with oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{"spec":{"defaultRoute":true}}'.

encryption-and-tls-infrastructure-model [IN] DERIVED

OpenShift enforces encryption at multiple layers: four TLS security profile types (Old/Intermediate/Modern/Custom) govern API and route encryption, IPsec uses AES-GCM-16-256 in Transport mode for pod-to-pod encryption on OVN-Kubernetes, and SAN fields are mandatory in HTTPS certificates since OCP 4.10 — creating defense-in-depth from certificate validation through transport encryption.

end-users-access-images-via-imagestreamtag-or-imagestreamimage [IN] OBSERVATION

End users access images via ImageStreamTags or ImageStreamImages, not the Image resource directly.

end-users-access-images-via-istag-isimage [IN] OBSERVATION

End users should access images through ImageStreamTag or ImageStreamImage resources, not directly through Image resources (which are for cluster admins and integrations)

end-users-create-projects-via-projectrequest [IN] OBSERVATION

End users create projects via the ProjectRequest resource (oc new-project), not by directly creating Project objects

endpoints-auto-created-same-name [IN] OBSERVATION

Endpoints objects are automatically created with the same name as the Service when the Service has a selector

endpoints-cartesian-product [IN] OBSERVATION

The expanded endpoint set within a subset is the Cartesian product of Addresses × Ports

endpoints-core-v1-namespaced [IN] OBSERVATION

Endpoints are namespaced core v1 objects at API path /api/v1/

endpoints-forbidden-ip-ranges [IN] OBSERVATION

Endpoint addresses cannot use loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast (224.0.0.0/24) IP ranges

endpoints-manual-no-selector [IN] OBSERVATION

Manual Endpoints (Service with no selector) allow routing to external IPs or other namespaces

endpoints-notready-excluded-lb [IN] OBSERVATION

Addresses in notReadyAddresses have failed health checks or are still starting and are excluded from load balancing

endpoints-port-default-tcp [IN] OBSERVATION

EndpointPort protocol defaults to TCP; valid values are TCP, UDP, and SCTP

endpointslice-address-type-immutable [IN] OBSERVATION

EndpointSlice addressType field is immutable after creation and supports three values: IPv4, IPv6, FQDN

endpointslice-api-group-discovery-v1 [IN] OBSERVATION

EndpointSlice belongs to API group discovery.k8s.io/v1, not the v1 core API group

endpointslice-default-port-protocol-tcp [IN] OBSERVATION

The default port protocol for EndpointSlice ports is TCP; supported protocols are TCP, UDP, and SCTP

endpointslice-max-1000-endpoints-100-ports [IN] OBSERVATION

Each EndpointSlice can hold a maximum of 1000 endpoints and 100 ports

endpointslice-nil-ready-means-ready [IN] OBSERVATION

A nil ready condition on an EndpointSlice endpoint should be interpreted as ready by consumers

endpointslice-three-conditions [IN] OBSERVATION

EndpointSlice endpoints track three conditions: ready (prepared to receive traffic), serving (like ready but remains true during termination), and terminating (endpoint is shutting down)

ephemeral-containers-added-at-runtime-only [IN] OBSERVATION

Ephemeral containers are added to running pods via the ephemeralcontainers subresource for debugging — they cannot be specified at pod creation

ephemeral-containers-via-subresource [IN] OBSERVATION

Ephemeral containers are added to running pods via the ephemeralcontainers subresource, not by updating the pod spec directly.

ephemeral-storage-best-effort-resource [IN] OBSERVATION

Ephemeral storage is a best-effort resource — pods cannot detect available local storage or request guaranteed local storage.

ephemeral-storage-pod-limit-is-sum-of-container-limits [IN] OBSERVATION

Pod-level ephemeral storage limit equals the sum of all container limits in the pod; pod-level request equals the sum of all container requests.

ephemeral-storage-root-partition-path [IN] OBSERVATION

The ephemeral storage root partition default path is /var/lib/kubelet/ and /var/log/; it holds emptyDir volumes, container logs, image layers, and writable layers.

ephemeral-storage-unit-suffixes-case-sensitive [IN] OBSERVATION

Ephemeral storage unit suffixes are case-sensitive: M = megabytes, Mi = mebibytes, m = millibytes (0.001 bytes).

etc-passwd-must-not-exist-in-image [IN] OBSERVATION

The /etc/passwd file must not exist in the container image because CRI-O injects random UIDs into it at runtime

etcd-automated-backup-pvc-in-openshift-etcd [IN] OBSERVATION

The PVC for automated etcd backups must be in the openshift-etcd namespace.

etcd-automated-backup-retention-default-15 [IN] OBSERVATION

Automated etcd backup retention types are RetentionNumber (default: 15 backups) or RetentionSize.

etcd-backup-before-cluster-shutdown [IN] OBSERVATION

etcd must be backed up before shutting down a cluster.

etcd-backup-from-single-control-plane-host [IN] OBSERVATION

etcd backup must be taken from only one control plane host, not from each control plane host.

etcd-backup-not-rollback-mechanism [IN] OBSERVATION

etcd backup/restore is a last-resort disaster recovery mechanism, not a rollback mechanism — rolling back to a previous OCP version is not supported.

etcd-backup-primary-disaster-recovery [IN] OBSERVATION

etcd backup and restore is the primary mechanism for cluster-level disaster recovery in OpenShift.

etcd-backup-produces-two-files [IN] OBSERVATION

etcd backup produces two files: snapshot<datetimestamp>.db (the etcd snapshot) and statickuberesources_<datetimestamp>.tar.gz (static pod resources and encryption keys if enabled).

etcd-backup-requires-oc-debug-chroot [IN] OBSERVATION

To run the etcd backup, you must first oc debug --as-root node/<node> then chroot /host before executing the backup script.

etcd-backup-script-path [IN] OBSERVATION

The etcd backup script is located at /usr/local/bin/cluster-backup.sh and is maintained by the etcd Cluster Operator.

etcd-backup-separate-from-oadp [IN] OBSERVATION

etcd backup is separate from OADP and uses its own backup/restore mechanism; etcd backup is the fundamental cluster-level backup in OpenShift.

etcd-controlplanehardwarespeed-slower-for-latency [IN] OBSERVATION

The Etcd operator controlPlaneHardwareSpeed field with value Slower tunes etcd for environments with higher network latency between control plane nodes.

etcd-default-revision-limits-5 [IN] OBSERVATION

Etcd operator default revision limits (both failedRevisionLimit and succeededRevisionLimit) are 5 when set to 0 or unset; -1 means unlimited.

etcd-disaster-recovery-constraints [IN] DERIVED

etcd backup/restore is a last-resort disaster recovery mechanism (not rollback) that requires privileged access via oc debug + chroot, and must not be confused with routine operations — direct etcd access outside documented procedures is unsupported.

etcd-encrypted-resource-types [IN] OBSERVATION

etcd encryption covers Secrets, ConfigMaps, Routes, OAuth access tokens, and OAuth authorize tokens; only values are encrypted, not keys (resource types, namespaces, object names remain unencrypted).

etcd-encryption-encrypts-values-not-keys [IN] OBSERVATION

etcd encryption only encrypts values, not keys — resource types, namespaces, and object names remain unencrypted.

etcd-encryption-keys-rotate-weekly [IN] OBSERVATION

etcd encryption keys are rotated automatically on a weekly basis for both AES-GCM and AES-CBC encryption types.

etcd-encryption-not-default [IN] OBSERVATION

OpenShift does not encrypt etcd data by default; encryption must be explicitly enabled via the APIServer custom resource.

etcd-encryption-three-types [IN] OBSERVATION

etcd encryption supports three types: aesgcm (AES-GCM), aescbc (AES-CBC), and identity (no encryption/default); configured via spec.encryption.type on the APIServer resource.

etcd-encryption-verify-three-api-servers [IN] OBSERVATION

etcd encryption completion must be verified on three separate API servers: openshiftapiserver, kubeapiserver, and authentication.operator.openshift.io.

etcd-ephemeral-min-10gb [IN] OBSERVATION

The Nova ephemeral disk for etcd requires a minimum of 10 GB per control plane node.

etcd-ephemeral-not-rbd [IN] OBSERVATION

Nova ephemeral storage for etcd must use a local storage backend, not rbd.

etcd-ephemeral-xfs-format [IN] OBSERVATION

The ephemeral disk for etcd is formatted as XFS with label local-etcd and mounted with defaults,prjquota options.

etcd-force-redeployment-reason-retries-failed [IN] OBSERVATION

The forceRedeploymentReason field on the Etcd CR is the mechanism to force redeployment of a previously failed static pod revision using a unique string.

etcd-local-disk-rhosp-day2 [IN] OBSERVATION

Moving etcd from Cinder-backed root volume to Nova ephemeral local disk is a day-2 operation on RHOSP to resolve latency-sensitive etcd performance issues.

etcd-machineconfig-98-var-lib-etcd [IN] OBSERVATION

The MachineConfig 98-var-lib-etcd creates four systemd units: var-lib-etcd.mount, create-local-etcd.service, migrate-to-local-etcd.service, and relabel-var-lib-etcd.service.

etcd-machineconfig-never-remove [IN] OBSERVATION

The 98-var-lib-etcd MachineConfig must never be removed while ephemeral disks are in use — doing so breaks etcd and causes system instability.

etcd-no-backup-before-first-cert-rotation [IN] OBSERVATION

Do not take an etcd backup before the first certificate rotation (24 hours after install) because the backup will contain expired certificates.

etcd-primary-cluster-state-datastore [IN] OBSERVATION

etcd is the primary datastore for OpenShift cluster state.

etcd-quorum-fault-tolerance [IN] OBSERVATION

etcd requires a quorum (majority) of members to function; a 3-node control plane tolerates 1 etcd member failure, a 5-node control plane tolerates 2 failures.

etcd-quorum-protection-predrain-hook [IN] OBSERVATION

The etcd Operator uses a preDrain lifecycle hook (named EtcdQuorumOperator, owner clusteroperator/etcd) to protect quorum during control plane machine replacement by waiting for a replacement node to join and sync.

etcd-requires-fast-low-latency-io [IN] OBSERVATION

etcd is the primary data store for Kubernetes and requires fast, low-latency I/O due to high-frequency small writes.

etcd-restore-requires-same-z-stream [IN] OBSERVATION

Restoring from an etcd backup requires a backup from the same z-stream release (e.g., 4.17.5 backup for a 4.17.5 cluster).

etcd-rollback-cpms-no-ephemeral [IN] OBSERVATION

To roll back the etcd local disk migration, modify the ControlPlaneMachineSet to use a flavor without ephemeral disks, and only remove the MachineConfig after the CPMS update completes.

etcd-runs-as-static-pods [IN] OBSERVATION

Etcd runs as static pods on control plane nodes, managed by the etcd operator with a revision-based deployment model tracked per node.

etcd-runs-on-control-plane-nodes [IN] OBSERVATION

etcd runs exclusively on control plane (master) nodes as static pods managed by the cluster etcd operator.

etcd-sole-persistent-store [IN] OBSERVATION

etcd is the sole persistent key-value store for all Kubernetes and OpenShift cluster objects and configuration.

etcd-stores-cluster-data [IN] OBSERVATION

etcd stores cluster state data; kube-scheduler allocates pods to nodes; kube-controller-manager governs cluster state.

eus-extended-ibm-z-power-ocp-414 [IN] OBSERVATION

Extended Update Support (EUS) was extended to IBM Power and IBM Z platforms starting with OCP 4.14.

event-api-group-events-k8s-io-v1 [IN] OBSERVATION

Events use API group events.k8s.io/v1 (distinct from the older v1 core Events).

event-eventtime-only-required-field [IN] OBSERVATION

eventTime (MicroTime) is the only required field on an Event (besides standard metadata).

event-namespaced-but-cluster-listable [IN] OBSERVATION

Events are namespaced resources but can be listed cluster-wide via /api/v1/events or oc get events -A.

event-required-fields-metadata-involvedobject [IN] OBSERVATION

Event objects require metadata and involvedObject fields; involvedObject uses an ObjectReference structure.

event-standard-types-normal-warning [IN] OBSERVATION

The Event type field has two standard values: Normal and Warning.

event-types-normal-and-warning [IN] OBSERVATION

Event type values are Normal and Warning; new types may be added in the future.

event-v1-limited-retention [IN] OBSERVATION

Kubernetes Events (v1) have limited retention time and are automatically garbage-collected; they should not be relied upon as a reliable audit log.

events-limited-retention-not-reliable [IN] OBSERVATION

Events have limited retention and are best-effort supplemental data; they should not be relied upon for persistent state or decision-making.

events-namespaced-resource [IN] OBSERVATION

Events are namespaced resources.

eviction-and-pdb-use-policy-v1-api [IN] OBSERVATION

Both Eviction and PodDisruptionBudget belong to the policy/v1 API group (stable/GA).

eviction-api-group-policy-v1 [IN] OBSERVATION

The Eviction resource uses API group policy/v1 (stable), replacing the deprecated policy/v1beta1.

eviction-field-validation-default-warn [IN] OBSERVATION

The fieldValidation parameter defaults to Warn in Kubernetes v1.23+ (relevant for OCP 4.x which is based on K8s 1.24+).

eviction-is-pod-subresource [IN] OBSERVATION

Eviction is a subresource of Pod, created by POSTing to /api/v1/namespaces/{namespace}/pods/{pod-name}/eviction, not a standalone top-level resource.

eviction-respects-pdb-delete-does-not [IN] OBSERVATION

Eviction respects PodDisruptionBudgets (PDBs); direct pod deletion does not.

eviction-subresource-of-pod [IN] OBSERVATION

Eviction is a subresource of Pod accessed via POST /api/v1/namespaces/{namespace}/pods/{name}/eviction, not a top-level resource.

exclude-node-draining-annotation [IN] OBSERVATION

The annotation machine.openshift.io/exclude-node-draining on a machine skips the node drain step during deletion.

expired-certs-approve-csrs [IN] OBSERVATION

If Ignition certificates expire, recovery requires manually approving pending node-bootstrapper CSRs to restore kubelet certificates

expired-silences-gc-120-hours [IN] OBSERVATION

Expired silences in Alertmanager cannot be deleted manually and are garbage collected after 120 hours.

explicit-multi-component-enablement-pattern [IN] DERIVED

Multiple OpenShift subsystems follow a common pattern where capability beyond the default platform requires explicit, multi-component enablement: service mesh needs multiple operators (mesh + Kiali + tracing) with multi-tenant SMCP, while observability requires separate admin action for user workload monitoring and distributed tracing — neither is automatic despite being platform-integrated.

extension-api-groups-three [IN] OBSERVATION

All six Extension API types belong to one of three API groups: apiregistration.k8s.io/v1, apiextensions.k8s.io/v1, or admissionregistration.k8s.io/v1.

external-dns-aws-creds-kube-system [IN] OBSERVATION

AWS credentials for the External DNS Operator come from the aws-creds secret in the kube-system namespace.

external-dns-aws-govcloud-no-sts [IN] OBSERVATION

AWS GovCloud with STS-enabled clusters is not supported by the External DNS Operator.

external-dns-channel-stable-v1-redhat-operators [IN] OBSERVATION

The External DNS Operator subscription uses channel stable-v1 from the redhat-operators catalog source.

external-dns-domain-length-cname-44-a-48 [IN] OBSERVATION

External DNS domain name length limits due to TXT registry prefix: CNAME max 44 chars, A record max 48 chars.

external-dns-operator-namespace [IN] OBSERVATION

The External DNS Operator is installed into the external-dns-operator namespace.

external-dns-operator-x86-64-only [IN] OBSERVATION

The External DNS Operator supports x86_64 architecture only.

external-dns-source-types-service-route [IN] OBSERVATION

The External DNS Operator supports two source types: Service and OpenShiftRoute.

externalip-autoassign-bare-metal [IN] OBSERVATION

externalIP.autoAssignCIDRs is primarily useful for bare-metal clusters

externalip-rejected-takes-precedence [IN] OBSERVATION

externalIP.policy.rejectedCIDRs takes precedence over allowedCIDRs; if externalIP is nil, ExternalIP cannot be set on Services

extract-installer-from-mirrored-content [IN] OBSERVATION

In disconnected installs, the installer must be extracted from mirrored content using oc adm release extract --command=openshift-install to ensure version correctness.

factory-precaching-cli-technology-preview [IN] OBSERVATION

The factory-precaching-cli tool (in quay.io/openshift-kni/telco-ran-tools:latest) is Technology Preview — not supported under production SLAs.

fbc-bundle-immutability [IN] OBSERVATION

Bundle images and metadata in FBC are immutable; broken bundles require releasing a new bundle with an upgrade edge rather than in-place fixes

fbc-default-format-since-ocp411 [IN] OBSERVATION

File-based catalogs (FBC) in JSON/YAML are the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.

fbc-default-since-ocp-411-sqlite-deprecated [IN] OBSERVATION

File-based catalogs (FBC) became the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.

fbc-deprecations-schema [IN] OBSERVATION

The olm.deprecations schema defines deprecation info for packages, bundles, and channels, surfacing PackageDeprecated, ChannelDeprecated, and BundleDeprecated status conditions

fbc-format-json-yaml-not-sqlite [IN] OBSERVATION

File-based catalogs (FBC) use plain-text JSON or YAML declarative configuration, replacing the older SQLite database format

fbc-modernizes-operator-catalog-format [IN] DERIVED

File-based catalogs replaced SQLite as the default since OCP 4.11, with opm validate for integrity checking and skipRange for update graph pruning — representing the modern catalog management model.

fbc-required-schemas-per-package [IN] OBSERVATION

Each FBC package requires exactly one olm.package blob, at least one olm.channel, and one or more olm.bundle blobs

fbc-skiprange-prunes-update-graph [IN] OBSERVATION

Using skipRange in FBC channel entries prunes skipped versions from the update graph, making them uninstallable; combine skipRange with replaces to preserve incremental upgrade paths

fbc-three-required-schemas [IN] OBSERVATION

File-based catalogs require three schema types per package: olm.package (exactly one), olm.channel (at least one), and olm.bundle (one or more).

fbc-three-schemas [IN] OBSERVATION

File-based catalogs use three schemas: olm.package (exactly one per package), olm.channel (at least one per package), and olm.bundle (one or more per package).

featuregate-custom-no-upgrade-irreversible-blocks-upgrades [IN] OBSERVATION

Setting featureSet to CustomNoUpgrade on the FeatureGate resource is unsupported, irreversible, and blocks cluster upgrades.

featuregate-default-featureset-empty [IN] OBSERVATION

The default featureSet on the FeatureGate resource is empty (no value), which applies the standard feature set.

featuregate-operators-read-status-not-spec [IN] OBSERVATION

Operators must read .status.featureGates (not .spec) to determine which features are active for their managed version.

field-selector-filter-events-by-involved-object [IN] OBSERVATION

Events can be filtered by involved object using field selectors: oc get events --field-selector involvedObject.name=<pod-name>.

field-validation-default-changed-k8s-1.23 [IN] OBSERVATION

The fieldValidation query parameter default changed from Ignore to Warn in Kubernetes v1.23.

field-validation-default-changed-k8s-v123 [IN] OBSERVATION

Kubernetes fieldValidation parameter default changed from Ignore (pre-v1.23) to Warn (v1.23+); Strict rejects unknown or duplicate fields

field-validation-default-changed-v123 [IN] OBSERVATION

The fieldValidation parameter default changed at Kubernetes v1.23: prior to v1.23 it defaults to Ignore, v1.23+ defaults to Warn.

field-validation-default-warn-since-k8s-123 [IN] OBSERVATION

The fieldValidation parameter default changed at Kubernetes v1.23: before v1.23 it was Ignore, from v1.23+ it is Warn.

field-validation-default-warn-since-v1-23 [IN] OBSERVATION

The fieldValidation default changed from Ignore (pre-v1.23) to Warn (v1.23+) for Kubernetes API requests.

field-validation-default-warn-since-v123 [IN] OBSERVATION

The fieldValidation parameter default changed at Kubernetes v1.23 from Ignore to Warn

field-validation-default-warn-v123 [IN] OBSERVATION

The fieldValidation query parameter defaults to Ignore before Kubernetes v1.23 and Warn in v1.23+; Strict rejects requests with unknown or duplicate fields.

field-validation-defaults [IN] OBSERVATION

The fieldValidation parameter defaults to Ignore (silently drop unknown fields) before Kubernetes v1.23, and Warn (warn on unknown/duplicate fields) from v1.23 onward; Strict rejects requests with unknown or duplicate fields.

field-validation-strict-rejects-unknown [IN] OBSERVATION

The fieldValidation=Strict query parameter on OpenShift/Kubernetes API requests rejects requests containing unknown or duplicate fields; default changed to Warn in v1.23+.

field-validation-strict-rejects-unknown-fields [IN] OBSERVATION

Setting fieldValidation=Strict on API requests rejects requests with unknown or duplicate fields; default since v1.23 is Warn

fieldvalidation-default-changed-k8s-123 [IN] OBSERVATION

The fieldValidation query parameter default changed at Kubernetes v1.23 from Ignore to Warn.

fieldvalidation-default-warn-since-v123 [IN] OBSERVATION

The fieldValidation parameter defaults to Ignore prior to Kubernetes v1.23 and Warn in v1.23+.

fieldvalidation-default-warn-v123 [IN] OBSERVATION

The fieldValidation query parameter defaults to Warn in Kubernetes v1.23+, replacing the previous Ignore default; Strict rejects requests with unknown or duplicate fields.

fieldvalidation-three-modes [IN] OBSERVATION

Kubernetes API fieldValidation query parameter supports three modes: Ignore (pre-v1.23 default), Warn (v1.23+ default), and Strict (rejects unknown/duplicate fields).

file-based-catalogs-replace-sqlite [IN] OBSERVATION

File-based catalogs (FBC) using JSON/YAML format replace the deprecated SQLite catalog format; built with opm render, opm validate, and opm init

filesystem-resize-requires-pod-restart [IN] OBSERVATION

File-system-based volume expansion (EBS, GCE, Cinder) requires a pod restart to complete the filesystem resize on the node.

filesystemresizepending-condition [IN] OBSERVATION

The FileSystemResizePending condition on a PVC indicates the backend volume resize is complete but the filesystem has not yet been resized; it clears once a pod mounts the volume.

fio-default-alert-nodehasintegrityfailure [IN] OBSERVATION

The File Integrity Operator ships a default PrometheusRule alert NodeHasIntegrityFailure that fires a warning after 1 second of integrity failure on a node.

fio-maxbackups-default-5 [IN] OBSERVATION

The File Integrity Operator config.maxBackups defaults to 5, controlling how many AIDE database and log backups are kept on each node after re-initialization.

fio-namespace-openshift-file-integrity [IN] OBSERVATION

The File Integrity Operator installs into the openshift-file-integrity namespace and requires the pod-security.kubernetes.io/enforce: privileged label in OCP 4.17+.

fio-not-supported-hcp [IN] OBSERVATION

The File Integrity Operator is not supported on Hosted Control Planes (HCP) clusters.

fio-reinit-failed-annotation [IN] OBSERVATION

The annotation file-integrity.openshift.io/re-init-on-failed= on a FileIntegrity CR reinitializes the AIDE database baseline on only failed nodes.

fio-uses-aide-daemonset [IN] OBSERVATION

The File Integrity Operator uses AIDE (Advanced Intrusion Detection Environment) deployed as a DaemonSet running privileged containers on each matching node.

fips-enforcement-spans-install-runtime-and-architecture [IN] DERIVED

FIPS compliance in OpenShift is a cross-cutting constraint spanning three dimensions: install-time (must install from a FIPS-enabled RHEL machine), runtime (CRI-O propagates FIPS awareness to containers, SSH keys restricted to RSA/ECDSA), and architecture (validated only on x86_64, ppc64le, s390x — not ARM)

fips-mode-requires-fips-rhel-host [IN] OBSERVATION

Enabling FIPS mode for OpenShift installation requires running the installer from a RHEL machine already in FIPS mode.

fips-requires-fips-enabled-rhel [IN] OBSERVATION

FIPS mode for OCP installation requires the installer to run from a FIPS-enabled RHEL machine.

fips-supported-x86-ppc64le-s390x [IN] OBSERVATION

FIPS 140-2/140-3 validation applies to x86_64, ppc64le, and s390x architectures, and must be installed from a FIPS-enabled RHEL machine.

firmwareschema-defines-bios-constraints [IN] OBSERVATION

FirmwareSchema (metal3.io/v1alpha1) defines the schema for bare-metal firmware settings, including attribute types (Enumeration, Integer, String), allowable values, range bounds, and read-only flags.

firmwareschema-only-required-field-schema [IN] OBSERVATION

The only required field in FirmwareSchema .spec is schema, which maps firmware setting names to their schema definitions.

flexvolume-not-on-control-plane [IN] OBSERVATION

FlexVolume plugins are not supported on control plane nodes.

flowcollector-default-sampling-50 [IN] OBSERVATION

Default eBPF sampling rate is 50 (1-in-50 flows captured); value of 0 or 1 captures all flows

flowcollector-deployment-models [IN] OBSERVATION

FlowCollector supports two deployment models: Service (direct, default) and Kafka (high-throughput/low-latency)

flowcollector-ebpf-only-agent [IN] OBSERVATION

eBPF is the only supported agent type for flow collection in the Network Observability Operator (spec.agent.type: EBPF)

flowcollector-exporters-types [IN] OBSERVATION

FlowCollector exporters support Kafka, IPFIX, and OpenTelemetry simultaneously for enriched flow data export

flowcollector-kafka-tls-both-namespaces [IN] OBSERVATION

Kafka TLS certificates must be available in both netobserv (processor) and netobserv-privileged (eBPF agents) namespaces

flowcollector-must-be-named-cluster [IN] OBSERVATION

The FlowCollector custom resource must be named cluster and only one instance is allowed per cluster

flowcollector-name-always-cluster [IN] OBSERVATION

The FlowCollector custom resource is always named cluster and lives in the netobserv namespace

flowcollector-quick-filter-negation [IN] OBSERVATION

FlowCollector quick filter negation uses ! appended to the key name (e.g., src_namespace!)

flowcollector-singleton-named-cluster [IN] OBSERVATION

The FlowCollector custom resource is a singleton that must be named cluster

flowcollector-without-loki-savings [IN] OBSERVATION

Running Network Observability without Loki saves 20–65% memory and 10–30% CPU by relying on Prometheus only

flowdirection-values [IN] OBSERVATION

FlowDirection field values: 0=Ingress, 1=Egress, 2=Inner (same source and destination node)

flowmetric-api-group [IN] OBSERVATION

The FlowMetric custom resource uses API group flows.netobserv.io/v1alpha1

flowmetric-empty-valuefield-counts-flows [IN] OBSERVATION

When FlowMetric valueField is left empty, the metric counts flows rather than summing a specific field value

flowmetric-namespace-requirement [IN] OBSERVATION

FlowMetric resources must be created in the namespace defined in FlowCollector spec.namespace (default: netobserv)

flowmetric-netobserv-prefix [IN] OBSERVATION

FlowMetric-generated metrics are automatically prefixed with netobserv_ in Prometheus

flowmetric-ownername-over-name [IN] OBSERVATION

FlowMetric labels should prefer SrcK8SOwnerName/DstK8SOwnerName over SrcK8SName/DstK8SName to reduce Prometheus cardinality

flowmetric-three-metric-types [IN] OBSERVATION

FlowMetric supports three metric types: Counter (rates), Histogram (sampled values like latencies), and Gauge (point-in-time values)

flowschema-api-group [IN] OBSERVATION

FlowSchema belongs to API group flowcontrol.apiserver.k8s.io/v1 and is a cluster-scoped resource.

flowschema-distinguisher-types [IN] OBSERVATION

FlowSchema distinguisher method type is either ByUser or ByNamespace, determining how flows within the schema are separated.

flowschema-matching-precedence-default [IN] OBSERVATION

FlowSchema matchingPrecedence defaults to 1000 with valid range [1, 10000]; lower numeric value means higher logical priority (matched first).

flowschema-prioritylevel-apf-system [IN] OBSERVATION

FlowSchema and PriorityLevelConfiguration work together as the API Priority and Fairness (APF) system, which replaced max-in-flight request handling for the API server.

flowschema-prioritylevel-required [IN] OBSERVATION

priorityLevelConfiguration is the only required field in FlowSchema .spec, referencing the PriorityLevelConfiguration that controls queuing and concurrency limits for matched requests.

flowschema-rule-matching-logic [IN] OBSERVATION

A FlowSchema rule matches a request only if both a subject matches (User, Group, or ServiceAccount) and a resource or non-resource rule matches.

force-redeployment-requires-unique-string [IN] OBSERVATION

The forceRedeploymentReason field requires a unique string each time to trigger a new static pod rollout

forward-compatibility-only [IN] OBSERVATION

OCP provides forward compatibility only — applications built for 4.14 are not guaranteed to work on 4.13.

fsgroup-changes-ownership-sets-setgid [IN] OBSERVATION

When fsGroup is specified in a pod's securityContext, Kubernetes changes ownership of volume files to the specified GID and sets the setgid bit on directories.

gce-pd-max-128-per-node [IN] OBSERVATION

GCE Persistent Disk supports a maximum of 128 PDs per node (127 usable, 1 reserved for root).

gce-pd-types [IN] OBSERVATION

GCE Persistent Disk provisioner types are pd-standard (default) and pd-ssd.

gcp-kms-key-location-defaults-global [IN] OBSERVATION

GCP KMS key location in ClusterCSIDriver defaults to "global" if not set.

generation-zero-forces-reimport [IN] OBSERVATION

Setting the generation field to 0 on an image stream tag resets it to the latest stream generation, triggering a fresh re-import

generic-ephemeral-indirect-pvc-creation-security [IN] OBSERVATION

Users creating pods with generic ephemeral volumes can indirectly create PVCs even without explicit PVC create permissions — cluster admins should use admission webhooks to restrict this.

generic-ephemeral-no-offline-snapshot-resize [IN] OBSERVATION

Generic ephemeral volumes do not support offline snapshotting and resizing; Azure Disk CSI has no resize support and Cinder CSI has no snapshot support for ephemeral volumes.

generic-ephemeral-pod-owns-pvc [IN] OBSERVATION

The pod is the owner of auto-created ephemeral volume PVCs; Kubernetes garbage collector handles cleanup when the pod is deleted.

generic-ephemeral-pvc-naming-convention [IN] OBSERVATION

Generic ephemeral volume PVCs are named <pod-name>-<volume-name>; naming collisions in the same namespace can prevent pods from starting.

generic-ephemeral-volumes-defined-inline-pod-spec [IN] OBSERVATION

Generic ephemeral volumes are defined under volumes[].ephemeral.volumeClaimTemplate in the pod spec and follow the pod lifecycle (created/deleted with the pod).

generic-ephemeral-waitforfirstconsumer-recommended [IN] OBSERVATION

WaitForFirstConsumer volume binding mode is recommended for generic ephemeral volumes so the scheduler can pick an appropriate node.

get-infrastructure-id-command [IN] OBSERVATION

The command to retrieve the cluster infrastructure ID is oc get -o jsonpath='{.status.infrastructureName}{"\n"}' infrastructure cluster.

gitops-agent-multi-cluster [IN] OBSERVATION

The Argo CD Agent architecture enables agent-based GitOps communication between a control plane and remote workload clusters for multi-cluster synchronization.

gitops-applicationsets-non-control-plane-ns [IN] OBSERVATION

ApplicationSets can be managed in non-control-plane namespaces in OpenShift GitOps.

gitops-argo-rollouts-progressive-delivery [IN] OBSERVATION

Argo Rollouts provides progressive delivery (canary, blue-green deployments) integrated into the OpenShift GitOps workflow.

gitops-based-on-argocd [IN] OBSERVATION

Red Hat OpenShift GitOps is built on Argo CD and installed as an Operator via OLM.

gitops-cli-is-argocd-binary [IN] OBSERVATION

The GitOps CLI tool for OpenShift is the argocd binary, not a separate Red Hat-specific binary.

gitops-git-single-source-of-truth [IN] OBSERVATION

In GitOps workflows, Git repositories serve as the single source of truth for declarative infrastructure and application configuration, and an agent reconciles the live cluster to match.

gitops-handles-cd-pipelines-handles-ci [IN] OBSERVATION

OpenShift GitOps (Argo CD) handles continuous deployment (CD), while OpenShift Pipelines (Tekton) handles continuous integration (CI).

gitops-infra-node-support [IN] OBSERVATION

OpenShift GitOps control plane workloads can run on infrastructure nodes, avoiding worker entitlement consumption.

gitops-installed-via-operatorhub [IN] OBSERVATION

OpenShift GitOps is installed via OperatorHub as an Operator managed by OLM.

gitops-multicluster-declarative-cd [IN] OBSERVATION

OpenShift GitOps supports multicluster declarative continuous deployment across OpenShift and Kubernetes clusters, managing both infrastructure and application configuration.

gitops-multicluster-support [IN] OBSERVATION

OpenShift GitOps supports multicluster OpenShift and Kubernetes infrastructure management.

gitops-not-builtin-requires-install [IN] OBSERVATION

OpenShift GitOps is an Operator that must be installed separately — it is not a built-in platform component.

gitops-operator-built-on-argocd [IN] OBSERVATION

OpenShift GitOps is an Operator built on Argo CD that provides declarative GitOps workflows for Kubernetes-based infrastructure and applications.

gitops-separate-release-cadence [IN] OBSERVATION

OpenShift GitOps releases on a different cadence from OpenShift Container Platform itself.

gitops-three-app-creation-methods [IN] OBSERVATION

Argo CD applications can be created via the Argo CD dashboard, the oc CLI, or the argocd GitOps CLI.

gitops-ztp-primary-mechanism-edge [IN] OBSERVATION

GitOps ZTP is the Red Hat-recommended approach for provisioning and managing edge clusters at scale in OpenShift.

gitops-ztp-updated-independently [IN] OBSERVATION

GitOps ZTP can be updated independently from the hub cluster, RHACM, and managed OpenShift clusters.

governance-controls-image-supply-chain [IN] DERIVED

The end-to-end image supply chain (build→ImageStream→registry for apps, FBC→OLM→CSV for operators) operates entirely within OpenShift's governance model: identity management controls who can push/pull/prune images, RBAC governs ImageStream access via get-layers permissions, and namespace-scoped quotas constrain resource consumption — making image delivery a governed pipeline, not an open one.

governance-spans-identity-resources-and-namespaces [IN] DERIVED

OpenShift governance operates across three reinforcing layers: identity management (OAuth → User → Identity chain), resource access control (dual auth systems + quota enforcement), and namespace provisioning (self-service with admin disable controls and custom templates), ensuring no resource is accessible without passing through all three gates.

governed-immutable-image-and-operator-platform [IN] DERIVED

Both application images and operator packages flow through governed supply chains (build→ImageStream→registry and FBC→OLM→CSV respectively) that terminate in an immutable node platform managed by singleton operators — no software executes without passing through a managed pipeline.

gpu-operator-required-for-gpu-support [IN] OBSERVATION

GPU support in OpenShift requires installing a GPU Operator; it is not built into the platform by default.

gpu-operators-installed-via-olm [IN] OBSERVATION

GPU Operators are installed via the Operator Lifecycle Manager (OLM).

gpu-scheduling-resource-name [IN] OBSERVATION

GPU workloads use extended resource requests (e.g., nvidia.com/gpu) for pod scheduling to GPU-equipped nodes.

gpu-support-via-operators [IN] OBSERVATION

GPU support in OpenShift is delivered through Operators (e.g., NVIDIA GPU Operator), not manual driver installation.

graceful-restart-order-control-plane-first [IN] OBSERVATION

During a graceful cluster restart, control plane nodes must come up first, then worker nodes.

group-api-user-openshift-io-v1 [IN] OBSERVATION

The Group resource (user.openshift.io/v1) is a cluster-scoped OpenShift-specific resource; its only required field is users (string array of usernames).

groups-recommended-over-individual-bindings [IN] OBSERVATION

Groups are the recommended way to manage access at scale rather than binding roles to individual users.

hardware-accelerators-scoped-to-openshift-ai [IN] OBSERVATION

Hardware accelerators documentation in OpenShift is specifically scoped to AI/ML use cases via Red Hat OpenShift AI.

hardware-enablement-via-nfd-kmm-operators [IN] OBSERVATION

OpenShift enables specialized hardware (GPUs, FPGAs, NICs) through Node Feature Discovery (NFD), the Kernel Module Management (KMM) Operator, and driver containers rather than manual kernel-level configuration.

hardware-networks-are-secondary-networks [IN] OBSERVATION

Hardware networks (e.g., SR-IOV) are configured as additional secondary networks via Multus CNI using NetworkAttachmentDefinition resources, not as replacements for the primary cluster network.

hardware-networks-are-secondary-not-primary [IN] OBSERVATION

Hardware networks (SR-IOV) are configured as additional (secondary) pod networks via Multus NetworkAttachmentDefinitions, not as the primary cluster network.

hardwaredata-api-group-metal3io-v1alpha1 [IN] OBSERVATION

HardwareData is a custom resource under the metal3.io/v1alpha1 API group

hardwaredata-created-by-host-inspection [IN] OBSERVATION

HardwareData is created automatically as a result of bare-metal host inspection (introspection), not manually by users in typical workflows

hardwaredata-dual-stack-nic-separate-entries [IN] OBSERVATION

In dual-stack environments, NIC entries in HardwareData produce separate entries per IP address (one per IP family)

hardwaredata-is-namespaced [IN] OBSERVATION

HardwareData is a namespaced resource, not cluster-scoped

hardwaredata-ram-mebibytes-cpu-mhz-nic-gbps [IN] OBSERVATION

HardwareData measures RAM in mebibytes (MiB), CPU clock speed in megahertz (MHz), and NIC speed in gigabits per second (Gbps)

hardwaredata-storage-type-hdd-ssd-nvme [IN] OBSERVATION

HardwareData storage type field values are HDD, SSD, and NVME; the rotational boolean is deprecated in favor of type

hcp-adding-idp-removes-kubeadmin [IN] OBSERVATION

Adding any identity provider to a hosted cluster's OAuth configuration removes the default kubeadmin user provider.

hcp-api-resources-hostedcluster-nodepool [IN] OBSERVATION

HCP uses HostedCluster and NodePool API resources from the hypershift.openshift.io API group (not openshift-install).

hcp-auto-import-default [IN] OBSERVATION

Hosted clusters are automatically imported into the local multicluster engine Operator when the hosted control plane becomes available — this is the default behavior.

hcp-aws-destroy-five-params [IN] OBSERVATION

AWS hosted cluster destruction requires five parameters: --name, --infra-id, --role-arn, --sts-creds, --base-domain

hcp-aws-etcd-snapshot-requires-api-downtime [IN] OBSERVATION

On AWS, taking an etcd snapshot requires API downtime — kube-apiserver, openshift-apiserver, and openshift-oauth-apiserver must be scaled to 0 replicas first

hcp-aws-kubevirt-delete-managedcluster-first [IN] OBSERVATION

On AWS and OpenShift Virtualization, the managed cluster resource must be deleted (oc delete managedcluster) before destroying the hosted cluster

hcp-bare-metal-manual-cleanup-without-render [IN] OBSERVATION

Bare metal hosted clusters created without --render/--render-sensitive flags require manual backend resource cleanup during destruction

hcp-cco-manual-mode-only-aws [IN] OBSERVATION

The Cloud Credential Operator (CCO) for hosted clusters on AWS supports manual mode only — this is the default and only supported mode.

hcp-cco-sts-operator-annotation [IN] OBSERVATION

Operators declare support for CCO/STS in hosted control planes with the CSV annotation features.operators.openshift.io/token-auth-aws: "true".

hcp-cluster-name-unique-clusters-reserved [IN] OBSERVATION

Hosted cluster names must be unique cluster-wide; the name clusters is reserved and cannot be used

hcp-clusterversion-ignored [IN] OBSERVATION

ClusterVersion resource changes are ignored in hosted clusters — updates are driven through HostedCluster and NodePool .spec.release.image.

hcp-control-plane-namespace-pattern [IN] OBSERVATION

The hosted control plane namespace follows the pattern ${HOSTEDCLUSTERNAMESPACE}-${CLUSTER_NAME} (e.g., clusters-my-cluster)

hcp-control-plane-node-updates-independent [IN] OBSERVATION

In hosted control planes, control plane and node pool updates are independent — unlike standalone OCP where they are coupled.

hcp-control-plane-on-mgmt-data-plane-on-workers [IN] OBSERVATION

In hosted control planes, the control plane runs on the management cluster (managed by Control Plane Operator) and the data plane runs on the hosted cluster workers (managed by HostedClusterConfig Operator)

hcp-control-plane-runs-as-pods [IN] OBSERVATION

Hosted control planes run control plane components (etcd, API server, controller manager, VPN) as pods on a management cluster, not on dedicated machines.

hcp-control-plane-update-two-steps [IN] OBSERVATION

Updating a hosted control plane requires two steps: (1) annotate HostedCluster with hypershift.openshift.io/force-upgrade-to, (2) patch spec.release.image.

hcp-create-cluster-platforms [IN] OBSERVATION

The hcp create cluster command supports three platforms: aws, agent, and kubevirt.

hcp-custom-cert-path-named-certificates [IN] OBSERVATION

Custom API server certificates for hosted control planes are configured at spec.configuration.apiServer.servingCerts.namedCertificates in the HostedCluster resource.

hcp-custom-kubeconfig-secret-naming [IN] OBSERVATION

When kubeAPIServerDNSName is set on a HostedCluster, the HyperShift Operator generates a custom kubeconfig secret named <cluster_name>-custom-admin-kubeconfig.

hcp-decouples-control-plane-data-plane [IN] OBSERVATION

Hosted control planes decouple the control plane from the data plane — the hosting cluster runs control plane pods while worker nodes run separately.

hcp-decouples-control-plane-from-data-plane [IN] OBSERVATION

Hosted control planes decouple the control plane from the data plane — the control plane runs on the management cluster while worker nodes run separately.

hcp-default-cidr-ranges [IN] OBSERVATION

HCP default CIDR ranges: 100.65.0.0/16 (OVN-Kubernetes internal), 10.132.0.0/14 (pod/cluster network), 172.31.0.0/16 (service network).

hcp-default-metrics-set-telemetry [IN] OBSERVATION

The default metrics set for hosted control planes is Telemetry (the smallest set).

hcp-default-namespace-clusters [IN] OBSERVATION

The default namespace for hosted clusters is clusters.

hcp-default-tuned-profile-openshift-node [IN] OBSERVATION

The default TuneD profile in HCP is openshift-node when no custom profiles are defined

hcp-destroy-subcommand-per-platform [IN] OBSERVATION

The hcp destroy cluster subcommand varies by platform: aws, kubevirt, or agent

hcp-differs-from-standalone-in-machine-management [IN] DERIVED

Hosted control planes use distinct machine management patterns: NodePool replaces MachineSet/MHC, autoRepair replaces MachineHealthCheck, and upgrade strategies (Replace vs In-place) are NodePool-level settings.

hcp-disable-auto-import-config [IN] OBSERVATION

Disabling auto-import of hosted clusters uses autoImportDisabled: "true" in the hypershift-addon-deploy-config AddonDeploymentConfig in the multicluster-engine namespace.

hcp-disconnected-rhcos-manual-mirror [IN] OBSERVATION

In disconnected environments, RHCOS images must be manually mirrored because oc-mirror does not automatically mirror them; an ImageDigestMirrorSet is used to configure the mirror.

hcp-diverges-from-standalone-machine-and-provisioning [IN] DERIVED

Hosted control planes and standalone clusters use fundamentally different machine management: standalone uses MachineSet/MHC with BMC-based bare metal provisioning, while HCP replaces these with NodePool/autoRepair and runs control planes as pods — two incompatible operational models under the same platform.

hcp-dual-stack-disconnected-tech-preview [IN] OBSERVATION

Dual-stack networking for hosted control planes in disconnected environments is Technology Preview only — not supported for production

hcp-enabled-by-default-in-mce [IN] OBSERVATION

Hosted control planes (HCP) is enabled by default in the multicluster engine Operator.

hcp-encryption-key-saved-separately-for-dr [IN] OBSERVATION

The secret encryption key (spec.secretEncryption.aescbc) must be saved separately from the etcd snapshot for disaster recovery to a new cluster

hcp-etcd-encryption-secretencryption-field [IN] OBSERVATION

In HCP, etcd encryption is configured via the SecretEncryption field on the HostedCluster resource (supporting AES-CBC or KMS for AWS), unlike standalone OCP which uses the APIServer resource.

hcp-etcd-runs-as-3-member-statefulset [IN] OBSERVATION

In hosted control planes, etcd runs as a 3-member StatefulSet with individual PVCs (data-etcd-0, data-etcd-1, data-etcd-2), not as static pods on control plane nodes

hcp-etcd-runs-as-pod-on-management-cluster [IN] OBSERVATION

Each hosted cluster's etcd runs as a pod on the management cluster rather than on dedicated control plane nodes.

hcp-etcd-uses-pvcs [IN] OBSERVATION

In hosted control planes, etcd uses Persistent Volume Claims for storage (not local node storage) and is managed by the Control Plane Operator.

hcp-etcdutl-not-etcdctl-for-restore [IN] OBSERVATION

etcdutl snapshot restore (not etcdctl) is used for restoring etcd snapshots in HCP, with --skip-hash-check

hcp-featuregate-path-spec-configuration [IN] OBSERVATION

Feature gates on hosted clusters are configured at spec.configuration.featureGate.featureSet in the HostedCluster CR on the management cluster

hcp-featuregate-set-on-mgmt-cluster-cr [IN] OBSERVATION

Feature gates for hosted clusters are set by editing the HostedCluster CR on the management cluster, not by editing resources on the hosted cluster directly

hcp-force-rollout-restart-date-annotation [IN] OBSERVATION

After etcd restore, a manual rollout is triggered using the hypershift.openshift.io/restart-date annotation on the HostedCluster resource

hcp-ha-control-plane-resource-requirements [IN] OBSERVATION

A highly available hosted control plane consists of 78 pods requiring approximately 5.5 vCPUs, 19 GiB memory, and three 8 GiB PVs for etcd.

hcp-hostedcluster-api-group-hypershift-v1beta1 [IN] OBSERVATION

The HostedCluster CR uses the API group hypershift.openshift.io/v1beta1

hcp-htpasswd-request-header-no-nodepool-required [IN] OBSERVATION

htpasswd and request-header are the only identity providers that do not require NodePool replicas configured in advance (other providers need worker nodes for DNS resolution).

hcp-hypershift-operator-in-mce [IN] OBSERVATION

The HyperShift Operator is included in the multicluster engine (MCE) for Kubernetes Operator; MCE is installed with RHACM or standalone from OperatorHub.

hcp-ibm-power-cluster-grace-period [IN] OBSERVATION

The --cluster-grace-period flag is used with hcp destroy cluster agent on IBM Power to specify destruction timeout

hcp-ibmz-kvm-auto-detach-zvm-lpar-manual [IN] OBSERVATION

On IBM Z, scaling NodePool to 0 auto-detaches compute nodes only with KVM; z/VM and LPAR require manual compute node deletion

hcp-icsp-idms-restarts-kubelet-not-node [IN] OBSERVATION

Applying ICSP/IDMS triggers a MachineConfig change that restarts kubelet (not the entire node) on each node

hcp-idms-icsp-mgmt-imagecontentsource-hosted [IN] OBSERVATION

IDMS/ICSP applies to the management cluster; ImageContentSource in the hosted cluster spec is translated to IDMS on the hosted cluster

hcp-ignition-version-3-2-0 [IN] OBSERVATION

MachineConfig objects in HCP use Ignition version 3.2.0

hcp-integrates-with-acm-mce [IN] OBSERVATION

Hosted control planes integrate with Red Hat Advanced Cluster Management (ACM) / Multicluster Engine (MCE) for lifecycle management.

hcp-klusterlet-deploy-mode-hosted-annotation [IN] OBSERVATION

The annotation import.open-cluster-management.io/klusterlet-deploy-mode: Hosted is required when manually importing a hosted cluster.

hcp-klusterletaddonconfig-rhacm-only [IN] OBSERVATION

KlusterletAddonConfig is only needed when RHACM is installed, not for MCE-only deployments.

hcp-konnectivity-api-server-to-node [IN] OBSERVATION

In HCP, API server-to-node communication uses Konnectivity (not direct communication), since control plane and workers are in different VPCs.

hcp-kubevirt-container-oc-mirror-v2-only [IN] OBSERVATION

The kubeVirtContainer: true flag in ImageSetConfiguration mirrors the RHCOS boot container disk image and is available only in oc-mirror v2

hcp-kubevirt-ingress-dns-pattern [IN] OBSERVATION

Default ingress DNS for KubeVirt hosted clusters follows the pattern *.apps.<hostedclustername>.apps.<mgmtclusterdomain>

hcp-kubevirt-ingress-https-only-port-443 [IN] OBSERVATION

Default hosted cluster ingress for KubeVirt only supports HTTPS on port 443; plain HTTP on port 80 is rejected

hcp-kubevirt-provision-time-10-15-min [IN] OBSERVATION

A KubeVirt hosted cluster typically takes 10–15 minutes to fully provision

hcp-kubevirt-requires-bare-metal-mgmt [IN] OBSERVATION

KubeVirt-based hosted control planes require the management cluster to run on bare metal

hcp-machineconfig-wrapped-in-configmap [IN] OBSERVATION

Machine configuration objects (MachineConfig, KubeletConfig, Tuned) must be embedded inside a ConfigMap in the management cluster's clusters namespace to be applied in HCP

hcp-managed-via-hypershift-operator [IN] OBSERVATION

Hosted control planes are powered by the HyperShift operator and managed via the hcp CLI and CRDs (HostedCluster, NodePool).

hcp-management-cluster-min-3-workers [IN] OBSERVATION

A hosted control planes management cluster requires at least 3 worker nodes; single-node OpenShift is not supported as a management cluster.

hcp-management-cluster-version-support-n-minus-3 [IN] OBSERVATION

A management cluster on OCP 4.17 can deploy hosted clusters at versions 4.17, 4.16, 4.15, and 4.14 (current version plus two previous minor versions, totaling n-3).

hcp-max-latency-200ms [IN] OBSERVATION

Maximum supported latency between a management cluster and hosted clusters is 200 ms.

hcp-maxpods-density-tuning [IN] OBSERVATION

Default maxPods of 250 allows ~3 hosted control planes per node; increasing to 500 via KubeletConfig allows more density.

hcp-mce-minor-upgrade-updates-hypershift-patch-does-not [IN] OBSERVATION

Upgrading MCE minor version updates the HyperShift Operator; upgrading MCE patch/z-stream does not update HyperShift.

hcp-mce-supports-n-plus-1-to-n-minus-2 [IN] OBSERVATION

The multicluster engine Operator manages hosted clusters from n+1 to n-2 OCP versions where n is the current minor version.

hcp-metrics-set-env-var [IN] OBSERVATION

The metrics set is configured via the METRICS_SET environment variable on the HyperShift Operator deployment in the hypershift namespace.

hcp-mgmt-failure-impact-workloads-continue [IN] OBSERVATION

In HCP, management cluster control plane failure alone does not impact running workloads — only combined control plane and worker node failure makes the API unavailable (data plane stays available)

hcp-mixed-infra-requires-publicandprivate [IN] OBSERVATION

Mixed infrastructure hosted control planes (e.g., management on AWS, workers on-premise) require the PublicAndPrivate publishing strategy.

hcp-monitoring-dashboards-configmap-naming [IN] OBSERVATION

HCP monitoring dashboard ConfigMaps are created in openshift-config-managed namespace with naming pattern cp-<namespace>-<name>, and deleting a hosted cluster automatically deletes its dashboard.

hcp-monitoring-dashboards-install-flags [IN] OBSERVATION

Monitoring dashboards are enabled via the hypershift-operator-install-flags ConfigMap in the local-cluster namespace with --monitoring-dashboards flag.

hcp-must-gather-image-from-mce [IN] OBSERVATION

The must-gather image for hosted control planes is registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version>, not the standard OCP must-gather image.

hcp-no-machine-config-operator [IN] OBSERVATION

The Machine Config Operator does not exist in hosted control planes; machine configuration is applied via ConfigMap referenced in NodePool's spec.config.

hcp-no-machineconfigpool-uses-nodepool [IN] OBSERVATION

In hosted control planes, MachineConfigPool does not exist; NodePool is used instead for managing node configuration

hcp-node-labels-lost-on-upgrade-unless-inplace [IN] OBSERVATION

In HCP, node labels do not persist during upgrades unless spec.management.upgradeType is set to InPlace on the NodePool

hcp-nodehealthcheck-must-pause-before-update [IN] OBSERVATION

NodeHealthCheck remediation must be manually paused (via pauseRequests field) before updating hosted clusters because it cannot detect CVO status in hosted control planes.

hcp-nodepool-autorepair-spec [IN] OBSERVATION

Machine health checks in HCP use .spec.management.autoRepair on NodePool (not MachineHealthCheck resource).

hcp-nodepool-autoscaling-spec [IN] OBSERVATION

Autoscaling in HCP is configured via spec.autoScaling on NodePool (not ClusterAutoscaler/MachineAutoscaler).

hcp-nodepool-replaces-machinesets-autoscaler-healthcheck [IN] OBSERVATION

NodePool replaces MachineSets, MachineAutoscaler, MachineHealthCheck, and MachineConfigPool concepts from standalone OCP.

hcp-nodepool-spec-config-vs-tuningconfig [IN] OBSERVATION

NodePool spec.config references ConfigMaps containing MachineConfig/KubeletConfig; spec.tuningConfig references ConfigMaps containing Tuned objects — these are separate fields

hcp-nodepool-upgrade-types-replace-inplace [IN] OBSERVATION

Node pool upgrade types are Replace (re-provisions nodes, suited for cloud) and In-place (updates OS on existing instances, suited for bare metal); the type is immutable after node pool creation.

hcp-nodepool-version-cannot-exceed-control-plane [IN] OBSERVATION

Node pool version must not surpass the hosted control plane version per Kubernetes version skew policy.

hcp-oauth-configured-in-hostedcluster-cr [IN] OBSERVATION

OAuth for hosted clusters is configured in spec.configuration.oauth of the HostedCluster CR, not in a separate OAuth CR.

hcp-olm-management-mode-no-icsp-overrides [IN] OBSERVATION

When OLM catalogs use management (default) placement mode, ICSP overrides are not automatically applied to the OLM catalog image stream — requires manual annotation

hcp-pause-reconciliation-for-backup-restore [IN] OBSERVATION

Before performing etcd backup/restore operations on a hosted cluster, reconciliation must be paused with spec.pausedUntil: "true" and resumed afterward with "null"

hcp-registry-ca-two-places [IN] OBSERVATION

Registry CA certificates for disconnected HCP must be configured in two places: the management cluster (image.config.openshift.io additionalTrustedCA) and the hosted cluster workers (spec.additionalTrustBundle referencing a user-ca-bundle ConfigMap)

hcp-remote-hub-updates-local-mce-only [IN] OBSERVATION

Updates to hosted clusters imported into a remote RHACM hub must be done on the local MCE where the cluster is hosted, not through the remote hub.

hcp-replace-and-inplace-upgrades [IN] OBSERVATION

HCP supports both replace and in-place upgrade types for node pools; standalone OCP supports only in-place.

hcp-requires-distinct-operational-playbook [IN] DERIVED

Hosted control planes require a fundamentally different operational playbook from standalone clusters: machine management uses NodePool instead of MachineSet/MHC, ClusterVersion is ignored in favor of HostedCluster CR for updates, the web console cannot show control plane status or manage machines, and etcd restore uses a restart-date annotation — making standalone operational procedures largely inapplicable.

hcp-requires-multicluster-engine-not-rhacm [IN] OBSERVATION

Hosted control planes require multicluster engine for Kubernetes Operator; RHACM is optional and not required.

hcp-restart-via-annotation [IN] OBSERVATION

To restart all hosted control plane components, annotate the HostedCluster resource with hypershift.openshift.io/restart-date; the value is treated as a string, not a timestamp.

hcp-san-no-conflict-with-api-int [IN] OBSERVATION

Custom API server certificate SANs must not conflict with the internal API endpoint (api-int), except on AWS with Private or PublicAndPrivate publishing strategies.

hcp-service-publishing-strategy-immutable [IN] OBSERVATION

The service publishing strategy for hosted control planes is immutable after cluster creation.

hcp-single-control-plane-operator [IN] OBSERVATION

HCP uses a single Control Plane Operator that replaces the many individual operators used in standalone OCP control planes.

hcp-sizing-override-configmap [IN] OBSERVATION

HCP resource utilization can be overridden via a ConfigMap named hcp-sizing-baseline in the local-cluster namespace.

hcp-sts-token-path [IN] OBSERVATION

The web identity token path for STS in hosted control planes is /var/run/secrets/openshift/serviceaccount/token.

hcp-supported-platforms [IN] OBSERVATION

Hosted control planes support bare metal (Agent provider), OpenShift Virtualization, AWS, IBM Z, and IBM Power as platforms.

hcp-supported-versions-configmap-hypershift-ns [IN] OBSERVATION

The supported-versions ConfigMap is created by the HyperShift Operator in the hypershift namespace with label hypershift.openshift.io/supported-versions: "true".

hcp-techpreviewnoupgrade-irreversible-blocks-updates [IN] OBSERVATION

Enabling TechPreviewNoUpgrade feature set on a hosted cluster is irreversible and prevents minor version updates

hcp-three-metrics-sets [IN] OBSERVATION

Hosted control planes support three metrics sets: Telemetry (default, smallest), SRE (alerting/troubleshooting), and All (every metric standalone OCP produces).

hcp-tls-secret-on-management-cluster [IN] OBSERVATION

Custom TLS certificate secrets for hosted cluster API servers are created on the management cluster, not within the hosted cluster itself.

hcp-tuned-cr-name-hash-appended [IN] OBSERVATION

The Node Tuning Operator appends a hash of the node pool name and namespace to Tuned CR names to avoid collisions across node pools

hcp-update-order-management-mce-hosted [IN] OBSERVATION

HCP update order is strict: (1) management cluster OCP, (2) multicluster engine Operator, (3) hosted cluster and node pools.

hcp-web-console-limitations [IN] OBSERVATION

The web console for hosted clusters cannot show control plane status, manage machines, or perform cluster updates.

hcp-wildcard-dns-required-for-ingress [IN] OBSERVATION

Wildcard DNS routes (WildcardsAllowed on the IngressController) must be enabled on the infrastructure cluster for default Ingress behavior on OpenShift Virtualization hosted clusters.

hcp-worker-notready-15min-threshold [IN] OBSERVATION

Worker nodes in NotReady state during hosted cluster creation is normal while the networking stack rolls out, but should not persist beyond approximately 15 minutes.

helm-and-template-dual-packaging-model [IN] DERIVED

OpenShift provides two parallel application packaging mechanisms: Helm charts (cluster-scoped and project-scoped repositories, chart/release/revision lifecycle) and Templates (cluster-wide availability via the openshift namespace, labels applied to all generated objects) — both enabling repeatable application instantiation with different scope models.

helm-chart-release-revision-definitions [IN] OBSERVATION

In Helm, a chart is a packaging format, a release is a running instance of a chart, and a revision is an incremental snapshot created on install, upgrade, or rollback.

helm-chart-yaml-apiv2-for-helm3 [IN] OBSERVATION

Chart.yaml apiVersion must be v2 for Helm 3 charts.

helm-default-chart-repo-url [IN] OBSERVATION

Red Hat provides a default Helm chart repository at https://charts.openshift.io/.

helm-namespace-scoped-repos-no-cluster-admin [IN] OBSERVATION

Namespace-scoped Helm chart repos (ProjectHelmChartRepository) require appropriate RBAC permissions but not cluster-admin.

helm-private-repo-ca-cert-openshift-config [IN] OBSERVATION

CA certificates for private Helm chart repos are stored as ConfigMaps in the openshift-config namespace with key ca-bundle.crt.

helm-removing-all-repos-hides-ui [IN] OBSERVATION

Removing all Helm chart repositories (cluster and namespace level) hides the Helm option from the Developer Console UI.

helm-two-repo-crd-kinds [IN] OBSERVATION

OpenShift has two CRD kinds for Helm chart repos: HelmChartRepository (cluster-scoped) and ProjectHelmChartRepository (namespace-scoped), both using API group helm.openshift.io/v1beta1.

helmchartrepo-ca-tls-in-openshift-config [IN] OBSERVATION

HelmChartRepository CA ConfigMaps and TLS Secrets must reside in the openshift-config namespace, with keys ca-bundle.crt, tls.crt, and tls.key.

helmchartrepo-cluster-scoped-v1beta1 [IN] OBSERVATION

HelmChartRepository is a cluster-scoped resource under API group helm.openshift.io/v1beta1 (Compatibility Level 2).

helmchartrepo-disabled-without-deleting [IN] OBSERVATION

Setting spec.disabled: true on a HelmChartRepository disables the repository without removing it.

high-node-utilization-replica-warning [IN] OBSERVATION

The HighNodeUtilization scheduler profile may place all replicas of a ReplicaSet on the same node

highly-privileged-projects-bypass-admission [IN] OBSERVATION

Projects default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label 0 or 1 bypass admission plugins including pod security admission, SCCs, cluster resource quotas, and image reference resolution.

hive-provisions-klusterlet-registers [IN] OBSERVATION

Hive provisions self-managed OCP clusters to the hub; the klusterlet agent registers managed clusters to the hub.

host-device-one-selector [IN] OBSERVATION

The host-device CNI plugin requires specifying a device by exactly one of: device, hwaddr, kernelpath, or pciBusID.

hosted-control-planes-based-on-hypershift [IN] OBSERVATION

Hosted control planes in OpenShift are based on the HyperShift upstream project and enable hyperscale cluster operations with centralized control planes.

hosted-control-planes-run-as-pods [IN] OBSERVATION

Hosted control planes (HCP) run control plane components (API server, etcd, controllers) as pods on a management cluster, eliminating the need for dedicated VMs/machines per control plane.

hostfirmwaresettings-api-group-metal3io-v1alpha1 [IN] OBSERVATION

HostFirmwareSettings belongs to API group metal3.io/v1alpha1 and is a namespaced resource

hostfirmwaresettings-conditions-track-schema-validation [IN] OBSERVATION

HostFirmwareSettings .status.conditions tracks schema validation of spec settings against a referenced FirmwareSchema resource, not host health

hostfirmwaresettings-spec-settings-only-required-field [IN] OBSERVATION

.spec.settings is the only required field in the HostFirmwareSettings spec

hostfirmwaresettings-spec-status-pattern [IN] OBSERVATION

HostFirmwareSettings uses a spec/status pattern: .spec.settings holds desired BIOS/firmware name/value pairs, .status.settings reflects actual firmware state

hostnetwork-requires-clusterfirstwithhostnet [IN] OBSERVATION

When using hostNetwork: true, dnsPolicy must be set to ClusterFirstWithHostNet to retain cluster DNS resolution.

hostprefix-23-gives-510-pod-ips [IN] OBSERVATION

A hostPrefix of 23 in clusterNetwork CIDR provides 510 pod IPs per node (2^(32-23) - 2).

hpa-api-group-autoscaling-v2 [IN] OBSERVATION

The HorizontalPodAutoscaler uses the autoscaling/v2 API group, which supports multiple metrics and custom metrics (v1 only supports CPU)

hpa-average-utilization-resource-only [IN] OBSERVATION

The averageUtilization target type is only valid for Resource metric source type (percentage of pod's resource request)

hpa-default-metric-80-percent-cpu [IN] OBSERVATION

When no metrics are specified in an HPA, it defaults to 80% average CPU utilization

hpa-five-metric-source-types [IN] OBSERVATION

HPA supports five metric source types: Resource, ContainerResource (requires HPAContainerMetrics feature gate), Pods, Object, and External

hpa-is-namespaced-resource [IN] OBSERVATION

HorizontalPodAutoscaler (HPA) is a namespaced resource that targets a scalable workload such as a Deployment or ReplicaSet.

hpa-multiple-metrics-max-wins [IN] OBSERVATION

When multiple metrics are defined in an HPA, the maximum calculated replica count across all metrics is used

hpa-policy-period-max-1800 [IN] OBSERVATION

HPA behavior policy periodSeconds maximum is 1800 seconds (30 min); selectPolicy defaults to Max

hpa-replica-calculation-formula [IN] OBSERVATION

HPA calculates desired replicas as: desiredReplicas = currentReplicas × (currentMetricValue / targetMetricValue)

hpa-required-fields-scaletargetref-maxreplicas [IN] OBSERVATION

HPA spec requires scaleTargetRef and maxReplicas; minReplicas defaults to 1

hpa-requires-metrics-source [IN] OBSERVATION

HorizontalPodAutoscaler (HPA) requires a metrics source (Metrics Server or Prometheus adapter) to function.

hpa-scale-to-zero-requirements [IN] OBSERVATION

HPA minReplicas: 0 requires both the HPAScaleToZero feature gate and at least one Object or External metric configured

hpa-stabilization-window-defaults [IN] OBSERVATION

HPA scale-down stabilization window defaults to 300 seconds (5 min); scale-up defaults to 0 seconds; maximum is 3600 seconds (1 hour)

hpa-v2-in-ocp417 [IN] OBSERVATION

HorizontalPodAutoscaler uses the autoscaling/v2 API in OCP 4.17, which supports custom and external metrics (not just CPU)

hpp-no-block-storage [IN] OBSERVATION

HostPath Provisioner (HPP) does not support block storage; LSO and LVM Storage do.

htpasswd-secret-key-htpasswd [IN] OBSERVATION

HTPasswd identity provider data is stored in a Secret with key htpasswd (not in a ConfigMap)

hub-template-configmap-changes-require-manual-sync [IN] OBSERVATION

ConfigMap changes are not automatically synced to existing policies — requires either deleting the policy or using the policy.open-cluster-management.io/trigger-update annotation.

hub-template-configmap-same-namespace-as-policy [IN] OBSERVATION

ConfigMaps referenced by hub templates must be in the same namespace as the generated policy.

hub-template-fromconfigmap-function [IN] OBSERVATION

The fromConfigMap function is the primary hub template function for pulling values from ConfigMaps, with syntax fromConfigMap "<namespace>" "<configmap-name>" "<key>".

hub-template-syntax-hub-delimiters [IN] OBSERVATION

RHACM hub cluster templates use {{hub ... hub}} delimiters (not standard Go {{ }}).

hub-template-toliteral-for-json-arrays [IN] OBSERVATION

The toLiteral pipe is required in hub templates when a ConfigMap value is a JSON array/object that should be interpreted as YAML structure rather than a string.

hw-networks-additional-interfaces-via-multus [IN] OBSERVATION

Hardware networks are consumed as additional/secondary network interfaces on pods via Multus CNI, alongside the primary OVN-Kubernetes cluster network

hw-offload-eswitchmode-switchdev [IN] OBSERVATION

Hardware offloading requires eSwitchMode: "switchdev" in the SriovNetworkNodePolicy with deviceType: netdevice (vfio-pci is not supported)

hw-offload-incompatible-with-dpdk [IN] OBSERVATION

Hardware offloading is not compatible with DPDK applications

hw-offload-requires-bare-metal-smartnic [IN] OBSERVATION

Hardware offloading in OpenShift requires bare metal nodes with SmartNICs and is not available on VMs

hw-offload-requires-ovn-kubernetes [IN] OBSERVATION

Hardware offloading requires the OVN-Kubernetes network plugin with gatewayConfig.routingViaHost set to false

hw-offload-sriov-systemd-mode [IN] OBSERVATION

The SR-IOV Operator must be set to configurationMode: "systemd" in the SriovOperatorConfig CR (named default) for hardware offloading

hw-offload-supported-traffic-types [IN] OBSERVATION

Hardware offloading supports only two communication types: pod-to-pod and pod-to-ClusterIP-service (backed by regular pods)

hw-offload-without-pod-config-decreases-throughput [IN] OBSERVATION

Enabling hardware offloading on a node without configuring pods to use it results in decreased throughput

ibi-cluster-service-network-immutable [IN] OBSERVATION

The clusterNetwork and serviceNetwork settings from the seed cluster are baked into the seed image and cannot be changed after seed image creation.

ibi-dual-stack-not-supported [IN] OBSERVATION

Dual-stack networking is not supported for image-based installation (IBI) in OCP 4.17.

ibi-lifecycle-agent-namespace [IN] OBSERVATION

The Lifecycle Agent is installed in the openshift-lifecycle-agent namespace.

ibi-seed-image-is-oci-container [IN] OBSERVATION

The IBI seed image is an OCI container image (not a disk image), generated from a seed cluster using the Lifecycle Agent.

ibi-seed-target-must-match-cpu-topology [IN] OBSERVATION

Seed and target clusters for IBI must match on CPU topology (architecture, core count, tuned performance config), IP version, disconnected registry (yes/no), FIPS config, and proxy (enabled/disabled).

ibi-shared-partition-machineconfig-install-time [IN] OBSERVATION

The shared container partition MachineConfig for IBI must be applied at installation time of the seed cluster.

ibi-two-phase-installation-deployment [IN] OBSERVATION

Image-based installation (IBI) separates installation (preinstalling at central site) from deployment (reconfiguring at remote site) as two distinct phases.

ibi-var-lib-containers-minimum-500gb [IN] OBSERVATION

The shared /var/lib/containers partition on the seed cluster requires a minimum of 500 GB and must be a dedicated partition shared between ostree stateroots.

ibm-cloud-bare-metal-classic-supported-platform [IN] OBSERVATION

IBM Cloud Bare Metal (Classic) is a supported installation platform for OpenShift Container Platform.

ibm-cloud-classic-distinct-from-vpc [IN] OBSERVATION

IBM Cloud Bare Metal (Classic) is distinct from IBM Cloud VPC, IBM Power, and IBM Z/LinuxONE as separate installation targets.

ibm-cloud-classic-vs-vpc-distinct-install-paths [IN] OBSERVATION

IBM Cloud has distinct installation paths: Bare Metal (Classic), VPC, and IBM Power Virtual Server, each with separate documentation.

ibm-cloud-supported-install-target-ocp417 [IN] OBSERVATION

IBM Cloud (VPC) is a supported installation target for OpenShift Container Platform 4.17.

ibm-power-architecture-ppc64le-no-heterogeneous [IN] OBSERVATION

IBM Power uses the ppc64le architecture and heterogeneous clusters are not supported — all machine pools must use the same architecture.

ibm-power-two-install-methods [IN] OBSERVATION

IBM Power has exactly two installation methods: standard (internet-connected) and restricted/disconnected network (using an internal mirror of release content).

ibm-power-typically-upi [IN] OBSERVATION

IBM Power installations typically require user-provisioned infrastructure (UPI) rather than installer-provisioned infrastructure (IPI).

ibm-power-upi-only-no-ipi [IN] OBSERVATION

IBM Power supports only user-provisioned infrastructure (UPI) installations — IPI is not available.

ibm-powervc-openstack-based [IN] OBSERVATION

IBM PowerVC (Power Virtualization Center) is built on OpenStack and provides virtualization management for IBM Power Systems.

ibm-z-deployment-targets-zvm-lpar-kvm [IN] OBSERVATION

IBM Z deployments can run on z/VM, LPAR (Logical Partitions), or KVM on IBM Z.

ibm-z-power-openshift-virt-unsupported [IN] OBSERVATION

OpenShift Virtualization is unsupported on IBM Z and IBM Power platforms.

ibm-z-storage-dasd-or-fcp-scsi [IN] OBSERVATION

IBM Z installations use platform-specific disk provisioning via DASD or FCP/SCSI.

ibm-z-upi-only-no-ipi [IN] OBSERVATION

IBM Z installations use User-Provisioned Infrastructure (UPI) only — IPI is not available for the IBM Z platform.

ibmcloud-cco-manual-mode-only [IN] OBSERVATION

IBM Cloud requires credentialsMode: Manual for the Cloud Credential Operator (CCO) — it is the only supported credentials mode because IBM Cloud does not support storing administrator-level credential secrets in kube-system.

ibmcloud-ccoctl-delete-service-id-post-destroy [IN] OBSERVATION

After openshift-install destroy cluster on IBM Cloud, CCO credentials must be separately deleted using ccoctl ibmcloud delete-service-id as a manual step.

ibmcloud-five-install-variants [IN] OBSERVATION

IBM Cloud supports five IPI installation variants: customized cluster, network customizations, existing VPC, private cluster on existing VPC, and restricted network (air-gapped).

ibmcloud-ic-api-key-env-var [IN] OBSERVATION

The environment variable ICAPIKEY must be set (by exact name) before running openshift-install destroy cluster on IBM Cloud — the installer uses it to remove service IDs.

ibmcloud-ipi-only [IN] OBSERVATION

IBM Cloud supports only installer-provisioned infrastructure (IPI) for OpenShift installation — user-provisioned infrastructure (UPI) is not supported.

ibmcloud-only-ipv4-supported [IN] OBSERVATION

Only IPv4 addresses are supported for networking on IBM Cloud OpenShift installations.

ibmcloud-pvcs-not-auto-removed [IN] OBSERVATION

PVCs created after cluster deployment are not automatically removed during openshift-install destroy cluster on IBM Cloud.

ibmcloud-resource-group-uninstall-behavior [IN] OBSERVATION

On cluster uninstall, installer-created resource groups are deleted while user-provided resource groups are preserved (only installer-provisioned resources within them are removed).

ibmcloud-subnet-names-not-ids [IN] OBSERVATION

Only subnet names (not IDs) are supported for computeSubnets and controlPlaneSubnets in IBM Cloud install-config.yaml.

ibmcloud-uninstall-requires-metadata-json [IN] OBSERVATION

The metadata.json file in the installation directory is required for cluster deletion via openshift-install destroy cluster.

icsp-api-group-alpha [IN] OBSERVATION

ICSP uses API group operator.openshift.io/v1alpha1 — it is an alpha-level API with no compatibility guarantees (Compatibility Level 4).

icsp-cluster-scoped-resource [IN] OBSERVATION

ImageContentSourcePolicy (ICSP) is a cluster-scoped resource with no namespace, applying globally across the cluster.

icsp-deprecated-in-favor-of-idms [IN] OBSERVATION

ICSP is deprecated starting in OCP 4.13 in favor of ImageDigestMirrorSet (IDMS), which provides the same digest-based mirroring with a stable API.

icsp-deprecated-replaced-by-idms-itms [IN] OBSERVATION

ImageContentSourcePolicy (ICSP) is deprecated and replaced by ImageDigestMirrorSet (IDMS) and ImageTagMirrorSet (ITMS) starting in OpenShift 4.13+

icsp-digest-only-mirroring [IN] OBSERVATION

ImageContentSourcePolicy (ICSP) mirrors only apply to images pulled by digest — images referenced by tag are always pulled from the original source repository.

icsp-key-usecase-disconnected-installs [IN] OBSERVATION

ICSP is essential for disconnected/air-gapped environments where images must be pulled from a local mirror rather than internet-facing registries.

icsp-multiple-policies-merge-mirrors [IN] OBSERVATION

When multiple ICSP objects define mirrors for the same source, mirror lists are merged preserving relative order where possible.

icsp-triggers-node-reboots-via-mco [IN] OBSERVATION

Applying or modifying an ICSP triggers the Machine Config Operator to update container runtime mirror configuration (/etc/containers/registries.conf) on nodes, causing rolling node reboots.

identity-api-group [IN] OBSERVATION

The Identity resource belongs to the user.openshift.io/v1 API group, not core Kubernetes.

identity-governed-software-delivery [IN] DERIVED

The complete software delivery pipeline (build→image→operator→console) is identity-governed end-to-end: the OAuth→Identity→Authorization chain controls who can build images, deploy operators, and access console plugins, while dual RBAC+SCC enforces what those actors can do at each pipeline stage.

identity-governs-operator-and-workload-access [IN] DERIVED

OpenShift identity and authorization governance controls both operator lifecycle and workload deployment: the complete OAuth→User→Identity→Authorization chain gates OLM operator installation (ClusterRole/ServiceAccount for InstallPlans) and workload pod admission (SCC evaluation), making identity the root of all platform access regardless of OLM generation.

identity-requires-providername-and-providerusername [IN] OBSERVATION

An Identity resource requires both providerName and providerUserName fields, which together uniquely identify an authentication record.

identity-session-and-authorization-complete [IN] DERIVED

OpenShift identity management forms a complete chain from authentication through session management to authorization: OAuth providers create User/Identity objects that map to sessions (OAuthAccessToken lifecycle with active revocation), which are then evaluated against dual authorization systems (OpenShift auth + K8s RBAC) — revoking a session invalidates all authorization decisions for that identity.

identity-to-authorization-governance-chain [IN] DERIVED

OpenShift provides end-to-end identity governance: the OAuth identity chain (provider → User → Identity → UserIdentityMapping) feeds into dual authorization systems (OpenShift auth + K8s RBAC with SCCs), creating a unified access control pipeline from authentication through authorization.

identity-user-reference-requires-name-and-uid [IN] OBSERVATION

The user field on an Identity object is an ObjectReference that requires both Name and UID to be set.

idms-digest-only-mirroring [IN] OBSERVATION

ImageDigestMirrorSet (IDMS) applies only to images referenced by digest (@sha256:...); ImageTagMirrorSet (ITMS) is the companion resource for tag-based pulls

idms-mirror-source-policy-never-contact [IN] OBSERVATION

IDMS and ITMS support mirrorSourcePolicy: NeverContactSource to block fallback to the original source registry, critical for fully disconnected environments

idms-most-specific-source-wins [IN] OBSERVATION

When multiple IDMS objects match an image pull spec, the most specific namespace match applies (e.g., quay.io/libpod/busybox wins over quay.io/libpod)

ignition-certs-expire-24-hours [IN] OBSERVATION

Ignition config files contain certificates that expire after 24 hours; best practice is to use them within 12 hours of generation.

ignition-configs-expire-24h [IN] OBSERVATION

Ignition certificates expire after 24 hours and auto-renew; Ignition configs should be used within 12 hours of generation

ignition-files-expire-24-hours [IN] OBSERVATION

Ignition configuration files expire after 24 hours — installation must begin within that window.

ignition-first-boot-only [IN] OBSERVATION

Ignition runs only on first boot from initramfs; it is declarative and machines cannot be partially configured. Subsequent OS changes go through the Machine Config Operator.

ignition-supports-raid-not-lvm [IN] OBSERVATION

Ignition supports RAID but does not support LVM for disk configuration.

image-additional-trusted-ca-in-openshift-config [IN] OBSERVATION

The additionalTrustedCA field on the Image config references a ConfigMap in the openshift-config namespace for custom CA bundles trusted during image operations.

image-allowed-blocked-registries-mutually-exclusive [IN] OBSERVATION

In the Image config resource, registrySources.allowedRegistries and registrySources.blockedRegistries are mutually exclusive — only one may be set.

image-allowed-registries-for-import-not-restrict-admins [IN] OBSERVATION

The allowedRegistriesForImport field does not restrict admin users who can directly create Images or ImageStreamMappings.

image-apis-are-openshift-specific [IN] OBSERVATION

Image APIs (Image, ImageStream, ImageStreamTag, ImageStreamImage, ImageStreamImport, ImageTag) are OpenShift-specific extensions that do not exist in vanilla Kubernetes.

image-apis-openshift-specific [IN] OBSERVATION

Image APIs (Image, ImageStream, ImageStreamTag, etc.) are OpenShift-specific extensions to the Kubernetes API, not available in vanilla Kubernetes

image-config-cr-name-cluster [IN] OBSERVATION

The cluster-wide image registry configuration CR is image.config.openshift.io/cluster (kind Image, name must be "cluster")

image-container-runtime-search-registries-crio-only [IN] OBSERVATION

The containerRuntimeSearchRegistries field in the Image config works only with CRI-O, not with builds or imagestream imports.

image-content-source-policy-v1alpha1-level4 [IN] OBSERVATION

ImageContentSourcePolicy is Compatibility level 4 (v1alpha1) with no compatibility guarantees, unlike most operator APIs which are level 1

image-external-registry-hostnames-first-entry-used [IN] OBSERVATION

The first entry in externalRegistryHostnames populates publicDockerImageRepository in ImageStreams.

image-governed-from-build-through-lifecycle [IN] DERIVED

OpenShift image governance spans the complete lifecycle: images flow through build systems and supply chains (S2I/Shipwright → ImageStream → registry for apps; FBC → OLM for operators) and are then subject to lifecycle controls (managed annotation for pruning eligibility, registry operator for automated cleanup) — the same governance model that controls creation also controls deletion.

image-layering-base-image-command [IN] OBSERVATION

The correct base RHCOS image for image layering is obtained with oc adm release info --image-for rhel-coreos.

image-layering-containerfile-must-end-ostree-commit [IN] OBSERVATION

All RHCOS image layering Containerfiles must end with ostree container commit after installing packages.

image-layering-custom-node-os [IN] OBSERVATION

Image layering is the supported method for adding custom content to RHCOS node OS images without building entirely custom images

image-layering-no-rt-kernel-extensions [IN] OBSERVATION

Realtime kernel or extensions RPMs must NOT be installed as custom layered content — they conflict with MCO-managed RPMs and cause a degraded state.

image-layering-verify-rpm-ostree-status [IN] OBSERVATION

Custom layered image deployment on a node is verified with rpm-ostree status (via oc debug node).

image-lifecycle-management-model [IN] DERIVED

OpenShift image lifecycle management spans creation to deletion: images require the openshift.io/image.managed annotation for pruning eligibility, the ImagePruner (managed by the Image Registry Operator) runs as a CronJob, and pruning requires a registry restart to clear the blob metadata cache — creating a multi-step lifecycle with manual intervention points.

image-manifest-list-uses-dockerimagemanifests [IN] OBSERVATION

An Image with dockerImageManifests populated represents a manifest list (multi-arch); dockerImageLayers should not be set in this case.

image-metadata-stored-as-api-resources [IN] OBSERVATION

Image metadata is stored as standard API resources (images and image streams), not in the registry storage; actual image data goes to configurable storage.

image-mirror-configuration-pipeline [IN] DERIVED

Image mirroring follows a pipeline: oc-mirror generates IDMS manifests, MCO applies them as registries.conf on nodes, with ICSP deprecated in favor of IDMS since OCP 4.13.

image-name-max-63-chars [IN] OBSERVATION

Maximum image name length in OpenShift is 63 characters.

image-objects-immutable-content-addressed [IN] OBSERVATION

Image objects in OpenShift are immutable and content-addressed (named by a hash of their contents)

image-registry-auto-detects-storage [IN] OBSERVATION

The Cluster Image Registry Operator auto-detects storage based on cloud provider; creates an incomplete resource if storage info is missing.

image-registry-cluster-operator [IN] OBSERVATION

The image-registry cluster operator manages the lifecycle of OpenShift's built-in internal container image registry.

image-registry-config-singleton-named-cluster [IN] OBSERVATION

The image registry Config resource (imageregistry.operator.openshift.io/v1) is a cluster-scoped singleton named cluster.

image-registry-default-route-true-exposes-externally [IN] OBSERVATION

Setting defaultRoute: true on the image registry Config creates an externally accessible route using the default hostname.

image-registry-disable-redirect-forces-data-through-registry [IN] OBSERVATION

Setting disableRedirect: true on the image registry Config forces all image data to flow through the registry instead of redirecting clients to the storage backend.

image-registry-emptydir-not-production [IN] OBSERVATION

The image registry emptyDir storage backend is not production-grade — data is lost when the pod restarts.

image-registry-external-access-model [IN] DERIVED

The internal image registry can be exposed externally via defaultRoute (with re-encrypt TLS), requires specific storage backend configuration, and credentials are stored in a named secret — forming a complete deployment model for registry accessibility.

image-registry-operator-separate-api-group [IN] OBSERVATION

The image registry operator uses configs.imageregistry.operator.openshift.io (not operator.openshift.io)

image-registry-pvc-claim-immutable [IN] OBSERVATION

The image registry PVC claim field cannot be changed once set — the PVC must be deleted and recreated.

image-registry-replicas-only-required-field [IN] OBSERVATION

The replicas field is the only required field in the image registry Config .spec.

image-registry-storage-backends [IN] OBSERVATION

The image registry supports seven storage backends: S3, Azure Blob, GCS, OpenStack Swift, PVC, IBM COS, and emptyDir.

image-resource-cluster-scoped [IN] OBSERVATION

Image objects are cluster-scoped resources (not namespaced).

image-resource-immutable-content-addressable [IN] OBSERVATION

The Image resource (image.openshift.io/v1) is immutable and content-addressable — image names are derived from a hash of their contents, so any change produces a new Image object.

image-signatures-enforce-cluster-wide-policy [IN] OBSERVATION

Image signatures can enforce cluster-wide image policy restricting which images are allowed to run.

image-streams-enable-automated-rollouts [IN] OBSERVATION

Image Streams and Triggers enable automated rollouts when upstream images change, tying into CI/CD workflows.

image-supply-chain-end-to-end [IN] DERIVED

OpenShift provides two parallel but converging image supply chains: application images flow through build systems → ImageStreams → registry, while operator images flow through FBC catalogs → OLM lifecycle → deployment — both ultimately delivering container images through managed, auditable pipelines.

image-tags-mutable-ids-immutable [IN] OBSERVATION

Image tags are mutable human-readable labels pointing to immutable SHA digests; multiple tags can point to the same digest.

image-trigger-annotation-for-k8s-resources [IN] OBSERVATION

Kubernetes-native resources (Deployments, StatefulSets, DaemonSets, CronJobs, Jobs, ReplicationControllers, Pods) use the image.openshift.io/triggers annotation to trigger on image stream tag changes.

image-trigger-fieldpath-no-wildcards [IN] OBSERVATION

The fieldPath in an image trigger annotation must precisely match a container by name or index and cannot use wildcards.

image-trigger-from-kind-imagestreamtag-only [IN] OBSERVATION

The from.kind in an image trigger annotation must be ImageStreamTag — no other kinds are supported.

image-trigger-paused-disables-without-removing [IN] OBSERVATION

Setting paused: true in an image trigger annotation disables the trigger without removing the annotation.

imagecontentpolicy-cluster-scoped [IN] OBSERVATION

ImageContentPolicy is a cluster-scoped (not namespaced) resource in the config.openshift.io/v1 API group

imagecontentpolicy-digest-only-default [IN] OBSERVATION

ImageContentPolicy mirrors only work for digest-based image pulls by default; allowMirrorByTags: true must be set to enable tag-based mirroring

imagecontentpolicy-multiple-policies-merged [IN] OBSERVATION

When multiple ImageContentPolicy objects define mirrors for the same source, mirror lists are merged (not rejected); conflicting orderings result in unspecified behavior, not errors

imagemanifestvuln-crd-shortname-vuln [IN] OBSERVATION

Vulnerability scan results are exposed as ImageManifestVuln CRs (CRD: imagemanifestvulns.secscan.quay.redhat.com); CLI shorthand is oc get vuln --all-namespaces.

imagepruner-api-group [IN] OBSERVATION

The ImagePruner resource uses API group imageregistry.operator.openshift.io/v1.

imagepruner-default-min-age-60m [IN] OBSERVATION

The ImagePruner default minimum image age before pruning eligibility is 60 minutes (keepYoungerThanDuration).

imagepruner-default-schedule-daily-midnight [IN] OBSERVATION

The ImagePruner default schedule is 0 0 * * * (daily at midnight).

imagepruner-default-tag-revisions-3 [IN] OBSERVATION

The ImagePruner preserves a default of 3 tag revisions per image stream tag.

imagepruner-keepyoungerthan-deprecated [IN] OBSERVATION

The ImagePruner keepYoungerThan field (nanoseconds) is deprecated in favor of keepYoungerThanDuration (duration string); if both are set, the duration field wins.

imagepruner-managed-by-image-registry-operator [IN] OBSERVATION

The ImagePruner resource is managed by the Image Registry Operator, which translates its spec into a Kubernetes CronJob — it is not created manually as a CronJob.

imagepruner-suspend-true-pauses [IN] OBSERVATION

Setting suspend: true on the ImagePruner stops pruning without removing the configuration.

imagesignature-immutable-post-delete-only [IN] OBSERVATION

ImageSignature resources support only POST (create) and DELETE operations — no PATCH or PUT — making signatures immutable once created.

imagesignature-required-fields [IN] OBSERVATION

ImageSignature required fields are type and content; issuedTo also requires publicKeyID (at least 64 lowest bits of the public key fingerprint).

imagestream-api-group [IN] OBSERVATION

The API group for image streams is image.openshift.io/v1.

imagestream-buildconfig-openshift-native [IN] OBSERVATION

ImageStream and BuildConfig are OpenShift-native concepts with no direct Kubernetes equivalents.

imagestream-controlled-access-model [IN] DERIVED

ImageStream access follows a controlled model: images are immutable and content-addressed, end users access them via ImageStreamTag/ImageStreamImage (not Image directly), pulling requires explicit get-layers permission, and ImageStreamMapping is restricted to privileged integrators.

imagestream-dockerimagerepository-deprecated [IN] OBSERVATION

The spec.dockerImageRepository field on ImageStream is deprecated since v3.7; replaced by per-tag spec.tags[].from.

imagestream-imports-ignore-mirror-search [IN] OBSERVATION

Image stream imports do not use the mirror/search mechanism — samplesRegistry must be explicitly set to the mirror hostname.

imagestream-lookup-policy-local-resolves-short-names [IN] OBSERVATION

Setting spec.lookupPolicy.local: true on an ImageStream causes short image references in the namespace to be automatically resolved to the image stream's image ID without contacting a remote registry.

imagestream-lookup-policy-local-true [IN] OBSERVATION

Setting spec.lookupPolicy.local: true on an image stream enables all resources in the same project to resolve image stream references without additional configuration.

imagestream-metadata-stored-in-etcd [IN] OBSERVATION

Image stream metadata is stored in etcd.

imagestream-pull-requires-get-layers-permission [IN] OBSERVATION

Pulling from the integrated registry requires get imagestreams/layers permission.

imagestream-reference-policy-local-vs-source [IN] OBSERVATION

referencePolicy.type: Local points the pull-spec to the integrated registry (enabling credential isolation and local layer mirroring); Source (default) uses the original upstream location.

imagestream-resolve-names-annotation [IN] OBSERVATION

The annotation alpha.image.policy.openshift.io/resolve-names: '*' on a pod template enables image stream resolution for that specific resource.

imagestream-same-project-single-segment-name [IN] OBSERVATION

Image stream references must use single-segment names (<name>:<tag>, not full registry paths) and the image stream must be in the same project as the referencing resource.

imagestream-scheduled-import-policy [IN] OBSERVATION

Setting importPolicy.scheduled: true on an ImageStream tag enables periodic re-import to track upstream changes.

imagestream-status-tags-first-item-is-current [IN] OBSERVATION

The first entry in status.tags[].items is the currently active image for that tag.

imagestream-tag-vs-image-distinction [IN] OBSERVATION

ImageStreamTag references an image by tag name while ImageStreamImage references a specific image by digest within an ImageStream.

imagestreamimage-name-format-stream-at-digest [IN] OBSERVATION

ImageStreamImage name format is <STREAM>@<DIGEST> (e.g., mystream@sha256:abc123...), using a content-addressable digest reference rather than a tag.

imagestreamimage-read-only [IN] OBSERVATION

ImageStreamImage is a read-only resource — only GET is supported, no create/update/delete.

imagestreamimport-only-dockerimage-source [IN] OBSERVATION

ImageStreamImport only allows kind: DockerImage as the from source for importing images.

imagestreamimport-spec-import-true-triggers-import [IN] OBSERVATION

On ImageStreamImport, spec.import: true triggers actual import; false is a metadata preview/dry-run only.

imagestreamlayers-imagemissing-flag [IN] OBSERVATION

The imageMissing boolean in ImageStreamLayers indicates an Image object was deleted by an admin but is still referenced by the ImageStream

imagestreamlayers-layers-ordered-base-to-top [IN] OBSERVATION

ImageStreamLayers layers are ordered from base layer to top layer, and all referenced layers are guaranteed to exist in the blobs map

imagestreamlayers-multiarch-uses-manifests [IN] OBSERVATION

In ImageStreamLayers, multi-architecture images use the manifests field (list of digests) instead of layers/config

imagestreamlayers-read-only-subresource [IN] OBSERVATION

ImageStreamLayers is a read-only API subresource of ImageStream (only GET is supported), accessed via /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/layers

imagestreammapping-create-only [IN] OBSERVATION

ImageStreamMapping only supports the create operation — no get, list, update, or delete

imagestreammapping-grants-view-access [IN] OBSERVATION

Creating an ImageStreamMapping grants view access to the image for anyone who can view the image stream

imagestreammapping-privileged-integrators [IN] OBSERVATION

ImageStreamMapping is used by privileged integrators (not end users) to associate a container image with an image stream tag

imagestreams-abstract-over-registry-locations [IN] OBSERVATION

ImageStreams provide an abstraction over container image repositories, enabling tag-based references, indirection over registry locations, and automatic updates.

imagestreams-enable-automatic-rollouts [IN] OBSERVATION

ImageStreams enable automatic rollouts when upstream images change — DeploymentConfigs can trigger on ImageStream tag changes.

imagestreams-no-actual-image-data [IN] OBSERVATION

Image streams do not contain actual image data — they are an abstraction layer that presents a virtual view of related images via references and pointers.

imagestreams-openshift-specific-not-k8s [IN] OBSERVATION

ImageStreams are an OpenShift-specific abstraction (not a Kubernetes-native concept) that provides a virtual view of related images, enabling tagging, rollback, and trigger-based updates.

imagestreamtag-delete-clears-spec-and-status [IN] OBSERVATION

Deleting an ImageStreamTag clears both the status and spec fields of the associated image stream tag

imagetag-create-requires-no-existing-spec [IN] OBSERVATION

Creating an ImageTag only succeeds if no spec tag already exists and the spec field is set

imagetag-replaces-imagestreamtag [IN] OBSERVATION

ImageTag (image.openshift.io/v1) is the newer replacement for ImageStreamTag, providing spec + status + image in a single object

imagetag-spec-from-reference-types [IN] OBSERVATION

An ImageTag's spec.from can reference ImageStreamTag (same stream only), ImageStreamImage, or DockerImage

immutability-enforced-at-resource-and-platform-levels [IN] DERIVED

OpenShift enforces immutability at two distinct levels: individual resource fields (Route host, IngressController domain, IngressClass controller, CSIDriver attachRequired) are locked after creation, while platform-wide decisions (FIPS, CPU partitioning, network plugin) are locked at install time — creating a layered immutability model where some things can never change and others freeze on first write.

immutable-nodes-with-singleton-operator-control [IN] DERIVED

OpenShift node management combines immutability with singleton operator governance: RHCOS nodes accept changes only through the MCO delivery pipeline (render → cordon → drain → apply → reboot), and multiple operator CRs enforce singleton naming conventions — creating a system where node state is both immutable and centrally controlled through well-known named resources.

importpolicy-scheduled-periodic-reimport [IN] OBSERVATION

Setting importPolicy.scheduled: true on an image stream tag enables periodic re-checking and re-import of external tags

infra-node-label [IN] OBSERVATION

Infrastructure nodes are identified by the label node-role.kubernetes.io/infra: "".

infra-node-taint [IN] OBSERVATION

The recommended taint for infrastructure nodes is node-role.kubernetes.io/infra:NoSchedule to prevent user workloads from scheduling.

infra-nodes-no-subscription-cost [IN] OBSERVATION

Infra nodes labeled with the infra role running only infra workloads do not count toward subscription charges, but must also use taints to prevent user workload scheduling.

infra-workload-move-requires-per-operator-config [IN] OBSERVATION

Moving workloads (router, registry, monitoring, logging) to infra nodes requires configuring each operator's nodeSelector and tolerations individually; creating the infra node alone is not sufficient.

infrastructure-cloud-config-configmap-namespace [IN] OBSERVATION

The cloud config ConfigMap referenced by Infrastructure lives in openshift-config; the stitched/generated version is kube-cloud-config in openshift-config-managed with key cloud.conf

infrastructure-dual-stack-two-ips [IN] OBSERVATION

Dual-stack clusters have two entries in apiServerInternalIPs and ingressIPs (one IPv4, one IPv6)

infrastructure-operator-bare-metal-vsphere-sno [IN] OBSERVATION

The Infrastructure Operator manages Assisted Service deployment for on-premise bare metal and vSphere OCP installations, including single-node OpenShift, and supports GitOps Zero Touch Provisioning (ZTP).

infrastructure-platform-type-controls-automation [IN] OBSERVATION

Infrastructure.spec.platformSpec.type determines whether infrastructure automation (load balancers, dynamic volumes, machine lifecycle) is enabled; setting None disables all automation

infrastructure-platform-types [IN] OBSERVATION

Allowed platformSpec.type values include: AWS, Azure, BareMetal, GCP, Libvirt, OpenStack, VSphere, oVirt, KubeVirt, EquinixMetal, PowerVS, AlibabaCloud, Nutanix, None

infrastructure-resource-singleton-cluster [IN] OBSERVATION

The Infrastructure resource (config.openshift.io/v1) is a cluster singleton always named cluster that defines platform provider type, cloud config, API server IPs, ingress IPs, and failure domains

ingress-api-group-networking-v1 [IN] OBSERVATION

Kubernetes Ingress belongs to API group networking.k8s.io/v1 (not the deprecated extensions/v1beta1)

ingress-appsdomain-mutable-post-install [IN] OBSERVATION

spec.appsDomain on the Ingress config is an optional alternative domain for route host generation that can be modified post-install

ingress-backend-same-namespace [IN] OBSERVATION

The service referenced by an Ingress backend must be in the same namespace as the Ingress object

ingress-cloud-default-loadbalancer-external [IN] OBSERVATION

Cloud platforms (AWS, Azure, GCP) default to LoadBalancerService with External scope for endpoint publishing.

ingress-config-singleton-named-cluster [IN] OBSERVATION

The Ingress resource (config.openshift.io/v1) is a cluster-wide singleton with canonical name cluster

ingress-controller-default-replicas-2 [IN] OBSERVATION

The default number of replicas per Ingress Controller is 2.

ingress-controller-default-tls-intermediate [IN] OBSERVATION

The default TLS security profile for Ingress Controllers is Intermediate (TLS 1.2 minimum).

ingress-controller-namespace-openshift-ingress-operator [IN] OBSERVATION

The default Ingress Controller is named default and lives in the openshift-ingress-operator namespace.

ingress-default-placement-workers [IN] OBSERVATION

status.defaultPlacement on the Ingress config controls whether ingress router pods run on control-plane or worker nodes (default: Workers)

ingress-domain-field-immutable-unique [IN] OBSERVATION

The domain field on an IngressController cannot be updated after creation and must be unique across all Ingress Controllers.

ingress-domain-immutable-after-install [IN] OBSERVATION

spec.domain on the Ingress config sets the default domain for route host generation and cannot be changed after installation

ingress-forwarded-header-default-append [IN] OBSERVATION

The HTTP header forwarding policy defaults to Append.

ingress-haproxy-default-threads-4-max-64 [IN] OBSERVATION

HAProxy default thread count is 4 (max 64) and default max connections is 50000.

ingress-hsts-first-match-wins [IN] OBSERVATION

HSTS policies in spec.requiredHSTSPolicies are enforced via the haproxy.router.openshift.io/hsts_header annotation with first matching policy winning

ingress-http2-headerbuffer-min-16384 [IN] OBSERVATION

The headerBufferBytes must be at least 16384 if HTTP/2 is enabled (default 32768).

ingress-longest-path-wins [IN] OBSERVATION

When multiple Ingress paths match a request, the longest matching path takes priority

ingress-node-firewall-config-cr-name [IN] OBSERVATION

The IngressNodeFirewallConfig CR must be named ingressnodefirewallconfig and created in the openshift-ingress-node-firewall namespace.

ingress-node-firewall-ebpf-xdp [IN] OBSERVATION

The Ingress Node Firewall Operator uses eBPF programs with XDP preferred for packet processing; NICs without native XDP drivers run at lower performance.

ingress-node-firewall-must-gather [IN] OBSERVATION

oc adm must-gather -- gatheringressnode_firewall collects firewall-specific diagnostics including eBPF bpftool outputs.

ingress-node-firewall-namespace [IN] OBSERVATION

The Ingress Node Firewall Operator runs in the openshift-ingress-node-firewall namespace.

ingress-node-firewall-rule-order-1-100 [IN] OBSERVATION

Ingress Node Firewall rules use an order field (1–100 per source CIDR); lower order number means higher priority (executes first).

ingress-node-firewall-sno-annotation [IN] OBSERVATION

For Single-Node OpenShift clusters, the openshift-ingress-node-firewall namespace requires the annotation workload.openshift.io/allowed=management.

ingress-node-firewall-stateless-only [IN] OBSERVATION

The Ingress Node Firewall Operator supports only stateless firewall rules (no connection tracking).

ingress-node-firewall-webhook-blocks-critical [IN] OBSERVATION

The Ingress Node Firewall verification webhook prevents invalid configs and blocks rules that would break critical cluster services such as the API server.

ingress-operator-converts-tls10-to-tls11 [IN] OBSERVATION

The Ingress Operator always converts TLS 1.0 to TLS 1.1 for Old or Custom security profiles.

ingress-operator-deploys-haproxy [IN] OBSERVATION

The Ingress Operator deploys and manages HAProxy-based Ingress Controllers to route external traffic into the cluster.

ingress-operator-namespaces [IN] OBSERVATION

The Ingress Operator runs in the openshift-ingress-operator namespace; the router runs in the openshift-ingress namespace.

ingress-pathtype-required-three-values [IN] OBSERVATION

Ingress pathType is required on every path entry with three possible values: Exact, Prefix, and ImplementationSpecific

ingress-prefix-match-element-wise [IN] OBSERVATION

Ingress Prefix path matching is element-wise by / — /foo/bar matches /foo/bar/baz but does NOT match /foo/barbaz

ingress-route-admission-default-strict [IN] OBSERVATION

The routeAdmission.namespaceOwnership policy defaults to Strict (no cross-namespace hostname sharing).

ingress-sharding-via-namespace-route-selectors [IN] OBSERVATION

Ingress Controller sharding is implemented via namespaceSelector and routeSelector on the IngressController CR.

ingress-tls-port-443-only [IN] OBSERVATION

TLS on Kubernetes Ingress only supports port 443

ingress-wildcard-policy-default-disallowed [IN] OBSERVATION

The IngressController wildcardPolicy defaults to WildcardsDisallowed.

ingress-wildcard-single-label [IN] OBSERVATION

Ingress wildcard hosts (*.foo.com) match exactly one DNS label — * alone is not a valid host

ingressclass-cluster-scoped [IN] OBSERVATION

IngressClass is a cluster-scoped resource (not namespaced) in API group networking.k8s.io/v1

ingressclass-controller-immutable [IN] OBSERVATION

IngressClass spec.controller field is immutable — cannot be changed after creation

ingressclass-default-annotation [IN] OBSERVATION

The annotation ingressclass.kubernetes.io/is-default-class: "true" marks an IngressClass as the default; new Ingress resources without an explicit class get assigned to it

ingresscontroller-controls-haproxy-router [IN] OBSERVATION

IngressController is the resource that controls HAProxy router deployments; updating it can cause traffic disruption

ingresscontroller-custom-error-pages-503-404-only [IN] OBSERVATION

Custom error pages for IngressController require a ConfigMap in openshift-config namespace; only 503 and 404 error pages are customizable.

ingresscontroller-default-tls-profile-intermediate [IN] OBSERVATION

The default IngressController TLS security profile is Intermediate (TLS 1.2–1.3); profiles may change on OCP upgrade causing rolling router updates.

ingresscontroller-endpoint-strategy-platform-dependent [IN] OBSERVATION

Default IngressController endpoint publishing strategy is platform-dependent: LoadBalancerService (External) for AWS/Azure/GCP/IBMCloud/AlibabaCloud; HostNetwork for Libvirt and unknown platforms.

ingresscontroller-mtls-edge-reencrypt-only [IN] OBSERVATION

IngressController clientTLS (mTLS) works only with edge-terminated and reencrypt routes, not passthrough TLS or cleartext HTTP.

ingresscontroller-replicas-default-by-topology [IN] OBSERVATION

IngressController default replicas: 1 for SingleReplica topology, 2 for HighlyAvailable topology.

ingresscontroller-sharding-via-selectors [IN] OBSERVATION

IngressControllers can be sharded using namespaceSelector and/or routeSelector to control which routes they serve.

ingresscontroller-strategy-and-domain-immutable [IN] OBSERVATION

IngressController endpointPublishingStrategy and domain fields cannot be updated after creation.

ingresscontroller-wildcard-dns-aws-azure-gcp-only [IN] OBSERVATION

Wildcard DNS management by the Ingress Operator is only supported on AWS, Azure, and GCP.

init-containers-run-before-app-containers [IN] OBSERVATION

Init containers run before application containers and are used for setup tasks not present in the application image.

init-containers-run-sequentially [IN] OBSERVATION

Init containers run sequentially and each must complete successfully before the next starts; all must complete before app containers start.

init-containers-sequential-no-probes [IN] OBSERVATION

Init containers run sequentially, must all succeed, and cannot have probes or lifecycle hooks.

insights-advisor-location [IN] OBSERVATION

Insights Advisor is available at console.redhat.com/openshift/insights/advisor/ and displays identified issues with remediation steps

insights-operator-enabled-by-default [IN] OBSERVATION

The Insights Operator is installed and enabled by default on OpenShift Container Platform clusters.

insights-operator-interval-2h [IN] OBSERVATION

The Insights Operator uploads its archive to OpenShift Cluster Manager every 2 hours

insights-operator-report-interval-2h [IN] OBSERVATION

The Insights Operator reports configuration and component failure status to Red Hat every 2 hours.

insightsoperator-api-group [IN] OBSERVATION

The InsightsOperator API group is operator.openshift.io/v1 — not config.openshift.io.

insightsoperator-config-override-precedence [IN] OBSERVATION

InsightsOperator config override precedence order: hardcoded defaults → observedConfig → unsupportedConfigOverrides.

insightsoperator-empty-report-means-no-gathering [IN] OBSERVATION

An empty InsightsOperator gatherStatus or insightsReport means no data gathering has occurred — relevant for disconnected cluster scenarios.

insightsoperator-healthcheck-totalrisk-1-to-4 [IN] OBSERVATION

InsightsOperator health check totalRisk ranges from 1–4; higher values indicate more critical issues.

insightsoperator-management-state-values [IN] OBSERVATION

InsightsOperator managementState controls the operator lifecycle with values: Managed, Unmanaged, Removed.

install-config-immutable-after-install [IN] OBSERVATION

All install-config.yaml parameters (networking, platform, etc.) are immutable after OpenShift cluster installation.

install-config-params-immutable-after-install [IN] OBSERVATION

The install-config.yaml parameters cannot be changed after cluster installation.

install-config-yaml-consumed [IN] OBSERVATION

The install-config.yaml file is consumed/pruned by the installer during the transformation pipeline (install-config.yaml → Kubernetes manifests → Ignition configs) and must be backed up before installation

install-specific-operator-version-startingcsv-manual [IN] OBSERVATION

To install a specific Operator version, set startingCSV in the Subscription and use installPlanApproval: Manual.

install-time-irreversible-constraints [IN] DERIVED

OpenShift has multiple cluster-defining decisions that are permanently locked at install time and cannot be changed post-install: FIPS mode, CPU partitioning (workload partitioning), and the network plugin — creating a class of irreversible architectural choices that must be planned before cluster creation.

installplan-approval-automatic-or-manual [IN] OBSERVATION

InstallPlan spec.approval must be either "Automatic" or "Manual" — this is a required field.

installplan-approval-controls-upgrades [IN] OBSERVATION

The InstallPlan approval strategy determines whether Operator upgrades are applied automatically or require admin approval.

installplan-approval-required-before-install [IN] OBSERVATION

InstallPlans must be approved (manually or automatically) before an Operator installs or upgrades

installplan-attenuated-service-account [IN] OBSERVATION

The InstallPlan attenuatedServiceAccountRef field enables scoped/least-privilege operator installation using a specific service account.

installplan-is-namespaced [IN] OBSERVATION

InstallPlan is a namespaced resource, not cluster-scoped.

installplan-required-spec-fields [IN] OBSERVATION

The three required spec fields for an InstallPlan are approval, approved, and clusterServiceVersionNames.

integrated-registry-namespace [IN] OBSERVATION

The OpenShift integrated image registry runs in the openshift-image-registry namespace.

integrated-registry-sends-image-notifications [IN] OBSERVATION

The integrated registry sends notifications to the cluster when new images are pushed, which can trigger builds and deployments automatically.

internal-registry-configurable-storage [IN] OBSERVATION

The OpenShift internal registry is configurable and can be enabled, disabled, or pointed at different storage backends (e.g., PVCs, S3 object storage).

internal-registry-service-endpoint [IN] OBSERVATION

The internal registry service endpoint is image-registry.openshift-image-registry.svc:5000.

ip-forwarding-restricted-default [IN] OBSERVATION

OVN-Kubernetes gatewayConfig.ipForwarding defaults to Restricted (only Kubernetes traffic); Global forwards all traffic on OVN-managed interfaces

ipaddress-api-group-ipam-cluster-x [IN] OBSERVATION

The IPAddress resource belongs to the ipam.cluster.x-k8s.io/v1beta1 API group and is part of the Cluster API IPAM subsystem, not core Kubernetes networking.

ipaddress-is-namespaced [IN] OBSERVATION

The IPAddress resource is namespace-scoped (not cluster-scoped).

ipaddress-required-fields [IN] OBSERVATION

The IPAddress spec has four required fields: address, claimRef, poolRef, and prefix; gateway is optional.

ipaddressclaim-allocation-pattern [IN] OBSERVATION

IPAddressClaim follows a claim-based allocation model: a claim referencing a pool is created, the IPAM controller allocates an address by creating an IPAddress object, and status.addressRef is populated with a reference to it.

ipaddressclaim-condition-required-fields [IN] OBSERVATION

IPAddressClaim status conditions have three required fields: lastTransitionTime, status, and type; the severity field is only set when Status=False.

ipaddressclaim-ipaddress-claim-binding-pattern [IN] OBSERVATION

IPAddressClaim is the request object and IPAddress is the fulfilled allocation object, following a claim/binding pattern similar to PVC/PV.

ipaddressclaim-poolref-only-required-field [IN] OBSERVATION

The IPAddressClaim spec has only one required field: poolRef, which itself requires kind and name.

ipi-vs-upi-infrastructure-management [IN] OBSERVATION

With IPI (Installer-Provisioned Infrastructure) the installer manages cloud resources directly, while with UPI (User-Provisioned Infrastructure) the user provisions all infrastructure manually.

ipi-vs-upi-machine-management [IN] OBSERVATION

IPI installations on cloud providers get full MachineSet/MachineAPI support; UPI and bare-metal may have limited automation.

ipi-vs-upi-responsibility [IN] OBSERVATION

IPI — the installer manages infrastructure (networking, LBs, DNS, storage, machines); UPI — the user provisions and manages all infrastructure

ippool-range-allocations-required [IN] OBSERVATION

IPPool spec requires both range (CIDR notation) and allocations fields; each allocation requires id and podref (with ifname optional)

ippool-whereabouts-api-group [IN] OBSERVATION

IPPool belongs to API group whereabouts.cni.cncf.io/v1alpha1 and is a namespaced custom resource for managing IP address pools used by the Whereabouts CNI plugin

ipsec-ca-valid-10-years-node-cert-5-years [IN] OBSERVATION

CNO generates a self-signed X.509 CA valid for 10 years; node certificates are valid for 5 years and auto-rotated after 4.5 years.

ipsec-cipher-aes-gcm-16-256 [IN] OBSERVATION

IPsec uses AES-GCM-16-256 encryption cipher (ICV=16 bytes, key length=256 bits).

ipsec-disabled-by-default [IN] OBSERVATION

IPsec encryption is disabled by default in OpenShift Container Platform and must be explicitly enabled via the networks.operator.openshift.io CR.

ipsec-external-requires-nmstate-butane-routingviahost [IN] OBSERVATION

External IPsec requires NMState Operator, Butane tool, and routingViaHost=true in ovnKubernetesConfig.gatewayConfig.

ipsec-mtu-reduction-46-bytes [IN] OBSERVATION

Cluster MTU must be reduced by 46 bytes when IPsec is enabled to accommodate ESP header overhead.

ipsec-not-supported-hosted-control-planes [IN] OBSERVATION

IPsec is not supported on hosted control planes.

ipsec-not-supported-rhel-compute-nodes [IN] OBSERVATION

IPsec is not supported on RHEL compute nodes due to libreswan incompatibility.

ipsec-pod-to-pod-transport-mode [IN] OBSERVATION

IPsec uses Transport mode (not Tunnel mode) for pod-to-pod encryption on the OVN-Kubernetes cluster network.

ipsec-ports-udp500-udp4500-esp [IN] OBSERVATION

IPsec requires UDP 500 (IKE), UDP 4500 (NAT-T), and ESP protocol to be allowed through firewalls.

ipsec-same-node-never-encrypted [IN] OBSERVATION

Same-node pod traffic is never encrypted by IPsec.

ipsec-three-modes [IN] OBSERVATION

IPsec has three modes: Disabled (default), Full (pod-to-pod + external), and External (external traffic only).

ipsec-verify-ovn-nbctl [IN] OBSERVATION

IPsec can be verified by running ovn-nbctl --no-leader-only get nb_global . ipsec inside an ovnkube-node pod, which returns true if enabled.

ipvlan-shares-mac-macvlan-unique-mac [IN] OBSERVATION

ipvlan shares the parent MAC address across pods; macvlan gives each pod a unique MAC address.

istag-format-colon-separated [IN] OBSERVATION

Image stream tags are formatted as <imagestream-name>:<tag> (colon-separated); image stream images are formatted as <imagestream-name>@<image-id> (at-sign separated).

istag-history-enables-rollback [IN] OBSERVATION

Image stream tags maintain a history stack — new images are placed at the top, enabling rollback to previous image versions.

itms-tag-mirroring-risk [IN] OBSERVATION

Tag-based mirroring via ImageTagMirrorSet carries the risk of pulling different images from different mirrors for the same tag; digest-based mirroring via IDMS avoids this

jenkins-agent-base-image-includes-oc-cli [IN] OBSERVATION

The Jenkins base agent image includes headless Java, Jenkins JNLP client, git, tar, zip, nss, and the oc CLI tool.

jenkins-agent-default-java-version-java-11 [IN] OBSERVATION

The default Java version in the Jenkins agent image is java-11, configurable via the USEJAVAVERSION environment variable.

jenkins-agent-pods-deleted-by-default [IN] OBSERVATION

Jenkins agent pods are deleted by default after build completion; pod retention options are never(), onFailure(), always(), and default().

jenkins-agent-registry-ocp-tools-4 [IN] OBSERVATION

Jenkins agent images are available from registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8.

jenkins-deploy-methods-openshift [IN] OBSERVATION

Jenkins can be deployed on OpenShift via Samples Operator templates or a certified Helm chart.

jenkins-deprecated-in-favor-of-tekton-pipelines [IN] OBSERVATION

Jenkins is on a deprecation path in OCP; OpenShift Pipelines (Tekton) is the strategic replacement for CI/CD.

jenkins-deprecated-in-ocp [IN] OBSERVATION

Jenkins is deprecated in OpenShift Container Platform in favor of OpenShift Pipelines (Tekton).

jenkins-has-dedicated-ocp-docs-section [IN] OBSERVATION

Jenkins has its own dedicated documentation section in OpenShift Container Platform, available across versions 3.0 through 4.21.

jenkins-images-moved-ocp-tools-4-in-411 [IN] OBSERVATION

Jenkins and Agent Base images moved from OCP install payload to ocp-tools-4 repository at registry.redhat.io starting in OCP 4.11.

jenkins-imagestream-tags-upgrade-behavior [IN] OBSERVATION

Three image stream tags control Jenkins upgrade behavior: ocp-upgrade-redeploy (default, auto-redeploys on OCP upgrade), user-maintained-upgrade-redeploy (manual), and scheduled-upgrade-redeploy (periodic check).

jenkins-java-max-heap-param-overrides-dynamic [IN] OBSERVATION

JAVAMAXHEAP_PARAM takes precedence over dynamic heap calculation when set on Jenkins agent containers.

jenkins-jnlp-agent-default-heap-50-percent [IN] OBSERVATION

The Jenkins JNLP agent JVM uses 50% of container memory for heap by default (CONTAINERHEAPPERCENT=0.5); additional JVMs default to 25%.

jenkins-maven-nodejs-agents-deprecated-410-removed-411 [IN] OBSERVATION

Maven and NodeJS agent images were deprecated in OCP 4.10 and removed from the payload in 4.11; the recommended replacement is the sidecar pattern with the Jenkins Kubernetes Plugin.

jenkins-not-supported-outside-openshift [IN] OBSERVATION

Running Jenkins outside of OpenShift is not supported by Red Hat.

jenkins-oauth-integration [IN] OBSERVATION

Jenkins in OpenShift integrates with the OpenShift OAuth server for authentication.

jenkins-oc-cli-may-not-match-cluster-from-412 [IN] OBSERVATION

Starting with OCP 4.12, the bundled oc CLI in Jenkins images may not match the cluster version; pipelines needing a specific version must declare it in the pipeline DSL.

jenkins-pipeline-strategy-deprecated [IN] OBSERVATION

The jenkinsPipelineStrategy build strategy is deprecated; OpenShift Pipelines (Tekton) is the replacement

jenkins-pipeline-was-original-build-strategy [IN] OBSERVATION

Jenkins pipelines were the original JenkinsPipeline build strategy in OCP before Tekton/Pipelines became the recommended approach.

jenkins-updates-quarterly-latest-lts-only [IN] OBSERVATION

Jenkins images are updated quarterly aligned with upstream Jenkins LTS; only the latest LTS version is supported by Red Hat.

job-backofflimit-default-6 [IN] OBSERVATION

The Job .spec.backoffLimit defaults to 6 retries before marking the Job as failed.

job-backofflimit-default-6-cap-6min [IN] OBSERVATION

Job backoffLimit defaults to 6 retries with exponential backoff (10s, 20s, 40s…) capped at 6 minutes.

job-batch-v1-api-group [IN] OBSERVATION

Jobs belong to the batch/v1 API group and are namespaced resources.

job-completionmode-nonindexed-default [IN] OBSERVATION

Job .spec.completionMode has two values: NonIndexed (default) and Indexed.

job-pod-failure-policy-actions [IN] OBSERVATION

Pod failure policy actions are FailJob, FailIndex, Ignore, and Count; rules are evaluated in order with first match winning.

job-restart-never-vs-onfailure-behavior [IN] OBSERVATION

Job restartPolicy: Never creates new pods on failure (job controller retries), while restartPolicy: OnFailure restarts in-place on the same node (kubelet retries).

job-restart-policy-never-or-onfailure [IN] OBSERVATION

Pod restartPolicy in a Job template must be Never or OnFailure (not Always)

job-restartpolicy-never-or-onfailure [IN] OBSERVATION

Job Pod restartPolicy must be Never or OnFailure; Always is not allowed.

job-suspend-resets-starttime [IN] OBSERVATION

Suspending a Job resets its startTime and activeDeadlineSeconds timer.

job-ttl-zero-immediate-delete [IN] OBSERVATION

Setting ttlSecondsAfterFinished: 0 on a Job deletes it immediately after completion.

k8s-csr-approved-denied-immutable [IN] OBSERVATION

CSR Approved and Denied conditions are mutually exclusive and cannot be removed once added.

k8s-csr-cluster-scoped [IN] OBSERVATION

CertificateSigningRequest (CSR) objects are cluster-scoped (not namespaced) in the certificates.k8s.io/v1 API.

k8s-csr-min-expiration-600s [IN] OBSERVATION

The minimum expirationSeconds for a CertificateSigningRequest is 600 seconds (10 minutes).

k8s-csr-only-kubelet-client-auto-approved [IN] OBSERVATION

Of the three well-known Kubernetes CSR signers, only kubernetes.io/kube-apiserver-client-kubelet can be auto-approved by the csrapproving controller.

k8s-csr-three-well-known-signers [IN] OBSERVATION

Kubernetes has three well-known CSR signers: kubernetes.io/kube-apiserver-client, kubernetes.io/kube-apiserver-client-kubelet, and kubernetes.io/kubelet-serving.

k8s-flowlayer-app-infra [IN] OBSERVATION

The K8S_FlowLayer field categorizes network traffic as either app or infra

k8s-zone-eviction-rate-reduction [IN] OBSERVATION

In a partially disrupted Kubernetes zone (>55% nodes unhealthy), eviction rate is reduced from 0.1 to 0.01 nodes/sec; requires >3 zones and ≥50 nodes.

keda-custom-metrics-autoscaling-model [IN] DERIVED

Kubernetes-native autoscaling in OpenShift spans two complementary dimensions: KEDA provides horizontal scaling based on external triggers (Cron, Kafka, Prometheus, CPU/Memory) via ScaledObject/ScaledJob, while VPA adjusts vertical resource requests/limits — covering both scale-out and scale-up patterns.

keda-custom-resources [IN] OBSERVATION

Key KEDA custom resources are: ScaledObject, ScaledJob, KedaController, and TriggerAuthentication

keda-metrictype-replaces-type [IN] OBSERVATION

In KEDA CPU/Memory triggers, the type field is removed and replaced by metricType

keda-trigger-types [IN] OBSERVATION

Custom Metrics Autoscaler supported trigger types include: Cron, Kafka, Prometheus, Kubernetes workload, CPU, and Memory

kedacontroller-auto-created [IN] OBSERVATION

The KedaController CR is automatically created during Custom Metrics Autoscaler Operator installation (since version 2.17.2)

kepler-crd-deprecated-for-powermonitor [IN] OBSERVATION

The Kepler CRD is deprecated and replaced by the PowerMonitor CRD (starting with power monitoring 0.5).

kepler-default-metric-levels [IN] OBSERVATION

Default Kepler metric levels are node, pod, and vm (not container or process).

kepler-default-sample-rate-5s-staleness-500ms [IN] OBSERVATION

Kepler default sample rate is 5 seconds and default staleness is 500 milliseconds.

kepler-default-security-mode-rbac [IN] OBSERVATION

PowerMonitor default security mode is rbac with TLS encryption, not none.

kepler-runs-as-daemonset [IN] OBSERVATION

Kepler runs as a DaemonSet (one pod per node), as evidenced by DaemonSet-like scheduling status fields (desiredNumberScheduled, currentNumberScheduled, numberReady, etc.).

kepler-runs-as-daemonset-linux-nodes [IN] OBSERVATION

Kepler runs as a DaemonSet and is scheduled only on Linux nodes by default (kubernetes.io/os: linux).

kernel-bonding-default-when-no-ovs-bonds [IN] OBSERVATION

Kernel bonding is the default bonding type when no OVS bonds are configured in OpenShift.

kernel-bonding-fail-over-mac-only-zero [IN] OBSERVATION

Kernel bonding only supports failovermac=0 (none); values 1 (active) and 2 (follow) are not supported by Red Hat.

kernel-memory-overhead-formula [IN] OBSERVATION

On high-CPU nodes, container kernel memory overhead follows the formula: $(nproc) × 1/2 MiB due to per-cgroup kmem_cache.

key-escrow-not-supported-ocp [IN] OBSERVATION

Key escrow is not supported by OpenShift Container Platform; only TPM and NBDE are supported encryption methods.

kn-cli-for-openshift-serverless [IN] OBSERVATION

The kn CLI interacts with OpenShift Serverless components (Knative Serving and Eventing).

kn-cli-manages-serving-and-eventing [IN] OBSERVATION

The kn CLI manages both Knative Serving (services, revisions, traffic-splitting) and Knative Eventing (sources, triggers) components.

kn-plugin-architecture-like-kubectl [IN] OBSERVATION

The kn CLI has a flexible plugin architecture modeled after kubectl's plugin system.

knative-cli-kn-separate-from-oc [IN] OBSERVATION

The Knative CLI (kn) is a separate CLI from oc, covering Functions, Serving, and Eventing operations.

knative-eventing-components [IN] OBSERVATION

Knative Eventing handles event-driven architectures via event sources, brokers, triggers, and channels.

knative-eventing-event-driven [IN] OBSERVATION

Knative Eventing provides event-driven architecture capabilities (event sources, brokers, triggers) in OpenShift Serverless.

knative-serving-scale-to-zero [IN] OBSERVATION

Knative Serving handles request-driven compute — deploying and auto-scaling serverless containers, including scale-to-zero.

krew-works-with-oc-without-operator [IN] OBSERVATION

Krew works with oc even without the CLI Manager Operator installed.

kube-storage-version-migrator-purpose [IN] OBSERVATION

The KubeStorageVersionMigrator operator manages a component that re-writes stored resources in etcd to their current storage version after API schema changes during upgrades

kube-version-sorting-order [IN] OBSERVATION

Kubernetes "kube-like" version sorting order: GA > beta > alpha, then by major/minor version number (e.g., v10 > v2 > v1 > v11beta2 > v3beta1 > v12alpha1).

kubeadmin-password-location [IN] OBSERVATION

The kubeadmin password is located at <install_directory>/auth/kubeadmin-password.

kubeapiserver-cr-api-group [IN] OBSERVATION

The KubeAPIServer custom resource uses the API group operator.openshift.io/v1, not config.openshift.io

kubeapiserver-singleton-name-cluster [IN] OBSERVATION

The KubeAPIServer operator resource name is always cluster (singleton pattern for OpenShift operators)

kubelet-container-network-metrics-count-eight [IN] OBSERVATION

There are 8 standard kubelet containernetwork* metrics: 4 receive and 4 transmit (bytes, errors, packets, packets_dropped).

kubelet-default-log-level-2 [IN] OBSERVATION

The default kubelet log verbosity level in OpenShift is 2 (KUBELETLOGLEVEL=2).

kubelet-evicts-on-ephemeral-storage-exceeded [IN] OBSERVATION

Kubelet evicts pods when individual container ephemeral storage usage exceeds its limit or total pod usage exceeds the sum of all container limits.

kubelet-log-levels-debug-0-4-trace-5-8 [IN] OBSERVATION

Kubelet log levels 0–4 are debug-level; levels 5–8 are trace-level.

kubelet-onetime-log-change-dropin-path [IN] OBSERVATION

One-time kubelet log level changes are written to /etc/systemd/system/kubelet.service.d/30-logging.conf and require systemctl daemon-reload && systemctl restart kubelet.

kubelet-only-manages-k8s-created-containers [IN] OBSERVATION

The kubelet only manages containers created by Kubernetes, not other containers on the node.

kubelet-persistent-log-change-machineconfig [IN] OBSERVATION

Persistent kubelet log level changes require a MachineConfig object with the machineconfiguration.openshift.io/role label targeting the correct pool (master/worker).

kubelet-runs-on-nodes [IN] OBSERVATION

The kubelet runs on each node, reads container manifests, and ensures defined containers are running. kube-proxy also runs on every node and maintains network traffic between resources.

kubelet-version-skew-rules [IN] OBSERVATION

The kubelet must not be newer than kube-apiserver; it can be up to 1 minor version older on odd OCP releases or up to 2 minor versions older on even OCP releases.

kubeletconfig-containerruntimeconfig-generate-machineconfig [IN] OBSERVATION

KubeletConfig and ContainerRuntimeConfig are higher-level abstractions that generate MachineConfig objects under the hood via the Machine Config Operator.

kubeletconfig-cr-for-kubelet-params [IN] OBSERVATION

KubeletConfig CRs are the supported way to modify kubelet parameters in OCP; direct kubelet config editing is not supported.

kubeletconfig-for-kubelet-params [IN] OBSERVATION

KubeletConfig is the dedicated CR for managing Kubelet parameters (e.g., pod limits, eviction thresholds), separate from MachineConfig.

kubeletconfig-for-kubelet-settings [IN] OBSERVATION

KubeletConfig CR is used for managing Kubelet configuration on nodes; ContainerRuntimeConfig CR is used for CRI-O settings

kubeletconfig-nil-selector-selects-no-pools [IN] OBSERVATION

A nil machineConfigPoolSelector in KubeletConfig selects no pools — it must be explicitly set for the config to take effect.

kubeletconfig-no-api-validation [IN] OBSERVATION

Invalid kubelet configuration values in KubeletConfig are not validated by the OpenShift API — they are passed through to the kubelet and can make nodes unusable.

kubeletconfig-tls-default-from-apiserver [IN] OBSERVATION

KubeletConfig tlsSecurityProfile defaults to the cluster-wide setting from apiservers.config.openshift.io/cluster when unset.

kubeletconfig-tls-profiles-old-intermediate-only [IN] OBSERVATION

KubeletConfig only supports Old and Intermediate TLS profiles; Modern is not supported and maximum minTLSVersion is VersionTLS12.

latest-available-revision-triggers-redeployment [IN] OBSERVATION

A new latestAvailableRevision value on OpenShiftAPIServer triggers pod redeployments (used as suffix for revisioned secrets like encryption-config)

lb-required-ports-6443-22623-80-443 [IN] OBSERVATION

The load balancer for OCP must proxy ports 6443 (Kubernetes API), 22623 (Machine Config Server), 80, and 443.

ldap-group-sync-command [IN] OBSERVATION

LDAP group sync (oc adm groups sync) automatically creates and maintains Group objects from external directory services.

ldap-insecure-false-starttls [IN] OBSERVATION

LDAP with insecure: false and ldap:// URL upgrades to TLS via StartTLS; ldaps:// always uses TLS regardless of insecure setting

lease-api-group-coordination-k8s-io-v1 [IN] OBSERVATION

The Lease resource belongs to the coordination.k8s.io/v1 API group, not core/v1.

lease-namespaced-resource [IN] OBSERVATION

Leases are namespaced resources.

lease-transitions-tracks-holder-changes [IN] OBSERVATION

The leaseTransitions field on a Lease tracks the number of times the lease has changed holders.

lease-used-for-leader-election-and-node-heartbeats [IN] OBSERVATION

Leases are used for leader election among controller replicas and for node heartbeats (kubelets maintain Lease objects in the kube-node-lease namespace).

lifecycle-constrained-across-heterogeneous-fleet [IN] DERIVED

OpenShift lifecycle management must navigate a fundamental tension: install-time and update-time constraints create irreversible platform boundaries, while the node fleet is inherently heterogeneous (RHCOS immutable nodes vs. Windows nodes with different runtimes and networking) — meaning lifecycle operations must account for divergent upgrade paths and capability profiles within a single cluster.

lifecycle-hook-failure-policies [IN] OBSERVATION

Deployment lifecycle hook failure policies are: Abort (fail deployment), Retry (retry until success), and Ignore (ignore failure and continue).

lightspeed-ai-assistant-operator [IN] OBSERVATION

OpenShift Lightspeed is an AI-powered assistant delivered as a separate operator (version 1.0) with its own versioning independent of OCP.

lightspeed-genai-assistant [IN] OBSERVATION

OpenShift Lightspeed is a generative AI-powered virtual assistant accessed through a natural-language interface in the OpenShift web console.

lightspeed-introduced-ocp-417 [IN] OBSERVATION

OpenShift Lightspeed is available as of OpenShift Container Platform 4.17.

lightspeed-is-genai-virtual-assistant [IN] OBSERVATION

OpenShift Lightspeed is a generative AI-powered virtual assistant that provides a natural-language interface within the OpenShift web console.

lightspeed-separate-release-cadence [IN] OBSERVATION

OpenShift Lightspeed releases on a separate cadence from OpenShift Container Platform and has its own independent documentation set and versioning (e.g., Lightspeed 1.0 does not correspond to OCP 4.17).

lightspeed-version-compatibility-required [IN] OBSERVATION

OpenShift Lightspeed requires explicit verification of version compatibility with the underlying OpenShift Container Platform before installation.

lightspeed-web-console-not-cli [IN] OBSERVATION

OpenShift Lightspeed is accessed through the OpenShift web console, not the oc CLI.

limitrange-per-pod-container-defaults [IN] OBSERVATION

LimitRange sets default, minimum, and maximum resource constraints per pod or container within a namespace, complementing ResourceQuota's aggregate limits.

limitrange-sets-per-pod-container-defaults-bounds [IN] OBSERVATION

LimitRange sets default resource values and min/max constraints on individual pods and containers within a namespace.

limitrange-vs-resourcequota [IN] OBSERVATION

LimitRange sets default resource requests/limits per container in a project. ResourceQuota sets project-wide totals. They serve different purposes.

link-pull-secret-to-sa-command [IN] OBSERVATION

Pull secrets are linked to service accounts with oc secrets link <sa> <secret> --for=pull.

list-available-operators-command [IN] OBSERVATION

oc get packagemanifests -n openshift-marketplace lists all available Operators from OperatorHub catalogs.

list-config-resources-command [IN] OBSERVATION

oc api-resources -o name | grep config.openshift.io lists all cluster configuration resources

list-machines-command [IN] OBSERVATION

The command to list machines is oc get machine -n openshift-machine-api.

list-oauth-api-resources-cmd [IN] OBSERVATION

oc api-resources --api-group=oauth.openshift.io lists all OAuth API resources in OpenShift.

list-objects-share-uniform-structure [IN] OBSERVATION

All Kubernetes/OpenShift List API responses share four fields: apiVersion, kind, items (required), and metadata (ListMeta).

list-packagemanifests-command [IN] OBSERVATION

Command to discover available Operators: oc get packagemanifests -n openshift-marketplace

local-prefix-means-namespace-scoped-authz [IN] OBSERVATION

Authorization resources prefixed with "Local" (e.g., LocalSubjectAccessReview, LocalResourceAccessReview) are namespace-scoped; non-local variants operate cluster-wide.

local-storage-all-rwo-only [IN] OBSERVATION

All three local storage solutions (HPP, LSO, LVM Storage) only support ReadWriteOnce (RWO) access mode — none support RWX.

local-storage-device-paths-use-by-id [IN] OBSERVATION

Device paths in local storage configurations should use /dev/disk/by-id/ for stable identification.

local-storage-supported-filesystems-ext4-xfs [IN] OBSERVATION

Supported filesystems for LSO and LVM Storage are ext4 and xfs.

local-volume-operator-namespace [IN] OBSERVATION

The Local Volume Operator is installed in the openshift-local-storage namespace.

local-volumes-no-dynamic-provisioning [IN] OBSERVATION

Local volumes in OpenShift do NOT support dynamic provisioning.

localhost-recovery-kubeconfig-fallback [IN] OBSERVATION

The localhost-recovery.kubeconfig file on a control plane node can be used when admin.kubeconfig is unavailable.

localnet-requires-bridge-mappings-via-nncp [IN] OBSERVATION

OVN-K localnet topology requires bridge mappings configured via NodeNetworkConfigurationPolicy (NNCP) from the NMState Operator, where the localnet name in the NNCP must match the name field in the NAD.

localresourceaccessreview-answers-who-can [IN] OBSERVATION

LocalResourceAccessReview (authorization.openshift.io/v1) answers "who can do X?" — it returns which users and groups are authorized to perform a specified action within a particular namespace.

localresourceaccessreview-is-namespace-scoped [IN] OBSERVATION

LocalResourceAccessReview is namespace-scoped; the namespace is part of the URL path (POST /apis/authorization.openshift.io/v1/namespaces/{namespace}/localresourceaccessreviews).

localresourceaccessreview-vs-localsubjectaccessreview [IN] OBSERVATION

LocalResourceAccessReview asks "who can do X?" while LocalSubjectAccessReview asks "can user Y do X?"

localsubjectaccessreview-allowed-false-denied-false-no-opinion [IN] OBSERVATION

When LocalSubjectAccessReview returns allowed=false and denied=false, the authorizer has no opinion — this is distinct from an explicit denial.

localsubjectaccessreview-api-group-k8s [IN] OBSERVATION

LocalSubjectAccessReview uses the upstream Kubernetes API group authorization.k8s.io/v1, not the OpenShift-specific authorization.openshift.io/v1.

localsubjectaccessreview-exactly-one-attribute-type [IN] OBSERVATION

LocalSubjectAccessReview spec must set exactly one of resourceAttributes (for resource requests) or nonResourceAttributes (for non-resource URL requests).

logging-5-to-6-upgrade-not-automatic [IN] OBSERVATION

The upgrade from OpenShift Logging 5.x to 6.x is a documented manual migration procedure, not an in-place automatic upgrade.

logging-58-eol-date [IN] OBSERVATION

OpenShift Logging 5.8 reached End of Life on November 3, 2025 and is replaced by Logging 6.0.

logging-6x-requires-three-operators [IN] OBSERVATION

OpenShift Logging 6.x installation requires three operators: Loki Operator, Red Hat OpenShift Logging Operator, and Cluster Observability Operator (COO).

logging-6x-uses-loki-not-elasticsearch [IN] OBSERVATION

OpenShift Logging 6.x uses Loki (via LokiStack) as the default log store, replacing Elasticsearch from 5.x.

logging-architecture-three-tier-evolution [IN] DERIVED

OpenShift logging follows a three-tier evolutionary architecture: three log categories (infrastructure/application/audit) flow through Vector (replacing Fluentd) into Loki (replacing Elasticsearch in 6.x), with the 5.x→6.x transition requiring manual migration — not automatic upgrade.

logging-collector-http-receiver [IN] OBSERVATION

The OpenShift Logging collector (Vector) can be configured as an HTTP server to receive logs as a webhook input.

logging-elasticsearch-fluentd-kibana-deprecated [IN] OBSERVATION

Elasticsearch, Fluentd, and Kibana are deprecated in OpenShift Logging 5.8 and removed in Logging 6.0; Vector (collector) + LokiStack (storage) is the preferred stack.

logging-four-functions [IN] OBSERVATION

OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.

logging-logfilemetricexporter-manual [IN] OBSERVATION

LogFileMetricExporter is no longer deployed by default with the collector in Logging 5.8; it must be manually created as a CR to generate log metrics.

logging-multi-namespace-clusterlogforwarder [IN] OBSERVATION

In Logging 5.8, multiple isolated RBAC-protected ClusterLogForwarder CRs can be deployed in any namespace, not just openshift-logging.

logging-not-installed-by-default [IN] OBSERVATION

OpenShift Logging is not installed by default — it requires installing the Red Hat OpenShift Logging operator (and typically a log store operator like Loki).

logging-operator-not-default [IN] OBSERVATION

The OpenShift Logging Operator is not installed by default and must be installed separately.

logging-separate-product-from-ocp [IN] OBSERVATION

Red Hat OpenShift Logging is a separate product with its own release cycle, not bundled directly under OCP.

logging-separate-release-cycle [IN] OBSERVATION

OpenShift Logging is a separate installable component with its own release cycle, independent from core OpenShift Container Platform.

logging-subscription-channel-stable-xy [IN] OBSERVATION

The stable subscription channel provides updates only for the most recent logging release; use stable-x.y (e.g., stable-5.7) to pin to a specific logging version.

logging-three-log-categories [IN] OBSERVATION

OpenShift has three categories of logs: infrastructure logs, application logs, and audit logs.

logging-uninstall-requires-uiplugin-removal [IN] OBSERVATION

Uninstalling OpenShift Logging requires removing the operators and the UIPlugin resource.

loki-default-rate-limits [IN] OBSERVATION

Default Loki perStreamRateLimit is 3 MB/sec and perStreamRateLimitBurst is 15; HTTP 429 errors are fixed by increasing these in the LokiStack CR

loki-empty-ring-fix-reinstall [IN] OBSERVATION

Loki "empty ring" error after reinstall is fixed by removing old PVCs and reinstalling LokiStack

loki-max-batch-size-98mib [IN] OBSERVATION

Red Hat Loki Operator sets max message size to 100 MiB; spec.loki.batchSize must not exceed 98 MiB

loki-network-tenant-orgid [IN] OBSERVATION

The Loki tenant for Network Observability uses X-Scope-OrgID: network

lokistack-1x-extra-small-100gb [IN] OBSERVATION

LokiStack supports a 1x.extra-small deployment size for up to 100GB/day log ingestion.

lokistack-recommended-log-store [IN] OBSERVATION

LokiStack is the recommended log storage backend, replacing the deprecated Elasticsearch/Kibana stack.

lokistack-supports-node-scheduling [IN] OBSERVATION

LokiStack and log forwarding resources can be scheduled to specific nodes using node selectors and tolerations.

lookuppolicy-local-namespace-scoped [IN] OBSERVATION

When lookupPolicy.local=true on an ImageStreamTag, docker short image references are resolved to image IDs from the image stream without contacting external registries; scoped to the current namespace only

lso-installs-openshift-local-storage-namespace [IN] OBSERVATION

The Local Storage Operator (LSO) installs into the openshift-local-storage namespace.

lso-uses-localvolume-cr-static-provisioning [IN] OBSERVATION

LSO uses the LocalVolume CR (apiVersion local.storage.openshift.io/v1) and only supports static provisioning — not dynamic.

lvm-storage-only-local-dynamic-provisioning [IN] OBSERVATION

LVM Storage is the only local storage solution in OpenShift that supports dynamic provisioning, PVC expansion, volume snapshots, and volume clones.

lvm-storage-uses-topolvm-csi [IN] OBSERVATION

LVM Storage uses the TopoLVM CSI driver for dynamic provisioning and topology awareness.

machine-api-declarative-node-management [IN] OBSERVATION

Machine APIs are the declarative interface for managing compute node lifecycle (creation, scaling, deletion) in OpenShift.

machine-api-group-v1beta1 [IN] OBSERVATION

The Machine, MachineSet, and MachineHealthCheck resources use API group machine.openshift.io/v1beta1

machine-api-handles-post-install-provisioning [IN] OBSERVATION

The Machine API handles all node host provisioning after cluster installation (not during installation).

machine-api-key-objects [IN] OBSERVATION

Key Machine API objects are: Machine, MachineSet, MachineHealthCheck, MachineAutoscaler, and ClusterAutoscaler

machine-api-namespace [IN] OBSERVATION

Machine API objects reside in the openshift-machine-api namespace.

machine-api-operator-five-resources [IN] OBSERVATION

The Machine API Operator provisions exactly five resources: MachineSet, Machine, ClusterAutoscaler, MachineAutoscaler, and MachineHealthCheck.

machine-api-requires-cluster-admin [IN] OBSERVATION

Machine API operations require cluster-admin privileges.

machine-api-requires-ipi [IN] OBSERVATION

The Machine API is only operational on installer-provisioned infrastructure (IPI); UPI installations do not have compute machine sets by default.

machine-api-scaling-hierarchy [IN] OBSERVATION

The Machine API scaling hierarchy is: ClusterAutoscaler → MachineAutoscaler → MachineSet → Machine → Node.

machine-api-two-api-groups [IN] OBSERVATION

Machine management uses two API groups: machineconfiguration.openshift.io/v1 for node/OS-level configuration and machine.openshift.io (v1/v1beta1) for machine lifecycle.

machine-api-version-v1beta1 [IN] OBSERVATION

Machine objects use API version machine.openshift.io/v1beta1, kind Machine.

machine-approver-worker-csrs [IN] OBSERVATION

The Cluster Machine Approver auto-approves CSRs for new worker nodes; the bootstrap node approves control plane CSRs.

machine-autoscaler-namespace [IN] OBSERVATION

MachineAutoscaler resources must be created in the openshift-machine-api namespace.

machine-configs-applied-lexicographic-order [IN] OBSERVATION

Machine configs are applied in lexicographic order (00* through 99*); last file wins for conflicts.

machine-delete-annotation [IN] OBSERVATION

The annotation machine.openshift.io/delete-machine="true" marks a machine for preferential deletion when scaling down a MachineSet.

machine-deletion-order [IN] OBSERVATION

Machine deletion order is: preDrain hooks → drain node → preTerminate hooks → remove cloud instance → delete Node object.

machine-error-fields-terminal-only [IN] OBSERVATION

Machine errorMessage/errorReason fields are set only for terminal (non-transient) problems requiring manual intervention

machine-failed-phase-unrecoverable [IN] OBSERVATION

The Failed machine phase indicates an unrecoverable problem such as the cloud provider deleting the instance.

machine-lifecycle-hooks-two-types [IN] OBSERVATION

Machine lifecycle hooks have two types: preDrain (blocks drain and termination) and preTerminate (blocks termination, runs after drain completes)

machine-machineset-machinehealthcheck-v1beta1 [IN] OBSERVATION

Machine, MachineSet, and MachineHealthCheck are machine.openshift.io/v1beta1 (Compatibility Level 2), while ControlPlaneMachineSet is machine.openshift.io/v1 (Compatibility Level 1).

machine-management-varies-by-install-type [IN] OBSERVATION

Machine management capabilities differ by installation type — IPI installations typically offer more automation than UPI

machine-management-varies-by-installation-type [IN] OBSERVATION

Not all machine management tasks are available in all installation types; some features require IPI (Installer-Provisioned Infrastructure).

machine-one-to-one-with-node [IN] OBSERVATION

Each Machine object has a 1:1 relationship with a Kubernetes Node, linked via status.nodeRef and providerID

machine-phases [IN] OBSERVATION

Machine lifecycle phases are: Failed, Provisioning, Provisioned, Running, Deleting

machine-phases-five-states [IN] OBSERVATION

Machines in OpenShift have five lifecycle phases: Provisioning, Provisioned, Running, Deleting, and Failed.

machine-phases-lifecycle [IN] OBSERVATION

Machine phases progress through: Provisioning → Provisioned → Running → Deleting.

machine-providerid-autoscaler [IN] OBSERVATION

The providerID field on a Machine must match the Node's provider ID and is used by the cluster autoscaler to detect unregistered machines

machine-running-phase-noderef-populated [IN] OBSERVATION

A machine's status.nodeRef is populated only when it reaches the Running phase, after Ignition completes and the cluster machine approver approves the kubelet CSR.

machine-skip-drain-annotation [IN] OBSERVATION

The annotation machine.openshift.io/exclude-node-draining on a Machine skips node draining during deletion.

machine-taints-additive-reconciled [IN] OBSERVATION

Taints on Machine/MachineSet spec are additively reconciled to the Node — the controller re-applies them if manually removed but does not remove other taints

machineautoscaler-api-group [IN] OBSERVATION

MachineAutoscaler API group is autoscaling.openshift.io/v1beta1 — an OpenShift-specific CR, not upstream Kubernetes

machineautoscaler-namespace-openshift-machine-api [IN] OBSERVATION

MachineAutoscaler is namespaced, typically deployed in openshift-machine-api

machineautoscaler-namespaced-per-machineset [IN] OBSERVATION

MachineAutoscaler is a namespaced resource tied to specific MachineSets, defining min/max replicas for those MachineSets.

machineautoscaler-references-machineset [IN] OBSERVATION

MachineAutoscaler scales MachineSets to add or remove worker nodes and references a specific MachineSet.

machineautoscaler-required-fields [IN] OBSERVATION

MachineAutoscaler spec has three required fields: minReplicas, maxReplicas, and scaleTargetRef

machineautoscaler-requires-clusterautoscaler [IN] OBSERVATION

MachineAutoscaler requires the ClusterAutoscaler to be enabled in order to take effect

machineautoscaler-same-namespace-target [IN] OBSERVATION

MachineAutoscaler scaleTargetRef requires kind and name but not namespace — the target must be in the same namespace

machineautoscaler-v1beta1 [IN] OBSERVATION

MachineAutoscaler uses autoscaling.openshift.io/v1beta1 (not yet GA), while ClusterAutoscaler is at v1

machineconfig-crs-in-siteconfig-extramanifests [IN] OBSERVATION

Best practice is to put MachineConfig CRs in SiteConfig extraManifests so they are applied at install time rather than post-install.

machineconfig-ignition-version-3-2-0 [IN] OBSERVATION

MachineConfig objects use Ignition spec version 3.2.0 for defining systemd unit drop-ins.

machineconfig-targets-os-level [IN] OBSERVATION

MachineConfig targets OS-level settings including systemd units, files on disk, and kernel arguments on RHCOS nodes.

machineconfig-three-cr-types [IN] OBSERVATION

Three distinct CR types control node configuration: MachineConfig (OS-level), KubeletConfig (kubelet), ContainerRuntimeConfig (CRI-O)

machineconfig-three-primary-crs [IN] OBSERVATION

MachineConfig, KubeletConfig, and ContainerRuntimeConfig are the three primary custom resources for node-level configuration in OpenShift.

machineconfig-triggers-node-reboot [IN] OBSERVATION

Changes applied via MachineConfig trigger node reboots, rolled out by the MCO through MachineConfigPools

machineconfig-triggers-rolling-reboot [IN] OBSERVATION

Changes applied via MachineConfig typically trigger a rolling node reboot across the affected MachineConfigPool.

machineconfigpool-groups-nodes [IN] OBSERVATION

MachineConfigPool groups nodes that share the same machine configuration (e.g., worker, master pools)

machineconfigpool-groups-nodes-by-role [IN] OBSERVATION

MachineConfigPools group nodes that share the same machine configuration, using role labels like worker or master.

machineconfigpool-groups-nodes-for-rollout [IN] OBSERVATION

MachineConfigPool groups nodes that share the same MachineConfig and controls configuration rollout (e.g., master and worker pools).

machinehealthcheck-detects-deletes-replaces [IN] OBSERVATION

MachineHealthCheck detects unhealthy machines, deletes them, and provisions replacements on supported platforms.

machineosconfig-one-per-pool [IN] OBSERVATION

A separate MachineOSConfig CR is needed for each machine config pool when using on-cluster image layering.

machines-namespace-openshift-machine-api [IN] OBSERVATION

Machine and MachineSet resources managed by the Machine API live in the openshift-machine-api namespace.

machines-namespaced-openshift-machine-api [IN] OBSERVATION

Machine, MachineSet, and MachineHealthCheck are namespaced resources typically in the openshift-machine-api namespace

machineset-api-resource-name [IN] OBSERVATION

The full API resource name for machine sets is machinesets.machine.openshift.io (not just machinesets).

machineset-changes-not-retroactive [IN] OBSERVATION

MachineSet CR changes only affect newly created machines; existing machines are not updated when the MachineSet is modified.

machineset-default-replicas-1-deletepolicy-random [IN] OBSERVATION

MachineSet defaults: replicas is 1, deletePolicy is Random; valid delete policies are Random, Newest, Oldest

machineset-deletion-policy-default-random [IN] OBSERVATION

MachineSet deletion policy defaults to Random; other options are Newest and Oldest.

machineset-has-scale-subresource [IN] OBSERVATION

MachineSet has a dedicated /scale sub-resource for scaling operations

machineset-namespace-openshift-machine-api [IN] OBSERVATION

All MachineSet and Machine resources live in the openshift-machine-api namespace.

machineset-rolling-replacement-pattern [IN] OBSERVATION

To propagate MachineSet changes: annotate old machines with machine.openshift.io/delete-machine="true", scale up to 2× replicas, wait for new machines to reach Running, then scale back down.

machineset-scoped-single-availability-zone [IN] OBSERVATION

Each MachineSet is scoped to a single availability zone; the installer distributes MachineSets across zones automatically.

machineset-selector-must-match-template [IN] OBSERVATION

MachineSet selector must match the machine template's labels — a mismatch will cause issues

management-state-unmanaged-stops-reconciliation [IN] OBSERVATION

Setting managementState to Unmanaged on an operator.openshift.io/v1 resource stops the operator from reconciling changes

management-state-values [IN] OBSERVATION

The managementState field on OpenShift operator resources controls operator behavior with values: Managed (active), Unmanaged (hands-off), Removed

managementstate-controls-operator-behavior [IN] OBSERVATION

The managementState field on operator.openshift.io/v1 resources controls whether the operator actively manages its component, with values: Managed, Unmanaged, Removed

manual-approval-affects-all-operators-in-namespace [IN] OBSERVATION

Installing an Operator with Manual approval in a namespace causes all Operators in that namespace to use Manual approval and update together; use separate namespaces for independent updates.

manual-approval-all-operators-in-namespace [IN] OBSERVATION

Setting manual approval strategy applies to all Operators in the same namespace, not just the one being configured.

manual-approval-required-token-auth-clouds [IN] OBSERVATION

Token-based auth clusters (AWS STS, Azure Workload ID, GCP Workload Identity) require Manual approval strategy for operator Subscriptions

master-worker-label-selectors [IN] OBSERVATION

The label selector for control plane nodes is node-role.kubernetes.io/master; for workers it is node-role.kubernetes.io/worker.

max-ebs-volumes-per-node-39 [IN] OBSERVATION

The maximum number of EBS volumes per node is 39, with in-tree and CSI volumes counted separately.

maxunavailable-default-one-for-mcp [IN] OBSERVATION

The maxUnavailable default is 1 for all machine config pools; Red Hat recommends never setting it to 3 for the control plane pool.

mcd-four-critical-metrics [IN] OBSERVATION

Four critical MCD metrics that can block updates and upgrades: mcddrainerr, mcdpivoterr, mcdkubeletstate, and mcdrebooterr.

mcd-kubelet-health-threshold-2 [IN] OBSERVATION

The MCD kubelet health failure threshold is 2 — exceeding it signals a problem via the mcdkubeletstate metric.

mcd-metrics-available-since-ocp43 [IN] OBSERVATION

MCD metrics have been available since OpenShift Container Platform 4.3.

mcd-namespace-openshift-machine-config-operator [IN] OBSERVATION

MCD logs are in namespace openshift-machine-config-operator, container machine-config-daemon.

mcd-runs-as-daemonset [IN] OBSERVATION

The Machine Config Daemon (MCD) runs as a DaemonSet with one instance per node in the cluster.

mcd-three-states [IN] OBSERVATION

The Machine Config Daemon has exactly three states: Done, Working, and Degraded.

mce-210-rhel9-base-image [IN] OBSERVATION

The multicluster-operators-subscription image uses RHEL 9 base starting with MCE 2.10 (RHACM 2.10+); earlier versions use RHEL 8.

mco-boot-images-only-machinesets [IN] OBSERVATION

The only valid apiGroup for managedBootImages machineManagers is machine.openshift.io and the only valid resource is machinesets

mco-default-revision-limit-five [IN] OBSERVATION

failedRevisionLimit and succeededRevisionLimit default to 5 when set to 0 or unset; -1 means unlimited

mco-disruption-action-types [IN] OBSERVATION

Valid node disruption action types are Reboot, Drain, Reload, Restart, DaemonReload, and None — Reboot and None cannot be combined with other actions

mco-disruption-policy-limits [IN] OBSERVATION

nodeDisruptionPolicy supports a maximum of 50 file entries, 50 unit entries, and 10 actions per entry

mco-managed-boot-images-must-be-explicit [IN] OBSERVATION

managedBootImages must be explicitly configured in MachineConfiguration; when omitted, boot images are not updated during cluster upgrades

mco-manages-machineconfig-resources [IN] OBSERVATION

The Machine Config Operator (MCO) is the controller responsible for reconciling MachineConfig, KubeletConfig, and ContainerRuntimeConfig resources and applying changes to nodes.

mco-manages-os-config [IN] OBSERVATION

The Machine Config Operator (MCO) manages and applies OS-level configurations and updates between the kernel and kubelet layers

mco-node-disruption-policy-no-effect-on-upgrades [IN] OBSERVATION

The nodeDisruptionPolicy in MachineConfiguration only affects day-2 MachineConfig changes, not cluster upgrades

mco-node-update-order [IN] OBSERVATION

The MCO updates nodes alphabetically by zone (oldest first within a zone), cordons per maxUnavailable, then reboots.

mco-reconciles-machineconfig [IN] OBSERVATION

The Machine Config Operator (MCO) reconciles MachineConfig objects and applies them to nodes

mco-restarts-crio-not-nodes [IN] OBSERVATION

The MCO does not restart nodes for registry configuration changes — it restarts CRI-O only (cordon, restart CRI-O, uncordon)

mco-rollout-process [IN] OBSERVATION

MCO rollout process for config changes: render new MC → cordon → drain → write config → apply image → reboot.

mcp-api-group-v1-cluster-scoped [IN] OBSERVATION

MachineConfigPool uses API group machineconfiguration.openshift.io/v1 and is cluster-scoped (no namespace)

mcp-default-pools-master-worker [IN] OBSERVATION

Default MachineConfigPools are master and worker; custom pools can be created for specialized node roles

mcp-degraded-vs-unavailable [IN] OBSERVATION

In MCP, a node is degraded when configuration application fails; unavailable when updating or NodeReady is false

mcp-maxunavailable-default-1-no-zero [IN] OBSERVATION

MachineConfigPool maxUnavailable defaults to 1 and cannot be set to 0; use paused: true to stop updates instead

mcp-paused-stops-generation-and-updates [IN] OBSERVATION

Setting paused: true on a MachineConfigPool stops both generating new desiredMachineConfig and updating machines

mcp-updates-respect-pdbs [IN] OBSERVATION

MachineConfigPool updates respect Pod Disruption Budgets even when maxUnavailable is greater than 1

metadata-apis-category-contents [IN] OBSERVATION

The Metadata APIs category in OpenShift 4.17 includes: APIRequestCount, Binding, ComponentStatus, ConfigMap, ControllerRevision, Event, Lease, and Namespace.

metal3remediationtemplate-api-group-capi [IN] OBSERVATION

Metal3RemediationTemplate belongs to API group infrastructure.cluster.x-k8s.io/v1beta1 (Cluster API infrastructure provider), not metal3.io

metal3remediationtemplate-strategy-fields [IN] OBSERVATION

Metal3RemediationTemplate remediation strategy is configured via spec.template.spec.strategy with fields: type (string), retryLimit (integer), and timeout (string for time between retries)

metal3remediationtemplate-used-by-machinehealthcheck [IN] OBSERVATION

MachineHealthCheck references a Metal3RemediationTemplate to define what remediation action to take when a bare-metal machine is unhealthy

metallb-bare-metal-networking-model [IN] DERIVED

Bare metal clusters use MetalLB for load balancing with two complementary modes: Layer 2 (gratuitous ARP failover within ~10s) and BGP (constrained to single ASN/router-ID), providing external service access without cloud provider load balancers.

metallb-bgp-single-asn-requirement [IN] OBSERVATION

In OpenShift MetalLB, all BGP peers must share a single ASN (spec.myASN) and a single router ID — this differs from community MetalLB.

metallb-external-traffic-policy-local-vs-cluster [IN] OBSERVATION

MetalLB external traffic policy local preserves client IP but risks uneven distribution; cluster (default) obscures client IP but distributes evenly.

metallb-incompatible-with-ip-failover [IN] OBSERVATION

MetalLB and IP failover are incompatible; IP failover must be removed before installing MetalLB.

metallb-l2-failover-gratuitous-arp [IN] OBSERVATION

MetalLB Layer 2 failover uses gratuitous ARP with typical failover within 10 seconds.

metallb-l2-single-node-bottleneck [IN] OBSERVATION

In MetalLB Layer 2 mode, all traffic for a service flows through a single node, making it a failover mechanism rather than a true load balancer.

metallb-one-cr-per-cluster [IN] OBSERVATION

Only one MetalLB CR instance is supported per cluster; deleting it removes MetalLB from the cluster.

metallb-operator-bare-metal-only [IN] OBSERVATION

The MetalLB Operator provides load balancing specifically for bare metal clusters, not cloud deployments

metallb-six-custom-resources [IN] OBSERVATION

MetalLB uses six custom resources: MetalLB, IPAddressPool, L2Advertisement, BGPAdvertisement, BGPPeer, BFDProfile.

metallb-two-modes-l2-bgp [IN] OBSERVATION

MetalLB operates in two modes: Layer 2 (using ARP/NDP, single-node traffic) and BGP (router distributes traffic across nodes).

metrics-api-group-v1beta1 [IN] OBSERVATION

The Metrics API group is metrics.k8s.io/v1beta1 and provides NodeMetrics and PodMetrics resources that back oc top commands and HPA decisions.

metrics-memory-working-set [IN] OBSERVATION

Both NodeMetrics and PodMetrics report memory usage as the memory working set, not RSS or total allocated.

metrics-server-required-for-oc-top [IN] OBSERVATION

The Metrics Server must be running in the cluster for oc top node and oc top pods to work; it is deployed by default in OpenShift.

metrics-timestamp-window [IN] OBSERVATION

NodeMetrics and PodMetrics use timestamp and window fields to define the collection interval: metrics were collected during [Timestamp - Window, Timestamp].

mhc-control-plane-max-unhealthy-1 [IN] OBSERVATION

For control plane MachineHealthChecks, maxUnhealthy should be set to 1 to prevent action when multiple control plane nodes appear unhealthy.

mhc-empty-selector-matches-all [IN] OBSERVATION

A MachineHealthCheck with an empty selector matches all machines

mhc-failed-phase-immediate-remediation [IN] OBSERVATION

A machine with Failed phase is remediated immediately by MachineHealthCheck without waiting for timeout.

mhc-max-unhealthy-default-100-percent [IN] OBSERVATION

MachineHealthCheck maxUnhealthy defaults to 100% if not set, meaning remediation always proceeds.

mhc-maxunhealthy-circuit-breaker [IN] OBSERVATION

MachineHealthCheck maxUnhealthy is a circuit breaker — remediation stops if more than this many machines are unhealthy; setting it to 0 or 0% blocks all remediation

mhc-node-startup-timeout-zero-disables [IN] OBSERVATION

Setting MachineHealthCheck nodeStartupTimeout to "0" disables startup health checks (machines without nodes won't be remediated)

mhc-one-node-at-a-time [IN] OBSERVATION

MachineHealthCheck remediates only one node at a time (drains and deletes) to limit disruption.

mhc-pause-during-update [IN] OBSERVATION

MachineHealthCheck resources must be paused before cluster updates using annotation cluster.x-k8s.io/paused="" in the openshift-machine-api namespace, and resumed after

mhc-percentage-max-unhealthy-rounded-down [IN] OBSERVATION

Percentage-based maxUnhealthy values in MachineHealthCheck are rounded down.

mhc-remediation-template-optional [IN] OBSERVATION

MachineHealthCheck remediationTemplate is optional; without it, default remediation (delete and recreate machine) is used

mhc-unhealthy-conditions-ored [IN] OBSERVATION

MachineHealthCheck unhealthy conditions are OR'd — any single condition match triggers unhealthy status

mig-requires-ampere-max-7-instances [IN] OBSERVATION

Multi-Instance GPU (MIG) requires NVIDIA Ampere architecture or newer (A100, A30) and supports up to 7 independent GPU instances per physical GPU.

minimum-cpu-allocation-10m [IN] OBSERVATION

The minimum CPU allocation per pod is 10 mCPU (10 millicores), even if less is requested.

minreadyseconds-available-vs-ready [IN] OBSERVATION

The minReadySeconds field controls when a pod counts as "available" (ready for at least that many seconds) versus merely "ready".

mirror-config-applied-via-mco-registries-conf [IN] OBSERVATION

Mirror configuration from IDMS/ITMS/ImageContentPolicy is applied to nodes by the Machine Config Operator via /etc/containers/registries.conf, which may trigger node reboots

mirror-registries-auto-added-unauthenticated-ignore [IN] OBSERVATION

Mirror registries defined in registries.conf are automatically added to the unauthenticated ignore list — no need to list them under spec.unauthenticatedRegistries in AgentServiceConfig.

mirror-registry-configmap-multicluster-engine-namespace [IN] OBSERVATION

The ConfigMap for mirror registry configuration must be in namespace multicluster-engine with label app: assisted-service.

mirror-registry-docker-v2-2-required [IN] OBSERVATION

Mirror registries must support Docker v2-2 manifest format.

mixed-mtu-nodes-use-lowest [IN] OBSERVATION

When cluster nodes have different MTU values, the cluster network MTU must be set to the lowest node MTU minus the overlay overhead.

monitoring-config-configmap [IN] OBSERVATION

Cluster Monitoring configuration is edited via the cluster-monitoring-config ConfigMap in the openshift-monitoring namespace.

monitoring-from-collection-through-alerting [IN] DERIVED

The monitoring-to-alerting pipeline is fully layered: metrics collection feeds recording and alerting rules (evaluated at 30s default intervals), AlertRelabelConfigs filter before reaching Alertmanager, inhibit rules suppress duplicates via source/target matching, and silences require persistent storage — creating a complete observe→evaluate→route→notify chain.

monitoring-rbac-roles [IN] OBSERVATION

Access to monitoring APIs is governed by cluster roles including cluster-monitoring-view, monitoring-edit, and monitoring-rules-edit.

monitoring-requires-explicit-enablement-beyond-platform [IN] DERIVED

Platform monitoring is automatic but both user workload monitoring and distributed tracing require explicit administrator action to enable, creating a two-tier observability model.

monitoring-stack-layered-architecture [IN] DERIVED

OpenShift monitoring uses a layered architecture where AlertingRules generate PrometheusRules, AlertRelabelConfigs filter before Alertmanager, and inhibit rules suppress cascading alerts — forming a three-stage alert pipeline.

monitoring-two-api-groups [IN] OBSERVATION

OpenShift monitoring CRDs span two API groups: monitoring.coreos.com (upstream prometheus-operator) and monitoring.openshift.io (OpenShift-specific wrappers).

mtc-custom-resources [IN] OBSERVATION

MTC uses MigCluster, MigStorage, MigPlan, and MigMigration custom resources for managing migrations

mtc-for-stateful-workload-migration [IN] OBSERVATION

The Migration Toolkit for Containers (MTC) is the supported tool for migrating stateful application workloads between OCP 4 clusters

mtc-installed-via-operatorhub [IN] OBSERVATION

MTC is an Operator installed from OperatorHub — it is not a built-in platform feature

mtc-pv-migration-strategies [IN] OBSERVATION

MTC supports two PV migration strategies: move (direct transfer) and copy (snapshot or filesystem copy)

mtc-uses-velero-via-oadp [IN] OBSERVATION

MTC leverages Velero (via OADP — OpenShift API for Data Protection) under the hood for backup/restore operations

mtu-migration-requires-two-reboots [IN] OBSERVATION

MTU migration on OpenShift requires at least two rolling reboots and is disruptive; rollback is not possible during migration.

mtu-migration-requires-two-rolling-reboots [IN] OBSERVATION

MTU migration requires at least two rolling reboots of all cluster nodes; MCO reboots one node per pool at a time by default.

mtu-migration-three-phase-process [IN] OBSERVATION

MTU migration is a 3-phase process: (1) patch CNO with migration spec on Network.operator.openshift.io, (2) update hardware MTU on nodes, (3) finalize by setting spec.migration to null and updating ovnKubernetesConfig.mtu.

mtu-no-rollback-during-migration [IN] OBSERVATION

You cannot roll back MTU during an active migration; rollback is only possible after the migration completes.

mtv-migration-toolkit-for-virtualization [IN] OBSERVATION

Migration Toolkit for Virtualization (MTV) is the official supported tool for migrating VMs at scale to OpenShift Virtualization from other platforms.

multi-attach-storage-rwx-vs-rwo [IN] OBSERVATION

Multi-attach storage errors are resolved by either using RWX (ReadWriteMany) volumes or recovering/deleting the failed node for RWO (ReadWriteOnce) volumes.

multi-cni-network-architecture [IN] DERIVED

OpenShift networking uses a layered CNI architecture: OVN-Kubernetes as default primary CNI, Multus as meta-plugin for additional interfaces, connecting to SR-IOV, bridge, and macvlan secondaries.

multi-level-autoscaling-architecture [IN] DERIVED

OpenShift autoscaling operates at three distinct levels: infrastructure scaling (ClusterAutoscaler + MachineAutoscaler add/remove nodes), pod horizontal scaling (HPA for built-in metrics, KEDA for external triggers like Kafka/Cron), and pod vertical scaling (VPA adjusts requests/limits) — each level operates independently but infrastructure scaling is gated on having at least one MachineAutoscaler deployed.

multicluster-engine-delivered-separately [IN] OBSERVATION

The multicluster engine for Kubernetes Operator is included with OCP subscription but delivered separately from the core payload and must be explicitly installed.

multicluster-engine-enabled-by-default-in-rhacm [IN] OBSERVATION

Multicluster engine is enabled by default when Red Hat Advanced Cluster Management (RHACM) is installed.

multicluster-engine-full-lifecycle-ocp-only [IN] OBSERVATION

Multicluster engine provides full lifecycle management for OCP clusters but only partial lifecycle management for non-OCP Kubernetes distributions.

multinetworkpolicy-api-group [IN] OBSERVATION

MultiNetworkPolicy uses the API group k8s.cni.cncf.io/v1beta1, distinct from the native NetworkPolicy API group networking.k8s.io/v1

multinetworkpolicy-applies-to-secondary-networks [IN] OBSERVATION

MultiNetworkPolicy applies network policy rules to secondary networks (additional interfaces attached via Multus CNI), not the primary pod network

multinetworkpolicy-selectors-depend-on-subnets [IN] OBSERVATION

MultiNetworkPolicy selectors depend on subnets config: with subnets defined, podSelector/namespaceSelector/ipBlock are available; without subnets, only ipBlock is allowed.

multinetworkpolicy-spec-identical-to-networkpolicy [IN] OBSERVATION

MultiNetworkPolicy spec is structurally identical to Kubernetes NetworkPolicy — same fields for podSelector, ingress, egress, and policyTypes

multiple-default-storageclass-alert [IN] OBSERVATION

Only one StorageClass should be default at any time; multiple defaults trigger a MultipleDefaultStorageClasses alert, and the most recently created default is used.

multiple-identities-per-user [IN] OBSERVATION

Multiple Identity objects can map to a single User object, enabling authentication from multiple identity providers.

multus-auto-names-interfaces-net1-net2 [IN] OBSERVATION

Multus automatically names attached secondary interfaces as net1, net2, net3, etc., unless overridden with the @name suffix in the pod annotation.

multus-cni-enables-multiple-network-attachments [IN] OBSERVATION

Multus CNI is the meta-plugin that enables attaching multiple network interfaces to pods in OpenShift

must-gather-audit-logs-not-default [IN] OBSERVATION

Audit logs are not collected by default with oc adm must-gather; they require explicit -- /usr/bin/gatherauditlogs

must-gather-creates-pod-on-control-plane [IN] OBSERVATION

oc adm must-gather creates a temporary pod on a random control plane node to collect debugging data

must-gather-default-plus-feature-image-stream [IN] OBSERVATION

To collect default data AND feature-specific data together, add --image-stream=openshift/must-gather alongside --image

must-gather-default-timeout-10min [IN] OBSERVATION

oc adm must-gather default timeout is 10 minutes

must-gather-diagnostic-data-collection [IN] OBSERVATION

The oc adm must-gather command is used to collect diagnostic data for submitting support cases to Red Hat.

must-gather-disconnected-import-image [IN] OBSERVATION

In disconnected environments, import the must-gather image first with oc import-image is/must-gather -n openshift

must-gather-fallback-oc-adm-inspect [IN] OBSERVATION

oc adm inspect is the fallback when oc adm must-gather cannot schedule its pod

must-gather-multiple-images-one-command [IN] OBSERVATION

Multiple --image flags can be combined in a single oc adm must-gather command to collect data for multiple features

must-gather-network-logs-command [IN] OBSERVATION

Network logs require -- gathernetworklogs; by default only OVN nbdb/sbdb databases are collected

must-gather-primary-support-tool [IN] OBSERVATION

oc adm must-gather is the primary recommended tool for collecting cluster diagnostic data when opening a support case with Red Hat.

must-gather-requires-cluster-admin [IN] OBSERVATION

oc adm must-gather requires the cluster-admin role

must-gather-volume-percentage-default-30 [IN] OBSERVATION

oc adm must-gather default --volume-percentage is 30%

mutating-webhook-api-group [IN] OBSERVATION

MutatingWebhookConfiguration belongs to API group admissionregistration.k8s.io/v1

mutating-webhook-can-modify-objects [IN] OBSERVATION

MutatingWebhookConfiguration webhooks can accept, reject, or modify incoming objects, unlike ValidatingWebhookConfiguration which can only accept or reject

mutating-webhooks-run-before-validating [IN] OBSERVATION

Mutating admission plugins run before validating admission plugins in the admission chain.

nad-api-group-v1 [IN] OBSERVATION

NetworkAttachmentDefinition uses API group k8s.cni.cncf.io/v1 and is a namespace-scoped resource defined by the Network Plumbing Working Group

nad-config-is-json-string [IN] OBSERVATION

NetworkAttachmentDefinition spec.config field is a JSON string (not a nested object) containing the full CNI plugin configuration

nad-crd-defines-secondary-networks [IN] OBSERVATION

NetworkAttachmentDefinition (NAD) is the CRD used to define and configure secondary network attachments for pods

nad-network-names-cluster-unique [IN] OBSERVATION

NetworkAttachmentDefinition (NAD) network names must be unique across the entire cluster; multiple NADs with different configs referencing the same network name is unsupported.

nad-network-names-cross-namespace [IN] OBSERVATION

NAD network names are not namespaced — a network named identically in different namespace NADs enables cross-namespace pod communication on the same secondary network.

namespace-api-core-v1 [IN] OBSERVATION

Namespace is a core v1 API resource in Kubernetes/OpenShift, served at /api/v1/ (not under any API group)

namespace-finalize-endpoint-unstick [IN] OBSERVATION

The /api/v1/namespaces/{name}/finalize PUT endpoint is used to clear finalizers and resolve a namespace stuck in Terminating state

namespace-finalizers-prevent-deletion [IN] OBSERVATION

Namespace finalizers are the mechanism that prevents premature deletion; a namespace stuck in Terminating typically has uncleared finalizers

namespace-two-phases-active-terminating [IN] OBSERVATION

Namespaces have exactly two phases: Active and Terminating

namespace-watch-endpoints-deprecated [IN] OBSERVATION

The dedicated /api/v1/watch/namespaces endpoints are deprecated; use the watch query parameter on list operations instead

namespaces-not-for-cluster-wide-resources [IN] OBSERVATION

Namespaces scope deployments, services, and pods, but do NOT apply to cluster-wide resources such as storage classes, nodes, and persistent volumes.

nbde-binds-encryption-to-network-presence [IN] OBSERVATION

NBDE (Network-Bound Disk Encryption) ties LUKS encryption keys to network presence using Tang servers and Clevis clients, enabling automatic decryption without manual password entry.

nbde-must-enable-at-install-time [IN] OBSERVATION

NBDE must be enabled at OpenShift installation time, but disk encryption policy can be changed post-installation.

nbde-node-no-tang-no-boot [IN] OBSERVATION

A node configured with NBDE that cannot reach its Tang servers at boot will retry indefinitely and cannot boot.

nbde-protects-entire-server-theft [IN] OBSERVATION

NBDE is the only supported OpenShift encryption method that protects against entire-server theft and never transmits keys over the network; TPM alone does not protect against entire-server theft.

netobserv-cli-capture-duration-limits [IN] OBSERVATION

Network Observability CLI default max capture time is 5 minutes for flows/packets and 1 hour for metrics; recommended max is 8-10 minutes

netobserv-cli-feature-flags-not-packets [IN] OBSERVATION

Network Observability CLI feature options (--enablepktdrop, --enablertt, --enabledns) work with flows and metrics commands but NOT with packets

netobserv-cli-max-capture-bytes [IN] OBSERVATION

Network Observability CLI default maximum capture size is 50MB

netobserv-cli-output-formats [IN] OBSERVATION

Network Observability CLI flow output is JSON + SQLite DB (./output/flow/), packet output is PCAP (./output/pcap/), and metrics output is a Prometheus dashboard via service monitor

netobserv-cli-separate-from-operator [IN] OBSERVATION

The Network Observability CLI (oc netobserv) is installed separately from the Network Observability Operator — they are independent components

netobserv-console-plugin-dual-registration [IN] OBSERVATION

Console plugin registration requires both spec.consolePlugin.register: true in the FlowCollector and netobserv-plugin listed in console.operator.openshift.io

netobserv-conversation-logtypes [IN] OBSERVATION

FlowCollector logTypes values for conversation tracking: Flows, All (highest storage), Conversations, EndedConversations (lowest storage)

netobserv-default-enabled-metrics [IN] OBSERVATION

Network Observability default-enabled metrics are namespaceflowstotal, nodeingressbytestotal, and workloadingressbytestotal

netobserv-flow-export-destinations [IN] OBSERVATION

Network flow data can be exported to Kafka, stored in Loki, and used for Prometheus metrics via FlowMetrics API

netobserv-flow-filter-actions [IN] OBSERVATION

eBPF flow filter actions: Accept (cache in eBPF table) and Reject (drop, don't cache); unmatched flows are cached by default

netobserv-loki-label-fields [IN] OBSERVATION

Network Observability Loki stream selector labels are: DstK8SNamespace, DstK8SOwnerName, DstK8SType, DstK8SZone, FlowDirection, K8SClusterName, K8SFlowLayer, SrcK8SNamespace, SrcK8SOwnerName, SrcK8SType, SrcK8SZone, _RecordType

netobserv-loki-recommended-backend [IN] OBSERVATION

Loki is the recommended storage backend for Network Observability flow logs

netobserv-metrics-configured-in-includeList [IN] OBSERVATION

Network Observability metrics are configured via spec.processor.metrics.includeList in the FlowCollector custom resource

netobserv-metrics-prefix [IN] OBSERVATION

All Network Observability Operator metrics are prefixed with netobserv_ in Prometheus

netobserv-must-gather-image [IN] OBSERVATION

The must-gather image for Network Observability is quay.io/netobserv/must-gather

netobserv-operator-cluster-scoped [IN] OBSERVATION

Network Observability is a cluster-level capability, not namespace-scoped observation only

netobserv-operator-memory-via-subscription [IN] OBSERVATION

Network Observability Operator memory limits are configured via the Subscription object's spec.config.resources, not the FlowCollector

netobserv-operator-not-default [IN] OBSERVATION

The Network Observability Operator is an optional, installable component — not enabled by default in OpenShift

netobserv-packet-drop-types [IN] OBSERVATION

Network Observability packet drops are classified as host drops (prefixed SKBDROP) and OVS drops (prefixed OVSDROP)

netobserv-pktdrop-requires-privileged [IN] OBSERVATION

PacketDrop metrics require privileged mode enabled in spec.agent.ebpf.features of the FlowCollector CR

netobserv-rtt-nanoseconds-divider [IN] OBSERVATION

Network Observability RTT values are provided in nanoseconds; use divider: "1000000000" to convert to seconds for Prometheus

netobserv-rtt-uses-srtt-hookpoint [IN] OBSERVATION

Network Observability RTT uses TCP smoothed RTT (sRTT) from the fentry/tcprcvestablished eBPF hookpoint

netobserv-three-console-views [IN] OBSERVATION

Network Observability provides three console views: Overview, Traffic Flows, and Topology — accessed under Observe → Network Traffic

netobserv-topology-default-layout-cola [IN] OBSERVATION

Network Observability Topology view default layout is Cola; other options are ColaNoForce, Concentric, Dagre, Force, Grid

netobserv-uses-ebpf-collection [IN] OBSERVATION

The Network Observability Operator uses eBPF technology for efficient flow collection at the kernel level

netpol-additive-union-semantics [IN] OBSERVATION

Multiple NetworkPolicy objects are additive — traffic allowed by any matching policy is permitted (union logic).

netpol-audit-log-location [IN] OBSERVATION

Network policy audit logs are stored at /var/log/ovn/acl-audit-log.log inside OVN-Kubernetes node pods.

netpol-audit-logging-annotation [IN] OBSERVATION

OVN-Kubernetes network policy audit logging is enabled via the k8s.ovn.org/acl-logging annotation on the namespace, with deny/allow severity keys.

netpol-cannot-block-localhost-or-node-traffic [IN] OBSERVATION

NetworkPolicy cannot block traffic from localhost or from the pod's resident node.

netpol-default-all-pods-accessible [IN] OBSERVATION

All pods in a project are accessible from all other pods and network endpoints until a NetworkPolicy is applied.

netpol-default-policies-via-project-template [IN] OBSERVATION

Default network policies for new projects are injected by modifying the project request template in the openshift-config namespace.

netpol-deny-all-ingress-pattern [IN] OBSERVATION

A NetworkPolicy with podSelector: {} and empty ingress: [] creates a deny-all-ingress policy; ingress: [{}] (empty rule) means allow-all-ingress.

netpol-from-entry-and-vs-or-logic [IN] OBSERVATION

Combined namespaceSelector + podSelector in a single from entry uses AND logic; separate from entries use OR logic.

netpol-ingress-controller-namespace-label [IN] OBSERVATION

To allow traffic from the OpenShift Ingress Controller, match on namespace label policy-group.network.openshift.io/ingress: "".

netpol-multitenant-isolation-three-policies [IN] OBSERVATION

Multitenant isolation requires three policies per namespace: deny-by-default, allow-same-namespace, and allow-from-ingress.

netpol-supported-protocols-tcp-udp-icmp-sctp [IN] OBSERVATION

NetworkPolicy only affects TCP, UDP, ICMP, and SCTP protocols — other protocols are unaffected.

netpol-unselected-pods-remain-accessible [IN] OBSERVATION

A pod not selected by any NetworkPolicy remains fully accessible — it is not denied by default.

network-architecture-layered-with-dual-stack-constraints [IN] DERIVED

OpenShift networking combines a multi-CNI plugin architecture (OVN-Kubernetes + Multus for secondary interfaces) with dual-stack IPv4/IPv6 support, but dual-stack imposes additional constraints on service network blocks, MTU, and virtualization workloads.

network-config-singleton-named-cluster [IN] OBSERVATION

The Network resource (config.openshift.io/v1) is a cluster-scoped singleton with canonical name cluster

network-connectivity-check-every-minute [IN] OBSERVATION

The CNO connectivity check controller runs TCP connection health checks every minute in parallel, storing results in PodNetworkConnectivityCheck objects.

network-diagnostics-configured-on-network-cr [IN] OBSERVATION

Network diagnostics are configured on the Network CR named cluster (API: config.openshift.io/v1) under spec.networkDiagnostics with modes All (default), Disabled, or empty string (= All).

network-diagnostics-log-reasons [IN] OBSERVATION

Network connectivity check log reason values are: TCPConnect, TCPConnectError, DNSResolve, DNSError.

network-diagnostics-namespace [IN] OBSERVATION

All network connectivity diagnostic resources live in the openshift-network-diagnostics namespace.

network-diagnostics-node-labels-before-config [IN] OBSERVATION

Node labels must be applied before updating the network diagnostics configuration — labels applied after are ignored.

network-diagnostics-source-deployment-target-daemonset [IN] OBSERVATION

The network diagnostics source pod is a Deployment (single replica) and target pods are a DaemonSet (runs on every node).

network-flow-export-ovn-only [IN] OBSERVATION

Network flow export (NetFlow, SFlow, IPFIX) is only supported on OVN-Kubernetes

network-metrics-daemon-publishes-pod-network-name-info [IN] OBSERVATION

The Network Metrics Daemon is a daemonset that collects and publishes network-related metrics including podnetworkname_info to supplement kubelet's built-in container network metrics.

network-name-label-format-namespace-nad [IN] OBSERVATION

The networkname label in podnetworknameinfo uses the format <namespace>/<NetworkAttachmentDefinition name>, derived from the Multus k8s.v1.cni.cncf.io/network-status annotation.

network-observability-operator-netobserv-dashboard [IN] OBSERVATION

The Network Observability Operator is optional and provides an additional Netobserv dashboard when installed.

network-plugin-selected-at-install-time [IN] OBSERVATION

The network plugin (OVN-Kubernetes or OpenShift SDN) is selected at cluster install time.

network-policies-are-additive [IN] OBSERVATION

When multiple NetworkPolicies select the same pod, the union of all their rules applies (policies are additive, not overriding).

network-policies-operate-at-l3-l4 [IN] OBSERVATION

Kubernetes NetworkPolicies operate at L3/L4 (IP address and port level) and do not support L7 filtering (e.g., HTTP path or header matching).

network-policy-deny-by-default-when-selected [IN] OBSERVATION

When any NetworkPolicy selects a pod, all traffic not explicitly allowed by a policy is denied; pods with no selecting policy allow all traffic.

network-policy-evaluation-order [IN] OBSERVATION

Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy

network-policy-selectors [IN] OBSERVATION

NetworkPolicy rules use podSelector, namespaceSelector, and ipBlock to select traffic sources and destinations.

network-read-status-not-spec [IN] OBSERVATION

Consumers should read status (not spec) on the Network config to see the currently deployed network configuration

network-resource-singleton-cluster [IN] OBSERVATION

The Network operator resource (operator.openshift.io/v1) is always named "cluster" — exactly one per cluster

network-security-two-mechanisms [IN] OBSERVATION

OpenShift network security is primarily implemented through two distinct mechanisms: network policies (pod/namespace-level ingress/egress) and egress firewalls (cluster-to-external traffic).

network-type-ovnkubernetes [IN] OBSERVATION

The only currently supported networkType value is OVNKubernetes

networking-and-observability-integrated-stack [IN] DERIVED

OpenShift networking and network observability form an integrated stack: the layered CNI architecture (OVN-Kubernetes + Multus) with dual-stack addressing provides the data plane, while the observability pipeline (eBPF→FlowCollector→Loki) provides flow-level visibility — both following the platform's explicit multi-component enablement pattern.

networkpolicy-empty-ingress-denies-all [IN] OBSERVATION

In both NetworkPolicy and MultiNetworkPolicy, an empty ingress array means deny all inbound traffic; an empty egress array means deny all outbound traffic

networkpolicy-endport-no-named-ports [IN] OBSERVATION

NetworkPolicy endPort field creates inclusive port ranges but cannot be used with named ports

networkpolicy-ipblock-mutually-exclusive-with-selectors [IN] OBSERVATION

In NetworkPolicy peers, ipBlock cannot be combined with podSelector or namespaceSelector in the same peer entry

networkpolicy-local-node-traffic-always-allowed [IN] OBSERVATION

Traffic from a pod's local node is always allowed for ingress, regardless of NetworkPolicy rules

networkpolicy-no-policy-means-all-allowed [IN] OBSERVATION

When no NetworkPolicy selects a pod, all traffic is allowed by default (default allow); once any policy selects a pod, only explicitly allowed traffic is permitted

networkpolicy-podselector-only-required-field [IN] OBSERVATION

The only required field in a NetworkPolicy or MultiNetworkPolicy spec is podSelector; an empty podSelector {} matches all pods in the namespace

networkpolicy-protocol-defaults-tcp [IN] OBSERVATION

In NetworkPolicy and MultiNetworkPolicy, the protocol field defaults to TCP when not specified

networkpolicy-rules-additive-across-policies [IN] OBSERVATION

Multiple NetworkPolicies selecting the same pod have their rules combined additively (union); you cannot use NetworkPolicy to deny traffic that another policy allows

never-scale-machineset-zero-with-router-pods [IN] OBSERVATION

Never scale a compute machine set to 0 without first relocating router pods, as they are needed for cluster access including the web console.

never-scale-workers-to-zero-without-router-relocation [IN] OBSERVATION

Worker machine sets should never be scaled to 0 without first relocating router pods, which run on workers by default and are required for web console access.

nfd-detects-and-labels-hardware-features [IN] OBSERVATION

Node Feature Discovery (NFD) detects hardware features on nodes and labels them for scheduling purposes.

nfd-prerequisite-for-gpu-operator [IN] OBSERVATION

The Node Feature Discovery (NFD) Operator must be installed before the GPU Operator; NFD detects GPU hardware so the GPU Operator can manage it.

nfd-required-alongside-gpu-operators [IN] OBSERVATION

Node Feature Discovery (NFD) is typically required alongside GPU operators to detect hardware capabilities on nodes.

nfs-supports-all-access-modes [IN] OBSERVATION

NFS supports all access modes (RWO, ROX, RWX). AWS EBS and Azure Disk only support RWO/RWOP.

nmstate-all-enactments-fail-means-policy-issue [IN] OBSERVATION

If all NMState enactments fail, the problem is likely in the policy; if only some fail, the problem is likely node-specific.

nmstate-automatic-rollback-on-failure [IN] OBSERVATION

NMState automatically rolls back failed network configurations — triggered by: failed apply, lost default gateway connectivity, or lost API server connectivity.

nmstate-cannot-update-primary-nic [IN] OBSERVATION

The NMState Operator cannot update the primary NIC or br-ex bridge on most on-premise networks.

nmstate-config-path-on-nodes [IN] OBSERVATION

NMState bonding configuration is base64-encoded and delivered via MachineConfig to the path /etc/nmstate/openshift/cluster.yml on nodes.

nmstate-declarative-node-networking [IN] OBSERVATION

Kubernetes NMState provides declarative management of node network configuration (interfaces, bridges, bonds, VLANs, routes) via Kubernetes custom resources.

nmstate-disconnected-dns-root-servers-net [IN] OBSERVATION

In disconnected environments, NMState health checks probe root-servers.net; the DNS server must have an NS entry for this zone or health checks will fail.

nmstate-instance-singleton-named-nmstate [IN] OBSERVATION

The NMState CR instance is a cluster-wide singleton and must be named nmstate.

nmstate-namespace-openshift-nmstate [IN] OBSERVATION

The Kubernetes NMState Operator installs into the openshift-nmstate namespace.

nmstate-nnce-failing-jsonpath [IN] OBSERVATION

The jsonpath filter '{.status.conditions[?(@.type=="Failing")].message}' extracts the error message from an NMState enactment resource.

nmstate-olm-no-auto-delete-crds [IN] OBSERVATION

Uninstalling the NMState Operator via OLM does not automatically delete CRDs, CRs, or API Services — manual cleanup is required.

nmstate-operator-not-enabled-by-default [IN] OBSERVATION

The NMState Operator must be installed separately from OperatorHub; it is not enabled by default in OpenShift.

nmstate-operator-required [IN] OBSERVATION

The Kubernetes NMState Operator must be installed before NMState features can be used.

nmstate-resource-shortnames [IN] OBSERVATION

NMState resource shortnames: nncp (NodeNetworkConfigurationPolicy), nnce (NodeNetworkConfigurationEnactment), nns (NodeNetworkState).

nmstate-supported-platforms [IN] OBSERVATION

NMState is supported on bare-metal, IBM Power, IBM Z/LinuxONE, VMware vSphere, and RHOSP, with limited Azure support (DNS only).

nmstate-three-crds [IN] OBSERVATION

Kubernetes NMState uses three core CRDs: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).

nmstate-three-custom-resources [IN] OBSERVATION

Kubernetes NMState uses three key custom resources: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).

nmstate-troubleshooting-flow [IN] OBSERVATION

NMState troubleshooting flow: oc get nncp (policy status) → oc get nnce (per-node status) → inspect failing enactment with jsonpath → oc get nns (actual node state) → oc edit nncp (fix policy).

nnce-tracks-per-node-policy-status [IN] OBSERVATION

NodeNetworkConfigurationEnactment (NNCE) tracks per-node status of policy application (success/failure), named as <node-name>.<policy-name>.

nncp-declares-desired-network-state [IN] OBSERVATION

NodeNetworkConfigurationPolicy (NNCP) is the resource administrators create to declare and apply desired network state across matching nodes.

nns-read-only-per-node [IN] OBSERVATION

NodeNetworkState (NNS) is read-only and automatically created per node — it reports current network configuration.

no-direct-etcd-access [IN] OBSERVATION

All etcd operations must go through the API server or documented backup/restore procedures — direct etcd access is not supported.

no-privileged-ports-in-containers [IN] OBSERVATION

Container processes in OpenShift must not listen on privileged ports (below 1024) because they run as non-root

node-affinity-required-terms-ored-expressions-anded [IN] OBSERVATION

Node affinity requiredDuringSchedulingIgnoredDuringExecution terms are ORed; within each term, match expressions are ANDed

node-affinity-terms-ored-expressions-anded [IN] OBSERVATION

Node affinity nodeSelectorTerms are ORed; matchExpressions within a single term are ANDed.

node-allocatable-defaults-to-capacity [IN] OBSERVATION

Node .status.allocatable defaults to .status.capacity; the difference represents resources reserved for system daemons.

node-api-group-core-v1 [IN] OBSERVATION

The Node resource uses the core v1 API group (/api/v1/nodes) and is a cluster-scoped (not namespaced) Kubernetes resource.

node-belongs-one-mcp [IN] OBSERVATION

A node can only belong to one MCP; custom pools take priority over the worker pool based on node labels.

node-cgroupmode-v1-or-v2 [IN] OBSERVATION

spec.cgroupMode on the Node config controls whether nodes use cgroups v1 or v2; changing requires node reboots

node-condition-status-values [IN] OBSERVATION

Node condition .status field accepts three values: True, False, or Unknown.

node-config-immutable-delivery-pipeline [IN] DERIVED

Node configuration follows an immutable delivery pipeline: RHCOS nodes accept changes only via Operators and rpm-ostree atomic images, while image mirroring configuration flows through oc-mirror → IDMS manifests → MCO → registries.conf on nodes — both channels enforce the immutable infrastructure contract.

node-config-singleton-named-cluster [IN] OBSERVATION

The Node resource (config.openshift.io/v1) is a cluster-scoped singleton with canonical name cluster, distinct from core Kubernetes Node objects

node-cordon-sets-unschedulable [IN] OBSERVATION

oc adm cordon sets unschedulable: true on a node, which only prevents new pod scheduling and does not evict existing pods.

node-fleet-heterogeneous-runtime-model [IN] DERIVED

The OpenShift node fleet is fundamentally heterogeneous: RHCOS nodes follow an immutable rpm-ostree model with operator-mediated changes, while Windows nodes use an entirely different container runtime (not CRI-O) and require OVN-Kubernetes hybrid networking — operational procedures, troubleshooting, and capacity planning must account for this runtime divergence.

node-heartbeat-every-10-seconds [IN] OBSERVATION

Nodes send heartbeats every 10 seconds to the kube controller manager (node-status-update-frequency: 10s).

node-maintenance-order-cordon-drain-uncordon [IN] OBSERVATION

Correct node maintenance order: cordon first, then drain, perform maintenance, then uncordon.

node-metrics-dashboard-location [IN] OBSERVATION

The Node Metrics Dashboard is accessed from the Administrator perspective under Observe → Dashboards → Node cluster filter.

node-metrics-kubelet-crio-threshold-50pct [IN] OBSERVATION

The Node Metrics Dashboard critical threshold for individual Kubelet and CRI-O reserved CPU and memory utilization is 50%.

node-metrics-no-critical-data-means-no-anomalies [IN] OBSERVATION

No data appearing in the Node Metrics Dashboard Critical category means no anomalies were detected, not a dashboard malfunction.

node-metrics-system-reserved-threshold-80pct [IN] OBSERVATION

The Node Metrics Dashboard critical threshold for overall system reserved CPU and memory utilization is 80%.

node-monitor-grace-period-40s [IN] OBSERVATION

The default node-monitor-grace-period is 40 seconds; after this period without a heartbeat, node status becomes Unknown.

node-monitor-grace-period-40s-not-modifiable [IN] OBSERVATION

The node-monitor-grace-period is 40 seconds and cannot be modified; after this period without heartbeat the node is marked Unhealthy.

node-phase-deprecated-use-conditions [IN] OBSERVATION

The Node .status.phase field is deprecated and never populated; .status.conditions should be used instead.

node-podcidrs-dual-stack-limit [IN] OBSERVATION

A node's podCIDRs field can contain at most 1 IPv4 and 1 IPv6 value for dual-stack support, and podCIDRs[0] must match podCIDR.

node-reserved-memory-formula [IN] OBSERVATION

System reserved resources are calculated as total capacity minus allocatable (kubenodestatuscapacity - kubenodestatusallocatable).

node-selector-operators [IN] OBSERVATION

Valid node selector operators are In, NotIn, Exists, DoesNotExist, Gt, and Lt.

node-selector-operators-list [IN] OBSERVATION

Node selector operators are: In, NotIn, Exists, DoesNotExist, Gt, Lt

node-statuses-tracks-per-node-deployment [IN] OBSERVATION

The status.nodeStatuses[] field on static pod operators tracks per-node deployment state including currentRevision, targetRevision, lastFailedRevision, and lastFallbackCount

node-taint-effects-three [IN] OBSERVATION

Node taints support three effects: NoSchedule (hard block, existing pods stay), PreferNoSchedule (soft, scheduler tries to avoid), and NoExecute (evicts non-tolerating pods).

node-tuning-operator-uses-tuned-one-per-node [IN] OBSERVATION

The Node Tuning Operator uses TuneD daemons for kernel tuning, running one per node across all nodes.

nodemetrics-read-only [IN] OBSERVATION

NodeMetrics is a read-only API resource (GET only; no create/update/delete) at endpoints /apis/metrics.k8s.io/v1beta1/nodes and /apis/metrics.k8s.io/v1beta1/nodes/{name}.

nodename-bypasses-scheduler [IN] OBSERVATION

Setting nodeName on a Pod bypasses the scheduler entirely, directly assigning the Pod to the named node.

nodenetworkstate-read-only [IN] OBSERVATION

NodeNetworkState (NNS) resources are read-only and report current node network state.

nodes-must-be-uncordoned-after-restart [IN] OBSERVATION

Nodes are cordoned during graceful shutdown and must be uncordoned during restart to become schedulable.

non-graceful-shutdown-causes [IN] OBSERVATION

Non-graceful node shutdown can be caused by hardware/system failures, missing Inhibitor Locks triggers, or misconfigured shutdownGracePeriod/shutdownGracePeriodCriticalPods settings.

nutanix-ahv-hypervisor [IN] OBSERVATION

Nutanix AHV is the hypervisor layer used for OCP installations on Nutanix; Prism Element manages individual clusters.

nutanix-boot-type-legacy-417 [IN] OBSERVATION

In OCP 4.17, the boot type for Nutanix VMs must be set to Legacy (options are Legacy, SecureBoot, UEFI).

nutanix-cco-manual-mode-required [IN] OBSERVATION

The Cloud Credential Operator (CCO) must be set to manual mode for Nutanix installations — this is not optional.

nutanix-ccoctl-linux-only [IN] OBSERVATION

The ccoctl binary for CCO manual mode is Linux-only and must be run in a Linux environment.

nutanix-csi-storage-integration [IN] OBSERVATION

Nutanix provides CSI-based persistent storage integration (Nutanix Volumes/Files) out of the box for OpenShift.

nutanix-default-cni-ovnkubernetes [IN] OBSERVATION

The default (and only listed) network type for Nutanix OCP installations is OVNKubernetes.

nutanix-default-replicas-3-3 [IN] OBSERVATION

Default compute replicas for Nutanix OCP installations is 3; control plane replicas must be 3 (or 1 for SNO).

nutanix-delete-machine-annotation [IN] OBSERVATION

The annotation machine.openshift.io/delete-machine="true" marks machines for deletion during scale-down on Nutanix (and other platforms).

nutanix-disk-reserved-indices [IN] OBSERVATION

On Nutanix, Disk.SCSI.0 and CDRom.IDE.0 device indices are reserved; custom data disks using those adapter types must start at deviceIndex 1.

nutanix-dns-api-ingress-vips [IN] OBSERVATION

Nutanix OCP installations require DNS records for api.<cluster>.<domain> and *.apps.<cluster>.<domain>, resolvable both externally and from within the cluster.

nutanix-failure-domain-same-network [IN] OBSERVATION

Machines across Nutanix Prism Element failure domains must reside on the same Ethernet network with subnets sharing the same CIDR containing cluster VIPs.

nutanix-failure-domain-three-recommended [IN] OBSERVATION

Three failure domains are recommended for high availability on Nutanix OpenShift clusters.

nutanix-failure-domains-ha [IN] OBSERVATION

Nutanix failure domains enable high availability by distributing VMs across different Prism Element clusters and subnets.

nutanix-full-platform-integration [IN] DERIVED

Nutanix provides integrated OCP infrastructure: AHV hypervisor with Prism management, CSI-based persistent storage, GPU passthrough on compute nodes, and reserved disk indices for system use.

nutanix-gpu-passthrough-compute [IN] OBSERVATION

GPU passthrough is supported on Nutanix compute machines, identified by Name or DeviceID.

nutanix-infrastructure-cr-before-machinesets [IN] OBSERVATION

The Infrastructure CR (infrastructures.config.openshift.io) must be configured with failure domains before updating control plane or compute machine sets to reference them.

nutanix-install-config-immutable [IN] OBSERVATION

Parameters in install-config.yaml (including networking) cannot be changed after OCP installation on Nutanix.

nutanix-ipi-primary-install-method [IN] OBSERVATION

OCP on Nutanix uses installer-provisioned infrastructure (IPI) as the primary installation method.

nutanix-ipi-supported-from-ocp-411 [IN] OBSERVATION

Nutanix is a supported IPI platform for OpenShift Container Platform, introduced in OCP 4.11.

nutanix-min-versions-aos-prism [IN] OBSERVATION

Nutanix minimum versions for OCP 4.17: AOS 6.5.2.7+ and Prism Central pc.2022.6+.

nutanix-one-subnet-per-failure-domain [IN] OBSERVATION

Only one subnet per failure domain per OpenShift cluster is supported on Nutanix.

nutanix-only-ipv4-supported [IN] OBSERVATION

Only IPv4 addresses are supported for Nutanix network configuration in OCP 4.17.

nutanix-prism-central-management-plane [IN] OBSERVATION

Nutanix Prism Central is used as the management plane for OCP cluster provisioning on Nutanix.

nutanix-requires-api-ingress-vips [IN] OBSERVATION

Nutanix platform configuration requires apiVIPs and ingressVIPs as mandatory parameters in install-config.yaml.

nutanix-runs-on-ahv-integrates-prism-central [IN] OBSERVATION

OCP on Nutanix runs on the AHV hypervisor and integrates with Prism Central (not Prism Element directly) for IPI installations.

nutanix-single-prism-central-required [IN] OBSERVATION

All Nutanix Prism Element instances used as failure domains must be managed by a single Prism Central instance; multi-Prism-Central is unsupported.

nutanix-single-prism-element [IN] OBSERVATION

Nutanix infrastructure configuration requires prismCentral and prismElements; currently only one Prism Element per cluster is supported

nutanix-standard-cluster-resources [IN] OBSERVATION

A standard Nutanix OCP installation creates 3 control plane + 3 compute + 1 temporary bootstrap = 7 VMs during install (6 after bootstrap teardown), requiring minimum 800 GB storage.

nutanix-supported-ocp-install-platform [IN] OBSERVATION

Nutanix is a supported installation platform for OpenShift Container Platform.

nutanix-supported-ocp-platform [IN] OBSERVATION

Nutanix is a supported installation platform for OpenShift Container Platform 4.17, running on Nutanix AHV (Acropolis Hypervisor).

nutanix-supports-ipi-and-upi [IN] OBSERVATION

Nutanix supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods for OCP.

nutanix-upi-manual-cleanup-after-destroy [IN] OBSERVATION

UPI clusters on Nutanix may leave behind resources requiring manual cleanup after openshift-install destroy cluster.

nutanix-uses-prism-central-api [IN] OBSERVATION

Nutanix installations use Prism Central (not Prism Element) as the API endpoint for the OpenShift installer integration.

nvidia-gpu-operator-supported-by-nvidia-only [IN] OBSERVATION

The NVIDIA GPU Operator is supported only by NVIDIA, not by Red Hat.

oadp-1-1-required-for-csi-on-ocp-4-11 [IN] OBSERVATION

OADP 1.1.x is required for CSI backup on OCP 4.11+ because OADP 1.0.x uses snapshot.storage.k8s.io/v1beta1 which is absent on 4.11+.

oadp-1-4-supports-ocp-4-14-to-4-17 [IN] OBSERVATION

OADP 1.4 supports OCP 4.14–4.17; OADP 1.3 supports OCP 4.12–4.15.

oadp-built-on-velero [IN] OBSERVATION

OADP (OpenShift API for Data Protection) is the supported method for application-level backup and restore and is built on Velero.

oadp-csi-plugin-builtin-1-4 [IN] OBSERVATION

In OADP 1.4, the CSI plugin is built into Velero and no longer requires a separate init container.

oadp-data-mover-uses-kopia [IN] OBSERVATION

OADP Data Mover uses Kopia under the hood to move CSI snapshots to remote object storage.

oadp-five-core-apis [IN] OBSERVATION

OADP provides five core APIs: Backup, Restore, Schedule, BackupStorageLocation, and VolumeSnapshotLocation.

oadp-full-cluster-backup-not-supported [IN] OBSERVATION

Full cluster backup and restore is not supported by OADP — only workload namespaces and cluster-scoped resources.

oadp-installs-in-openshift-adp-namespace [IN] OBSERVATION

OADP installs in the openshift-adp namespace by default.

oadp-is-ocp-backup-solution [IN] OBSERVATION

OADP (OpenShift API for Data Protection) is the supported backup and restore solution for OpenShift Container Platform.

oadp-is-velero-based [IN] OBSERVATION

OADP (OpenShift API for Data Protection) is the Red Hat-supported solution for application backup and restore, built on Velero.

oadp-not-disaster-recovery [IN] OBSERVATION

OADP (OpenShift API for Data Protection) is not a disaster recovery solution for etcd or OpenShift Operators — it only protects customer workloads, cluster-scoped resources, and persistent volumes.

oadp-requires-cluster-admin-and-object-storage [IN] OBSERVATION

OADP requires the cluster-admin role and object storage (S3-compatible, AWS, Azure, GCP, ODF, IBM Cloud).

oadp-upgrade-sequential-only [IN] OBSERVATION

OADP upgrades must be sequential — never skip minor versions (e.g., 1.1→1.2→1.3→1.4).

oauth-api-group [IN] OBSERVATION

OAuth API objects in OpenShift live in the oauth.openshift.io API group and are OpenShift-specific extensions (not part of upstream Kubernetes).

oauth-api-group-version [IN] OBSERVATION

OAuth API resources in OpenShift belong to the oauth.openshift.io/v1 API group.

oauth-api-objects-openshift-specific [IN] OBSERVATION

OAuth API objects (OAuthClient, OAuthAuthorizeToken, OAuthAccessToken, UserOAuthAccessToken, OAuthClientAuthorization) are OpenShift-specific resources, not part of standard Kubernetes.

oauth-authorize-token-dual-user-verification [IN] OBSERVATION

On OAuthAuthorizeToken, both userName and userUID must match for the token to be valid (dual verification).

oauth-authorize-token-pkce-support [IN] OBSERVATION

OAuthAuthorizeToken supports PKCE (RFC 7636) via codeChallenge and codeChallengeMethod fields.

oauth-compatibility-level-1 [IN] OBSERVATION

All five OAuth API resources have Compatibility Level 1: stable within a major release for at least 12 months or 3 minor releases.

oauth-config-requires-integrated-oauth [IN] OBSERVATION

The OAuth resource configuration (oauth.config.openshift.io) is only honored when the Authentication resource has type: IntegratedOAuth.

oauth-config-singleton-named-cluster [IN] OBSERVATION

The OAuth resource (config.openshift.io/v1) is a cluster-scoped singleton named cluster that configures the integrated OAuth server

oauth-delete-token-revokes-session [IN] OBSERVATION

Deleting an OAuthAccessToken object effectively revokes that user's session/token.

oauth-expiresin-seconds-from-creation [IN] OBSERVATION

The expiresIn field on OAuth tokens is measured in seconds from CreationTimestamp, defining absolute maximum token lifetime.

oauth-five-api-resources [IN] OBSERVATION

The five OAuth API resources are: OAuthAccessToken, OAuthAuthorizeToken, OAuthClient, OAuthClientAuthorization, and UserOAuthAccessToken.

oauth-inactivity-timeout-sliding [IN] OBSERVATION

The inactivityTimeoutSeconds field on OAuthAccessToken is automatically incremented on token use, implementing sliding session expiry rather than fixed expiry.

oauth-mapping-method-default-claim [IN] OBSERVATION

The mappingMethod for OAuth identity providers defaults to "claim"

oauth-metadata-external-in-openshift-config [IN] OBSERVATION

External OAuth metadata is stored in a ConfigMap in the openshift-config namespace; integrated OAuth metadata is in openshift-config-managed.

oauth-missing-secret-silently-ignored [IN] OBSERVATION

If a referenced secret/configmap for an OAuth identity provider is missing, the provider is silently not honored (no error)

oauth-requires-integratedoauth-type [IN] OBSERVATION

OAuth config is only honored when the Authentication config has type set to IntegratedOAuth

oauth-resources-cluster-scoped [IN] OBSERVATION

OAuth API resources (OAuthAccessToken, OAuthAuthorizeToken, etc.) are cluster-scoped resources (no namespace in the API path).

oauth-secrets-configmaps-openshift-config [IN] OBSERVATION

All secrets and configmaps referenced by OAuth identity providers must reside in the openshift-config namespace

oauth-server-route-namespace [IN] OBSERVATION

The OpenShift OAuth server is exposed via a route named oauth-openshift in the openshift-authentication namespace.

oauth-session-lifecycle-management [IN] DERIVED

OpenShift OAuth session management operates through five API resources, where deleting an OAuthAccessToken actively revokes a user session — providing both programmatic and administrative session control.

oauth-supported-identity-providers [IN] OBSERVATION

Supported OAuth identity provider types: HTPasswd, LDAP, BasicAuth, RequestHeader, Keystone, GitHub, GitLab, Google, OpenID Connect

oauth-token-inactivity-auto-increments [IN] OBSERVATION

OAuthAccessToken inactivityTimeoutSeconds auto-increments when the token is used, resetting the idle timeout.

oauth-token-sha256-prefix [IN] OBSERVATION

OAuth access token resource names use the format sha256~<base64url-hash>, derived by SHA-256 hashing the raw token and encoding with URL-safe unpadded base64 (RFC 4648).

oauth-watch-endpoints-deprecated [IN] OBSERVATION

The dedicated /watch/ endpoints for OAuth resources are deprecated; the ?watch=true query parameter on list operations should be used instead.

oauthclient-additional-secrets-rotation [IN] OBSERVATION

OAuthClient additionalSecrets field enables secret rotation without downtime by supporting multiple valid secrets simultaneously.

oauthclient-cluster-scoped [IN] OBSERVATION

OAuthClient is a cluster-scoped resource (no namespace) in the oauth.openshift.io/v1 API group.

oauthclient-grant-method-auto-prompt [IN] OBSERVATION

OAuthClient grantMethod field accepts auto (auto-approve for trusted clients) or prompt (requires user approval for third-party clients).

oauthclient-inactivity-timeout-not-retroactive [IN] OBSERVATION

Changing accessTokenInactivityTimeoutSeconds on an OAuthClient does NOT retroactively affect existing tokens — only newly issued tokens.

oauthclient-respond-with-challenges [IN] OBSERVATION

OAuthClient respondWithChallenges: true returns WWW-Authenticate challenges instead of redirects, useful for CLI and non-browser clients.

oauthclient-scope-restriction-allowlist [IN] OBSERVATION

OAuthClient scope restrictions use an allowlist model: any matching restriction allows the scope; if no restriction matches, the scope is denied.

oauthclient-token-inactivity-min-300 [IN] OBSERVATION

OAuthClient accessTokenInactivityTimeoutSeconds minimum non-zero value is 300 (5 minutes); setting to 0 disables inactivity timeout entirely.

oauthclientauthorization-cluster-scoped [IN] OBSERVATION

OAuthClientAuthorization is a cluster-scoped resource in the oauth.openshift.io/v1 API group.

oauthclientauthorization-delete-revokes [IN] OBSERVATION

Deleting an OAuthClientAuthorization effectively revokes the user's authorization for that OAuth client.

oauthclientauthorization-username-and-uid-required [IN] OBSERVATION

Both userName AND userUID must match for an OAuthClientAuthorization to be valid — knowing just the username is insufficient.

observability-follows-platform-enablement-pattern [IN] DERIVED

OpenShift observability is a specific instance of the platform-wide multi-component enablement pattern: like service mesh, it requires explicit opt-in beyond the default platform layer (user workload monitoring, distributed tracing), layered component composition (AlertingRules → PrometheusRules → Alertmanager), and multi-operator coordination.

observability-four-pillars [IN] OBSERVATION

Red Hat OpenShift Observability covers four signal types: metrics, logs, traces, and events.

observability-integrated-platform-capability [IN] OBSERVATION

Observability in OpenShift is provided as an integrated platform capability and is a top-level architectural concern, not a bolt-on or sub-component of another subsystem.

observability-requires-layered-enablement [IN] DERIVED

OpenShift observability operates through a layered enablement model: the monitoring stack itself is architecturally layered (AlertingRules → PrometheusRules → AlertRelabelConfig → Alertmanager), but only platform monitoring is automatic — user workload monitoring and distributed tracing require explicit admin action.

observability-subsystems [IN] OBSERVATION

OpenShift Observability encompasses monitoring (Prometheus/Thanos), logging (OpenShift Logging subsystem), distributed tracing (Jaeger/Tempo), and network observability (flow-based analysis).

observed-config-lives-in-spec [IN] OBSERVATION

The observedConfig field on OpenShift operator resources is stored in .spec (not .status) because it serves as input to the operator's reconciliation loop

oc-adm-drain-cordon-uncordon [IN] OBSERVATION

oc adm cordon marks a node unschedulable; oc adm uncordon re-enables scheduling; oc adm drain evicts pods and marks the node unschedulable.

oc-adm-drain-cordon-uncordon-node-maintenance [IN] OBSERVATION

Node maintenance uses oc adm cordon (mark unschedulable), oc adm drain (evacuate pods), and oc adm uncordon (mark schedulable again).

oc-adm-drain-uses-eviction-api [IN] OBSERVATION

oc adm drain uses the Eviction API internally to safely remove pods from a node.

oc-adm-groups-command-family [IN] OBSERVATION

The oc adm groups command family is the primary CLI for group management (e.g., oc adm groups new, oc adm groups add-users, oc adm groups sync).

oc-adm-groups-commands [IN] OBSERVATION

Groups are managed via oc adm groups new, oc adm groups add-users, and oc adm groups remove-users commands.

oc-adm-groups-management-commands [IN] OBSERVATION

oc adm groups new, oc adm groups add-users, and oc adm groups remove-users are the standard commands for managing group membership

oc-adm-must-gather-for-support [IN] OBSERVATION

oc adm must-gather is the command to collect cluster data for Red Hat support cases.

oc-adm-node-logs-by-role [IN] OBSERVATION

The command oc adm node-logs --role <role> -u kubelet gathers kubelet logs by node role without requiring SSH access.

oc-adm-node-logs-preferred-over-ssh [IN] OBSERVATION

oc adm node-logs --role=master -u kubelet is the preferred way to get node logs over SSH when the API is accessible.

oc-adm-policy-add-scc-to-user-command [IN] OBSERVATION

The command oc adm policy add-scc-to-user <scc> <user> grants an SCC to a user.

oc-adm-policy-manages-role-assignments [IN] OBSERVATION

oc adm policy add-role-to-user and oc adm policy add-cluster-role-to-user are the primary commands for managing role assignments in OpenShift.

oc-adm-policy-who-can-uses-resourceaccessreview [IN] OBSERVATION

The CLI command oc adm policy who-can <verb> <resource> -n <namespace> uses the LocalResourceAccessReview/ResourceAccessReview API under the hood.

oc-adm-policy-z-flag-service-account [IN] OBSERVATION

The -z flag in oc adm policy add-role-to-user specifies a service account (not a user). Example: oc adm policy add-role-to-user view -z default grants view to the default service account.

oc-adm-release-mirror-command [IN] OBSERVATION

oc adm release mirror mirrors OCP release images to a local registry; its imageContentSources output must be added to install-config.yaml.

oc-adm-top-requires-metrics-cluster-reader [IN] OBSERVATION

oc adm top nodes/pods requires both the metrics stack installed and cluster-reader permission.

oc-adm-upgrade-include-not-recommended [IN] OBSERVATION

oc adm upgrade --include-not-recommended shows conditional updates with known risks that are not normally displayed.

oc-adm-upgrade-primary-command [IN] OBSERVATION

oc adm upgrade is the primary CLI command for viewing and applying cluster updates; --to-latest=true applies the latest, --to=<version> targets a specific version

oc-adm-upgrade-status-tech-preview [IN] OBSERVATION

oc adm upgrade status is a Technology Preview command requiring OCENABLECMDUPGRADESTATUS=true environment variable; works on clusters 4.12+

oc-api-resources-and-explain-for-discovery [IN] OBSERVATION

oc api-resources lists all available API resources including extensions; oc explain <resource> inspects API object schemas from the CLI.

oc-api-resources-config-group [IN] OBSERVATION

Config API resources can be listed with oc api-resources --api-group=config.openshift.io

oc-api-resources-discovers-apis [IN] OBSERVATION

Available API resources on an OpenShift cluster can be discovered using oc api-resources and explored with oc explain <resource>

oc-api-resources-lists-all-api-objects [IN] OBSERVATION

The oc api-resources command lists all available API objects in the cluster, including their short names, API groups, and whether they are namespaced.

oc-api-resources-lists-extensions [IN] OBSERVATION

The command oc api-resources lists all available API resources on an OpenShift cluster, including extension APIs.

oc-auth-can-i-checks-permissions [IN] OBSERVATION

oc auth can-i <verb> <resource> is the CLI equivalent of creating SubjectAccessReview/SelfSubjectAccessReview resources for checking permissions.

oc-auth-can-i-wraps-sar [IN] OBSERVATION

The oc auth can-i --as=<user> command is the CLI equivalent of creating a SubjectAccessReview

oc-cli-primary-tool-admins-and-devs [IN] OBSERVATION

The oc CLI is the primary general-purpose OpenShift CLI tool, used by both administrators and developers.

oc-compatible-with-kubectl [IN] OBSERVATION

The oc CLI is compatible with kubectl but provides additional OpenShift-specific features.

oc-create-token-for-service-account [IN] OBSERVATION

oc create token <service-account-name> creates a TokenRequest for a service account (bound token with audience/expiry).

oc-debug-node-chroot-host [IN] OBSERVATION

oc debug node/<node> followed by chroot /host is the standard method to access a node's filesystem for troubleshooting.

oc-describe-clusterversion-detailed [IN] OBSERVATION

oc describe clusterversion provides detailed update history and available updates for the cluster.

oc-explain-config-resource [IN] OBSERVATION

oc explain <resource>.config.openshift.io shows the schema/documentation for a cluster config resource

oc-explain-from-cluster-api [IN] OBSERVATION

oc explain <resource> retrieves documentation directly from the cluster's API schema, useful for exploring resource fields.

oc-explain-inspects-api-schema [IN] OBSERVATION

The oc explain <resource> command inspects API object schemas directly from the cluster, with oc explain <resource>.spec drilling into spec fields.

oc-explain-inspects-operator-api-schemas [IN] OBSERVATION

The oc explain command can be used to inspect Operator API object schemas directly from the cluster.

oc-explain-shows-api-fields [IN] OBSERVATION

The oc explain <resource> command displays API field documentation for a resource directly from the CLI.

oc-extends-kubectl [IN] OBSERVATION

The oc CLI extends kubectl with OpenShift-specific commands such as oc new-project, oc new-app, and others.

oc-get-clusterversion-quick-status [IN] OBSERVATION

oc get clusterversion provides a quick summary of cluster version, availability, progressing status, and uptime.

oc-homebrew-formula-name [IN] OBSERVATION

The Homebrew formula for oc is openshift-cli (installed via brew install openshift-cli).

oc-idle-scales-to-zero [IN] OBSERVATION

The oc idle <service> command scales all scalable resources associated with a service to zero replicas to conserve resources.

oc-idle-single-project-scope [IN] OBSERVATION

The oc idle command is limited to a single project — it cannot idle resources across multiple projects in one invocation.

oc-import-image-cli-for-imagestreamimport [IN] OBSERVATION

The oc import-image command is the CLI interface to the ImageStreamImport API; use --confirm to actually import, --all to import an entire repository.

oc-in-pod-defaults-to-pod-namespace [IN] OBSERVATION

When oc runs inside a pod without a namespace specified, it defaults to the pod's namespace.

oc-login-creates-oauthaccesstoken [IN] OBSERVATION

The oc login flow creates OAuthAccessToken objects behind the scenes.

oc-login-web-uses-http-localhost [IN] OBSERVATION

The oc login --web flag runs a localhost HTTP server (not HTTPS) for the callback — a security concern on shared workstations.

oc-mirror-generates-idms [IN] OBSERVATION

The oc-mirror plugin generates IDMS manifests when mirroring content to a local registry

oc-must-match-cluster-version [IN] OBSERVATION

The oc CLI must match the cluster version — earlier versions of oc cannot complete all commands for the target OCP release.

oc-new-app-creates-resources-not-routes [IN] OBSERVATION

oc new-app automatically creates ImageStream, Deployment, and Service (plus BuildConfig for S2I builds), but does NOT create Routes — routes must be created separately with oc create route edge.

oc-new-app-template-instantiation [IN] OBSERVATION

oc new-app --template=<name> can instantiate applications from templates

oc-new-app-tilde-syntax-creates-s2i [IN] OBSERVATION

The oc new-app <builder-image>~<git-repo-url> tilde syntax creates an S2I BuildConfig automatically.

oc-new-project-creates-and-switches [IN] OBSERVATION

oc new-project both creates a new project and switches the current context to that project.

oc-new-project-uses-projectrequest [IN] OBSERVATION

oc new-project uses the ProjectRequest API, not direct Project creation.

oc-patch-pv-reclaim-policy [IN] OBSERVATION

The command oc patch pv <name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' changes the reclaim policy on an existing PV.

oc-process-renders-template [IN] OBSERVATION

oc process renders a template into a resource list; oc new-app --template= can process and create resources in one step

oc-proxy-env-vars [IN] OBSERVATION

The oc CLI respects HTTPPROXY, HTTPSPROXY, and NO_PROXY environment variables; authentication headers are only sent over HTTPS.

oc-rpm-not-supported-rhel9 [IN] OBSERVATION

RPM installation of the oc CLI (yum install openshift-clients) is not supported on RHEL 9 — binary download must be used instead.

oc-set-image-lookup-command [IN] OBSERVATION

oc set image-lookup <imagestream> enables image lookup on an image stream; oc set image-lookup deploy/<name> enables it on a specific resource; --enabled=false disables it.

oc-set-probe-syntax [IN] OBSERVATION

Health probes are set with oc set probe deployment/<name> --liveness|--readiness --get-url=http://:port/path --initial-delay-seconds=N.

oc-set-triggers-deploy-syntax [IN] OBSERVATION

The command oc set triggers deploy/<name> --from-image=<stream>:<tag> -c <container> configures image stream change triggers on a Deployment by setting the image.openshift.io/triggers annotation.

oc-set-volume-default-emptydir [IN] OBSERVATION

The default volume type when using oc set volume --add is emptyDir.

oc-set-volume-overwrite-flag [IN] OBSERVATION

The --overwrite flag is required when updating an existing volume with oc set volume.

oc-start-build-from-dir-binary-input [IN] OBSERVATION

The oc start-build --from-dir command uploads local content as binary input to a build.

oc-tag-creates-permanent-tags-by-default [IN] OBSERVATION

The default oc tag behavior creates permanent tags (pinned to image ID); use --alias=true to create tracking tags.

oc-version-must-match-cluster [IN] OBSERVATION

The oc binary version must match the cluster version; earlier versions cannot complete all commands.

oci-agent-based-installer [IN] OBSERVATION

OpenShift on OCI is installed using the Agent-based Installer, which provides Assisted Installation capabilities for both connected and disconnected environments.

oci-agent-iso-command [IN] OBSERVATION

The command ./openshift-install agent create image --log-level debug generates the agent ISO image for OCI installations.

oci-cluster-topologies [IN] OBSERVATION

Supported cluster topologies on OCI are: single-node, HA (3 control plane + 2 compute minimum), and compact 3-node (3 control plane only).

oci-disconnected-bootartifactsbaseurl [IN] OBSERVATION

Disconnected OCI installations require bootArtifactsBaseURL in agent-config.yaml and a separately hosted rootfs image.

oci-dns-a-records-required [IN] OBSERVATION

OCI installations require three DNS A records: api.<cluster>.<domain> and api-int.<cluster>.<domain> pointing to apiVIP, and *.apps.<cluster>.<domain> pointing to ingressVIP.

oci-ovnkubernetes-default-network [IN] OBSERVATION

OVNKubernetes is the default network type used for OCI installations of OpenShift.

oci-platform-type-external [IN] OBSERVATION

OCI is configured as platform.external with platformName: oci and cloudControllerManager: External in install-config.yaml — it is not a native integrated platform.

oci-rendezvousip-must-match-instance [IN] OBSERVATION

The rendezvousIP in agent-config.yaml must be an IPv4 address from the VCN CIDR that matches at least one booted instance's IP.

oci-supported-architectures [IN] OBSERVATION

OCI installations support 64-bit x86 (amd64) and 64-bit ARM (arm64) architectures.

oci-supported-platform-ocp-417 [IN] OBSERVATION

Oracle Cloud Infrastructure (OCI) is a supported installation target for OpenShift Container Platform starting from version 4.17.

oci-uefi-boot-required [IN] OBSERVATION

Custom images on OCI must be configured to boot in UEFI mode for OpenShift installation.

ocm-manages-rosa-aro-osd [IN] OBSERVATION

OpenShift Cluster Manager is the control plane for ROSA (AWS), ARO (Azure), OSD (GCP/AWS) managed clusters, and also supports registered self-managed OCP clusters.

ocm-saas-at-console-redhat-com [IN] OBSERVATION

OpenShift Cluster Manager (OCM) is a Red Hat-hosted SaaS console at console.redhat.com for centralized management of OpenShift clusters, distinct from per-cluster web consoles.

ocm-supports-three-cluster-types [IN] OBSERVATION

OCM supports three cluster types: OpenShift Container Platform (self-managed), Red Hat OpenShift Service on AWS (ROSA), and OpenShift Dedicated.

ocm-update-strategy-automatic-or-manual [IN] OBSERVATION

OCM cluster update strategy can be set to automatic (scheduled day/time) or manual.

ocm-url-console-redhat [IN] OBSERVATION

OpenShift Cluster Manager (OCM) is accessible at console.redhat.com/openshift and requires a Red Hat account belonging to an OpenShift organization.

ocp-3x-to-4x-architectural-shift [IN] OBSERVATION

The OpenShift version jump from 3.x to 4.x reflects a major architectural shift to an operator-driven, immutable infrastructure model using RHEL CoreOS and the Cluster Version Operator.

ocp-410-san-certificate-requirement [IN] OBSERVATION

Starting with OCP 4.10, HTTPS certificates must contain Subject Alternative Name (SAN) fields; certificates with only CommonName are rejected.

ocp-417-favors-vector-lokistack [IN] OBSERVATION

OpenShift 4.17 favors Vector (collector) + LokiStack (store) over the legacy Fluentd + Elasticsearch logging stack.

ocp-417-follows-416 [IN] OBSERVATION

OCP 4.17 follows OCP 4.16 in the continuous 4.x minor-version release cadence.

ocp-417-has-16-optional-capabilities [IN] OBSERVATION

OpenShift Container Platform 4.17 has 16 optional cluster capabilities: baremetal, Build, CloudControllerManager, CloudCredential, ImageRegistry, Storage, Console, CSISnapshot, DeploymentConfig, Ingress, Insights, MachineAPI, marketplace, NodeTuning, openshift-samples, and OperatorLifecycleManager.

ocp-417-optional-cluster-capabilities [IN] OBSERVATION

OpenShift Container Platform 4.17 supports optional cluster capabilities that can be selectively enabled or disabled.

ocp-417-uses-kubernetes-130 [IN] OBSERVATION

OpenShift Container Platform 4.17 is built on Kubernetes 1.30 with CRI-O as the container runtime.

ocp-421-ai-workloads-section [IN] OBSERVATION

OpenShift Container Platform 4.21 has a dedicated documentation section for AI workloads, signaling first-class platform support for AI training.

ocp-421-current-release [IN] OBSERVATION

OCP 4.21 is the current documented release of OpenShift Container Platform

ocp-421-latest-version [IN] OBSERVATION

OpenShift Container Platform 4.21 is the latest version in the 4.x release line as of the current documentation.

ocp-4x-kubernetes-based [IN] OBSERVATION

OpenShift Container Platform 4.x is built on Kubernetes for deploying and managing containerized applications at scale.

ocp-additional-default-clusterroles [IN] OBSERVATION

OpenShift adds additional default ClusterRoles beyond Kubernetes defaults, including admin, edit, view, cluster-admin, and self-provisioner.

ocp-adds-enterprise-features [IN] OBSERVATION

OpenShift adds enterprise features that Kubernetes lacks at the platform level: authentication, networking, security, monitoring, and log management.

ocp-admin-ack-required-api-removal-gate [IN] OBSERVATION

When updating across y-streams that remove Kubernetes APIs, OpenShift requires an admin acknowledgment (AdminAckRequired gate) via patching the admin-acks ConfigMap in openshift-config namespace.

ocp-admin-can-disable-self-provisioning [IN] OBSERVATION

Cluster admins can prevent authenticated user groups from self-provisioning new projects in OpenShift.

ocp-admission-plugins-skip-privileged-projects [IN] OBSERVATION

Admission plugins (pod security admission, SCCs, cluster resource quotas, image reference resolution) do not work in highly privileged projects.

ocp-agent-installer-available-412 [IN] OBSERVATION

The Agent-based Installer is available starting from OCP 4.12.

ocp-agent-installer-bootable-iso [IN] OBSERVATION

The Agent-based Installer generates a bootable ISO containing the cluster configuration, eliminating the need for a separate bootstrap machine.

ocp-agent-installer-disconnected [IN] OBSERVATION

The Agent-based Installer is the recommended method for disconnected/air-gapped on-premise OpenShift installations.

ocp-ai-training-multi-node [IN] OBSERVATION

OpenShift AI workload support focuses on large-scale AI training workloads running reliably across multiple nodes (distributed training).

ocp-alertingrule-generates-prometheusrule [IN] OBSERVATION

Each AlertingRule generates a corresponding PrometheusRule in the openshift-monitoring namespace.

ocp-alertingrule-no-recording-rules [IN] OBSERVATION

The AlertingRule resource only permits alerting rules; recording rules are explicitly prohibited.

ocp-alertingrule-not-prometheusrule [IN] OBSERVATION

Cluster admins must use the AlertingRule resource (monitoring.openshift.io/v1) to create custom alerts on the platform monitoring stack — not PrometheusRule directly.

ocp-alertmanagerconfig-api-v1beta1 [IN] OBSERVATION

AlertmanagerConfig uses API version monitoring.coreos.com/v1beta1 (beta, not yet stable v1).

ocp-alertmanagerconfig-namespace-scoped [IN] OBSERVATION

AlertmanagerConfig is namespace-scoped — it only applies to alerts whose namespace label matches the namespace where the resource is created, enforced by the operator.

ocp-alertmanagerconfig-route-first-level [IN] OBSERVATION

The route defined in AlertmanagerConfig is added as a first-level route in the generated Alertmanager configuration.

ocp-alertmanagerconfig-secrets-same-namespace [IN] OBSERVATION

Secrets referenced by AlertmanagerConfig must be in the same namespace as the AlertmanagerConfig object.

ocp-alertrelabelconfig-actions [IN] OBSERVATION

AlertRelabelConfig supports actions: Replace (default), Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep.

ocp-alertrelabelconfig-before-alertmanager [IN] OBSERVATION

AlertRelabelConfig relabeling is applied after alerting rules fire but before alerts reach Alertmanager.

ocp-alertrelabelconfig-openshift-specific [IN] OBSERVATION

AlertRelabelConfig is an OpenShift-specific CRD (monitoring.openshift.io/v1), not an upstream Prometheus/Kubernetes resource.

ocp-alertrelabelconfig-sequential-evaluation [IN] OBSERVATION

AlertRelabelConfig spec.configs array is evaluated sequentially — order matters.

ocp-api-driven-all-ops-via-api [IN] OBSERVATION

OpenShift Container Platform is API-driven — all cluster operations can be performed via the REST API, and every oc command corresponds to an underlying API call.

ocp-api-groups-examples [IN] OBSERVATION

OpenShift-specific API resources live in their own API groups, e.g. apps.openshift.io/v1 and route.openshift.io/v1.

ocp-api-lb-ports [IN] OBSERVATION

The API load balancer requires TCP 6443 (Kubernetes API) and TCP 22623 (Machine Config Server, bootstrap only); the Ingress load balancer requires TCP 443 (HTTPS) and TCP 80 (HTTP)

ocp-apiserver-cr-name-cluster [IN] OBSERVATION

The APIServer custom resource is named cluster and is edited with oc edit APIServer cluster.

ocp-apiserver-tls-propagation [IN] OBSERVATION

The APIServer CR propagates TLS settings to: Kubernetes API server, controller manager, scheduler, OpenShift API server, OAuth API server, OAuth server, etcd, MCO, and Machine Config Server.

ocp-arbitrary-uid-security [IN] OBSERVATION

OpenShift runs containers with arbitrarily assigned UIDs; writable directories must be owned by root group (GID 0) with group-writable permissions (chgrp -R 0 /dir && chmod -R g=u /dir)

ocp-auth-operator-api-group [IN] OBSERVATION

The Authentication operator resource is at API group operator.openshift.io/v1, distinct from the cluster-level auth config at config.openshift.io/v1.

ocp-auth-operator-manages-oauth-apiserver [IN] OBSERVATION

The Authentication operator manages the OAuth API server and authentication-related components in OpenShift.

ocp-authorization-api-governs-rbac [IN] OBSERVATION

The OpenShift Authorization API is a key API group that governs RBAC and access control, using common shared object structures across API groups.

ocp-authorization-api-objects [IN] OBSERVATION

OpenShift Authorization API objects include Role, ClusterRole, RoleBinding, ClusterRoleBinding, SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview, and SelfSubjectRulesReview.

ocp-authz-compat-level-1 [IN] OBSERVATION

All OpenShift authorization API resources (authorization.openshift.io) are Compatibility level 1 — stable within a major release for at least 12 months or 3 minor releases.

ocp-auto-image-pruner-daily-midnight-cronjob [IN] OBSERVATION

Automatic image pruning is managed by the imagepruners.imageregistry.operator.openshift.io/cluster CR, running as a CronJob with default schedule 0 0 * * * (daily at midnight).

ocp-automatic-vs-manual-machine-management [IN] OBSERVATION

OCP distinguishes between automatic (Machine API-driven) and manual machine management approaches

ocp-autoscaling-two-levels [IN] OBSERVATION

OpenShift autoscaling operates at two levels: pod-level (HPA/VPA) and cluster/node-level (ClusterAutoscaler + MachineAutoscaler).

ocp-aws-first-class-install-target [IN] OBSERVATION

OpenShift Container Platform supports AWS as a first-class installation target with dedicated documentation.

ocp-aws-ipi-nodes-private-subnets [IN] OBSERVATION

On AWS IPI installations, OpenShift cluster nodes are placed on private subnets without public IP addresses; a bastion host on a public subnet is needed for SSH access

ocp-azure-arm-templates-for-upi [IN] OBSERVATION

Azure Resource Manager (ARM) templates are the mechanism provided for UPI installations on Azure.

ocp-azure-default-compute-replicas-3 [IN] OBSERVATION

Default compute (worker) configuration on Azure is 3 replicas with premium_LRS disk type and 128 GB OS disk.

ocp-azure-government-regions-supported [IN] OBSERVATION

Microsoft Azure Government (MAG) regions are explicitly supported for OpenShift installations handling US government workloads.

ocp-azure-ha-requires-3-azs [IN] OBSERVATION

Azure regions need at least 3 Availability Zones for proper HA distribution of the control plane.

ocp-azure-ipi-default-upi-manual [IN] OBSERVATION

IPI (installer-provisioned infrastructure) is the default installation method for Azure; UPI requires the administrator to manage infrastructure manually.

ocp-azure-only-ipv4-supported [IN] OBSERVATION

Only IPv4 is supported for OpenShift installations on Azure.

ocp-azure-resource-group-must-be-empty [IN] OBSERVATION

When using an existing Azure resource group (platform.azure.resourceGroupName), the group must be empty and used exclusively for the cluster.

ocp-azure-stack-hub-supported [IN] OBSERVATION

OpenShift Container Platform supports Azure Stack Hub (on-premises Azure) as a separate installation platform from public Azure.

ocp-azure-supported-install-target [IN] OBSERVATION

Microsoft Azure is a supported installation target for OpenShift Container Platform, with both IPI and UPI installation methods available

ocp-azure-upi-network-topology [IN] OBSERVATION

Each Azure UPI cluster requires 1 VNet with 2 subnets, 2 network security groups (controlplane on port 6443, node on ports 80/443), 3 load balancers, and 3 public IP addresses.

ocp-azure-upi-requires-44-vcpus [IN] OBSERVATION

Default Azure UPI cluster requires 44 vCPUs total: 3 control plane nodes at StandardD8sv3 (8 vCPUs each), 3 workers at StandardD4sv3 (4 vCPUs each), and 1 bootstrap at StandardD8sv3 (8 vCPUs). Default Azure limit is only 20 per region.

ocp-backup-centers-on-etcd-snapshots [IN] OBSERVATION

OpenShift cluster backup strategy centers on etcd snapshots for preserving cluster state.

ocp-bare-metal-install-supported [IN] OBSERVATION

OpenShift Container Platform supports bare metal (direct physical server) installation as a first-class target.

ocp-bootstrap-process-temporary [IN] OBSERVATION

The OCP bootstrap process uses a temporary bootstrap machine to create the control plane, which then creates compute nodes; the bootstrap machine is destroyed after initialization

ocp-build-types-s2i-docker-custom [IN] OBSERVATION

OpenShift's built-in build system supports Source-to-Image (S2I), Docker, and Custom build strategies.

ocp-buildconfigs-not-in-upstream-k8s [IN] OBSERVATION

Builds and BuildConfigs are OpenShift-native resources not present in upstream Kubernetes.

ocp-built-on-kubernetes [IN] OBSERVATION

OpenShift Container Platform is built on Kubernetes and its API is 100% Kubernetes-compatible — applications run identically on both with no changes required.

ocp-builtin-oauth-server [IN] OBSERVATION

OpenShift includes a built-in OAuth server, which is a key differentiator from vanilla Kubernetes.

ocp-canary-updates-custom-machineconfigpools [IN] OBSERVATION

Canary rollout updates use custom MachineConfigPools with a pause/unpause workflow to update worker nodes in stages

ocp-capabilities-cannot-be-disabled-once-enabled [IN] OBSERVATION

Once a cluster capability is enabled in OpenShift Container Platform, it cannot be disabled — enabling is a one-way operation.

ocp-capability-dependency-baremetal-requires-machineapi [IN] OBSERVATION

The baremetal capability depends on MachineAPI; it cannot be enabled without MachineAPI also being enabled.

ocp-capability-dependency-marketplace-requires-olm [IN] OBSERVATION

The marketplace capability depends on OperatorLifecycleManager; it cannot be enabled without OLM also being enabled.

ocp-cco-credential-modes [IN] OBSERVATION

The Cloud Credential Operator supports Mint, Passthrough, Manual, or empty string credential modes (not all modes supported on all providers).

ocp-ccoctl-azure-delete-oidc-cleanup [IN] OBSERVATION

When short-term credentials (Azure AD Workload Identity) are used, ccoctl azure delete must be run after standard uninstall to clean up OIDC resources not removed by the installer.

ocp-cicd-multiple-solutions [IN] OBSERVATION

OpenShift Container Platform provides multiple CI/CD solutions: OpenShift Pipelines (Tekton), OpenShift GitOps (Argo CD), Builds/BuildConfigs, and Jenkins (legacy).

ocp-cluster-dns-format [IN] OBSERVATION

OpenShift cluster FQDN follows the format <metadata.name>.<baseDomain>.

ocp-cluster-monitoring-default-user-workload-explicit [IN] OBSERVATION

Cluster monitoring is enabled by default in OpenShift, while user workload monitoring must be explicitly enabled.

ocp-cluster-monitoring-operator-manages-stack [IN] OBSERVATION

The Cluster Monitoring Operator (CMO) deploys and manages the monitoring stack, which includes Prometheus, Alertmanager, Thanos Querier, and Telemeter Client.

ocp-cluster-observability-operator-separate [IN] OBSERVATION

The Cluster Observability Operator (COO) is a separate operator from the default built-in cluster monitoring stack (Prometheus, Alertmanager, Grafana) and is used to deploy and configure observability components.

ocp-cluster-resource-quota-no-even-distribution [IN] OBSERVATION

ClusterResourceQuota does not guarantee even distribution across projects — one project could consume the entire cluster quota budget.

ocp-cluster-resource-quota-selector-types [IN] OBSERVATION

ClusterResourceQuota can select projects by annotation (openshift.io/requester) or by label, but cannot use both simultaneously.

ocp-cluster-update-methods [IN] OBSERVATION

OpenShift cluster updates can be performed via the web console, CLI, or OpenShift Update Service (for disconnected environments).

ocp-cluster-updates-non-disruptive [IN] OBSERVATION

OCP cluster updates are non-disruptive — the cluster remains online during the update process (in-place, zero-downtime upgrade model)

ocp-cluster-wide-proxy-affects-all-components [IN] OBSERVATION

Cluster-wide proxy settings in OpenShift affect how all cluster components reach external resources

ocp-cno-deploys-cni-plugin [IN] OBSERVATION

The Cluster Network Operator (CNO) is responsible for deploying and managing the CNI plugin selected at install time.

ocp-compatibility-level-1-stability [IN] OBSERVATION

OpenShift Compatibility level 1 means the API is stable within a major release for a minimum of 12 months or 3 minor releases, whichever is longer

ocp-config-apis-cluster-scoped [IN] OBSERVATION

Config API objects in OpenShift are cluster-scoped resources that define platform-wide behavior (networking, authentication, scheduling, etc.)

ocp-console-branding-resource [IN] OBSERVATION

The resource to edit for console branding (logo, product name) is consoles.operator.openshift.io cluster.

ocp-console-cli-api-clients [IN] OBSERVATION

Both the OpenShift web console and the oc CLI are clients of the API; the API is the authoritative interface.

ocp-console-config-resource-edit-command [IN] OBSERVATION

The web console is configured by editing the cluster-scoped resource with oc edit console.config.openshift.io cluster.

ocp-console-crds-list [IN] OBSERVATION

Console customization CRDs include: ConsoleLink, ConsoleNotification, ConsoleExternalLogLink, ConsoleCLIDownload, ConsoleYAMLSample, and ConsoleQuickStart.

ocp-console-logout-redirect-enables-slo [IN] OBSERVATION

Setting spec.authentication.logoutRedirect on console.config.openshift.io controls the post-logout URL and enables single logout (SLO) through the identity provider.

ocp-consolelink-location-values [IN] OBSERVATION

ConsoleLink CRD location valid values are: HelpMenu, UserMenu, ApplicationMenu, NamespaceDashboard.

ocp-consolenotification-location-values [IN] OBSERVATION

ConsoleNotification CRD location valid values are: BannerTop, BannerBottom, BannerTopBottom.

ocp-container-engine-crio [IN] OBSERVATION

CRI-O is the container engine in OpenShift Container Platform (not Docker); it runs as a systemd service on each node.

ocp-container-runtime-crio [IN] OBSERVATION

OCP uses CRI-O as the container runtime, not Docker

ocp-control-plane-minimum-resources [IN] OBSERVATION

Control plane and bootstrap machines require minimum 4 vCPU, 16 GB RAM, 100 GB storage, 300 IOPS; compute machines require minimum 2 vCPU, 8 GB RAM, 100 GB storage, 300 IOPS

ocp-control-plane-must-run-rhcos [IN] OBSERVATION

Control plane nodes must run RHCOS; compute nodes can run RHCOS or RHEL 8.6+

ocp-control-plane-no-tls13 [IN] OBSERVATION

The OpenShift control plane does not support TLS 1.3 or the Modern TLS security profile.

ocp-control-plane-only-update-even-minor-versions [IN] OBSERVATION

Control Plane Only updates (formerly "EUS-to-EUS") in OpenShift are only viable between even-numbered minor versions (e.g., 4.14 → 4.16).

ocp-control-plane-pool-name-master [IN] OBSERVATION

The control plane machine pool name must be "master" and the compute pool name must be "worker" in install-config.yaml.

ocp-control-plane-requires-rhcos [IN] OBSERVATION

All control plane nodes must run RHCOS; compute nodes can optionally run RHEL but only with UPI installations

ocp-credentialsrequest-default-token-path [IN] OBSERVATION

The default cloudTokenPath for CredentialsRequest is /var/run/secrets/openshift/serviceaccount/token.

ocp-credentialsrequest-namespaced [IN] OBSERVATION

CredentialsRequest (cloudcredential.openshift.io/v1) is a namespaced resource managed by the Cloud Credential Operator.

ocp-credentialsrequest-secretref-required [IN] OBSERVATION

Every CredentialsRequest must specify spec.secretRef to define where generated cloud credentials will be stored as a Secret.

ocp-crio-provides-fips-awareness [IN] OBSERVATION

CRI-O is the container runtime that ensures containers are aware they run on a FIPS-enabled host.

ocp-crio-runtime-rhcos-containerd-windows [IN] OBSERVATION

OpenShift uses CRI-O as the container runtime on RHCOS nodes and containerd on Windows nodes (via WMCO).

ocp-current-version-421 [IN] OBSERVATION

OpenShift Container Platform documentation covers version 4.21, with versions ranging from 3.0 through 4.21.

ocp-custom-console-route-via-ingress-config [IN] OBSERVATION

Custom console routes are configured via ingress.config.openshift.io cluster using spec.componentRoutes, not via the console operator (deprecated method).

ocp-custom-error-template-redirect-idps-only [IN] OBSERVATION

Custom login error templates only work with redirect-based identity providers (request header, OIDC), not direct auth providers (LDAP, htpasswd).

ocp-custom-logo-configmap-openshift-config [IN] OBSERVATION

Custom console logos are stored in a ConfigMap in the openshift-config namespace, with max-height 60px and max size 1 MB.

ocp-custom-metrics-autoscaler-based-on-keda [IN] OBSERVATION

The Custom Metrics Autoscaler Operator in OCP is based on KEDA.

ocp-custom-project-template-in-openshift-config [IN] OBSERVATION

Custom project templates must be created in the openshift-config namespace and referenced via project.config.openshift.io/cluster.

ocp-cvo-checks-osus-for-updates [IN] OBSERVATION

The Cluster Version Operator (CVO) checks the OpenShift Update Service (OSUS) for valid updates and uses release images to perform upgrades

ocp-cvo-overrides-block-upgrades [IN] OBSERVATION

CVO spec.overrides with unmanaged: true blocks cluster upgrades and renders the cluster unsupported

ocp-day2-ops-postinstall-config [IN] OBSERVATION

Day 2 operations in OpenShift correspond to postinstallation configuration

ocp-day2-postinstallation-operations [IN] OBSERVATION

Postinstallation configuration in OpenShift is referred to as "Day 2 operations," distinct from Day 0 (planning) and Day 1 (installation) activities.

ocp-day2-tasks-include-idp-storage-networking-scaling [IN] OBSERVATION

Key Day 2 postinstallation tasks include configuring identity providers (OAuth), persistent storage, networking policies, node scaling, monitoring, logging, image registry storage, and cluster-wide proxy/certificate settings.

ocp-default-baseline-capability-set-vcurrent [IN] OBSERVATION

The default baselineCapabilitySet value is vCurrent, which enables all optional capabilities including any new ones added in future releases.

ocp-default-cluster-network-cidr [IN] OBSERVATION

Default OpenShift cluster network CIDR is 10.128.0.0/14 with /23 host prefix, providing 510 pod IPs per node.

ocp-default-cluster-roles [IN] OBSERVATION

Key default cluster roles in OpenShift are: cluster-admin, admin, edit, view, and self-provisioner.

ocp-default-cni-shifted-to-ovn-kubernetes [IN] OBSERVATION

OpenShift 4.x default CNI plugin shifted from OpenShift SDN to OVN-Kubernetes in later 4.x releases.

ocp-default-compute-replicas-3 [IN] OBSERVATION

Default compute (worker) replicas in OpenShift is 3; control plane replicas must be 3 (or 1 for single-node OpenShift).

ocp-default-host-prefix-23 [IN] OBSERVATION

The default host prefix is /23, giving 510 usable pod IPs per node

ocp-default-ingress-controller-haproxy [IN] OBSERVATION

The default Ingress Controller in OpenShift Container Platform uses HAProxy.

ocp-default-machine-cidr [IN] OBSERVATION

The default Machine CIDR in OpenShift is 10.0.0.0/16 and cannot be changed after cluster installation

ocp-default-network-cidrs [IN] OBSERVATION

Default OCP network CIDRs: cluster network 10.128.0.0/14 with /23 host prefix (510 pod IPs per node), service network 172.30.0.0/16, machine network 10.0.0.0/16.

ocp-default-network-plugin-ovnkubernetes [IN] OBSERVATION

OVNKubernetes is the default (and only listed) CNI network plugin for OpenShift 4.17, supporting Linux and hybrid Linux/Windows nodes.

ocp-default-pod-cidr [IN] OBSERVATION

The default Pod CIDR (clusterNetwork CIDR) in OpenShift is 10.128.0.0/14 and can be expanded post-installation

ocp-default-replica-counts [IN] OBSERVATION

Default compute node replicas: 3 (minimum 2); control plane replicas: 3 (or 1 for single-node OpenShift).

ocp-default-runtime-runc [IN] OBSERVATION

The default container runtime in OCP 4.17 is runC; crun is the alternative (C-based, by Red Hat).

ocp-default-service-cidr [IN] OBSERVATION

The default Service CIDR in OpenShift is 172.30.0.0/16

ocp-default-service-network-cidr [IN] OBSERVATION

Default OpenShift service network CIDR is 172.30.0.0/16.

ocp-delete-app-removes-all-components [IN] OBSERVATION

Deleting an application in OpenShift's Developer perspective Topology view removes the application and all associated components.

ocp-delete-app-requires-name-confirmation [IN] OBSERVATION

Deleting an application in the OpenShift web console requires typing the application name to confirm deletion.

ocp-delete-imagestreamtag-removes-spec-and-status [IN] OBSERVATION

Deleting an ImageStreamTag removes both the spec and status entries for that tag.

ocp-deployment-and-deploymentconfig-types [IN] OBSERVATION

Deployment and DeploymentConfig are the two object types for deploying applications in OpenShift.

ocp-destroy-cluster-command [IN] OBSERVATION

The primary command for removing an IPI cluster from AWS is openshift-install destroy cluster --dir <installation_directory> --log-level info

ocp-destroy-cluster-requires-metadata-json [IN] OBSERVATION

The openshift-install destroy cluster command requires the original installation directory containing metadata.json — without it, the cluster cannot be programmatically removed.

ocp-destroy-requires-metadata-json [IN] OBSERVATION

The openshift-install destroy cluster command requires the metadata.json file in the installation directory to identify and delete cluster resources

ocp-disable-console-management-state-removed [IN] OBSERVATION

To disable the web console, set spec.managementState: Removed on consoles.operator.openshift.io cluster.

ocp-disable-self-provisioning-two-steps [IN] OBSERVATION

To disable self-provisioning: remove subjects from the self-provisioners binding AND set annotation rbac.authorization.kubernetes.io/autoupdate: "false" to prevent automatic reset.

ocp-disabling-nodetuning-limits-scalability [IN] OBSERVATION

Disabling the NodeTuning capability can limit cluster scalability beyond 900 nodes or 900 routes.

ocp-disconnected-install-requires-image-mirroring [IN] OBSERVATION

Disconnected/restricted network OpenShift installations require mirroring installation images.

ocp-distributed-tracing-store-analyze-visualize [IN] OBSERVATION

Distributed tracing in OpenShift Container Platform is used to store, analyze, and visualize microservices transactions in distributed systems.

ocp-distributed-tracing-uses-tempo [IN] OBSERVATION

OpenShift distributed tracing uses the Tempo architecture as the backend for storing and visualizing requests across microservices.

ocp-dns-naming-convention [IN] OBSERVATION

The cluster's full DNS name follows the pattern <metadata.name>.<baseDomain>.

ocp-dns-operator-deploys-coredns [IN] OBSERVATION

The DNS Operator deploys and manages CoreDNS for pod name resolution in OpenShift (not kube-dns).

ocp-dns-preferred-over-env-vars [IN] OBSERVATION

DNS-based service discovery is preferred over environment variables because environment variables break when services are recreated with new IPs; backend services must exist before frontend pods if using env-var discovery.

ocp-dual-stack-same-nic-consistent-order [IN] OBSERVATION

For dual-stack networking, IPv4 and IPv6 must use the same NIC for the default gateway and addresses must be listed in consistent order across all config parameters.

ocp-enable-capability-post-install-patch [IN] OBSERVATION

Capabilities can be enabled post-install using oc patch clusterversion/version --type merge -p '{"spec":{"capabilities":{"additionalEnabledCapabilities":["<capability>"]}}}'.

ocp-etcd-fsync-requirement [IN] OBSERVATION

etcd requires 10 ms p99 fsync duration; faster storage is strongly recommended for control plane nodes

ocp-etcd-network-encryption-options [IN] OBSERVATION

OCP supports etcd encryption for data at rest and network encryption via IPsec or WireGuard with OVN-Kubernetes.

ocp-etcd-standalone-config-topic [IN] OBSERVATION

etcd is broken out as its own configuration topic in OpenShift, reflecting its criticality to cluster state (backup, restore, encryption)

ocp-eus-available-even-numbered-minor-releases [IN] OBSERVATION

Extended Update Support (EUS) is available on all even-numbered minor OpenShift releases (e.g., 4.14, 4.16).

ocp-eus-stable-channel-45-90-days-after-ga [IN] OBSERVATION

New EUS/stable channel update paths are not available until 45-90 days after initial GA of an OpenShift minor release; use fast channel for early testing.

ocp-every-pod-gets-unique-ip-no-nat [IN] OBSERVATION

Every pod in OpenShift receives a unique IP address from the cluster network CIDR with no NAT between pods

ocp-extended-resources-no-overcommit [IN] OBSERVATION

Extended resources (e.g., GPUs) only support the requests. prefix in quotas — overcommitment is not allowed.

ocp-extends-k8s-api-with-crds [IN] OBSERVATION

OpenShift extends the Kubernetes API with custom resource definitions (CRDs) for platform-specific functionality.

ocp-extends-kubernetes-api [IN] OBSERVATION

OpenShift Container Platform extends the upstream Kubernetes API with additional resource types including Routes, BuildConfigs, DeploymentConfigs, and ImageStreams.

ocp-extends-kubernetes-api-with-crds [IN] OBSERVATION

OpenShift-specific APIs (e.g., Route, BuildConfig, DeploymentConfig, ClusterVersion, MachineSet) are implemented as Custom Resource Definitions (CRDs) on top of Kubernetes.

ocp-fips-azure-file-incompatible [IN] OBSERVATION

Azure File storage is incompatible with OpenShift FIPS mode.

ocp-fips-etcd-encryption-aes-cbc [IN] OBSERVATION

In FIPS mode, etcd data-at-rest encryption uses the AES CBC algorithm and is applied after cluster installation.

ocp-fips-incompatible-azure-file-storage [IN] OBSERVATION

FIPS mode and Azure File storage are incompatible — Azure File storage cannot be used when FIPS is enabled.

ocp-fips-install-config-setting [IN] OBSERVATION

FIPS mode is enabled by setting fips: true in install-config.yaml.

ocp-fips-installer-binary-name [IN] OBSERVATION

The FIPS-capable OpenShift installer binary is named openshift-install-fips, distinct from the standard openshift-install.

ocp-fips-mode-install-time-only [IN] OBSERVATION

FIPS mode must be enabled at install time from a FIPS-configured RHEL host and cannot be enabled post-install; supported on x86_64, ppc64le, and s390x only.

ocp-fips-mode-install-time-option [IN] OBSERVATION

FIPS mode in OpenShift is an installation-time option (cannot be enabled post-install).

ocp-fips-must-be-enabled-at-install-time [IN] OBSERVATION

FIPS mode must be enabled at OpenShift cluster install time — it cannot be enabled after deployment.

ocp-fips-not-supported-aarch64 [IN] OBSERVATION

OpenShift Container Platform FIPS support is available on x86_64, ppc64le, and s390x architectures only — aarch64 is NOT supported for FIPS.

ocp-fips-requires-fips-enabled-rhel [IN] OBSERVATION

FIPS mode requires running the OpenShift installer from a FIPS-enabled RHEL machine.

ocp-fips-requires-rhel9-host-in-fips-mode [IN] OBSERVATION

The FIPS-capable OpenShift installer must be run from a RHEL 9 machine that is already running in FIPS mode.

ocp-fips-requires-rsa-or-ecdsa-not-ed25519 [IN] OBSERVATION

For FIPS mode, SSH keys must use RSA or ECDSA algorithms — ed25519 is not supported.

ocp-fips-ssh-key-types [IN] OBSERVATION

When FIPS mode is enabled, SSH keys must use RSA or ECDSA (ed25519 is not allowed)

ocp-fips-supported-architectures [IN] OBSERVATION

FIPS mode in OpenShift is supported only on x86_64, ppc64le, and s390x architectures (not aarch64).

ocp-firmware-updates-not-part-of-ocp-updates [IN] OBSERVATION

Firmware updates are NOT part of the OpenShift Container Platform update process — they are the customer's responsibility.

ocp-five-primary-cli-tools [IN] OBSERVATION

OCP provides five primary CLI tools: oc (OpenShift CLI), kn (Knative CLI), tkn (Pipelines CLI), opm (Operator catalog CLI), and Operator SDK (operator-sdk).

ocp-four-accelerator-types [IN] OBSERVATION

OpenShift Container Platform supports four types of hardware accelerators: GPUs, NPUs (Neural Processing Units), ASICs (Application-Specific Integrated Circuits), and DPUs (Data Processing Units).

ocp-four-cicd-solutions [IN] OBSERVATION

OpenShift Container Platform provides four CI/CD solutions: OpenShift Builds, OpenShift Pipelines, OpenShift GitOps, and Jenkins.

ocp-four-installation-methods [IN] OBSERVATION

OpenShift Container Platform 4.17 provides four installation methods: Assisted Installer, Agent-based Installer, installer-provisioned infrastructure (IPI), and user-provisioned infrastructure (UPI)

ocp-gcp-supported-install-target [IN] OBSERVATION

OpenShift Container Platform supports installation on Google Cloud Platform (GCP) as a first-class cloud provider.

ocp-gitops-based-on-argocd [IN] OBSERVATION

OpenShift GitOps is based on Argo CD and provides declarative CD for managing cluster and application state via Git.

ocp-groups-cluster-scoped [IN] OBSERVATION

Groups in OpenShift are cluster-scoped and can be referenced in both ClusterRoleBindings and namespace-scoped RoleBindings.

ocp-highly-privileged-projects-list [IN] OBSERVATION

Highly privileged projects are: default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label set to 0 or 1.

ocp-host-network-spec [IN] OBSERVATION

Pods requiring access to the host network (e.g., cloud metadata at 169.254.169.254) must set spec.hostNetwork: true in their pod spec.

ocp-hosted-control-planes-different-cidrs [IN] OBSERVATION

Hosted control planes use different default CIDRs than standard clusters: pod 10.132.0.0/14, service 172.31.0.0/16

ocp-hosted-control-planes-platforms [IN] OBSERVATION

Hosted control planes (HCP) can be deployed on OpenShift Virtualization, AWS, bare metal, IBM Z, and IBM Power, including in disconnected environments.

ocp-hosted-control-planes-supported [IN] OBSERVATION

Hosted control planes (HyperShift) is a supported cluster management model where control planes run as pods on a management cluster

ocp-identity-provider-types [IN] OBSERVATION

OpenShift supports these identity providers: HTPasswd, LDAP, GitHub, GitLab, Google, OpenID Connect, Keystone, Basic Authentication, and Request Header.

ocp-image-apis-group-v1 [IN] OBSERVATION

All OpenShift Image APIs are in the image.openshift.io/v1 API group.

ocp-image-namespace-flag-only-imagestreams [IN] OBSERVATION

The --namespace flag on oc adm prune images only removes image streams, not images, because images are cluster-scoped resources.

ocp-image-pruning-requires-image-pruner-role [IN] OBSERVATION

Image pruning requires the system:image-pruner cluster role or cluster-admin privileges.

ocp-image-pruning-requires-registry-restart [IN] OBSERVATION

After manual image pruning, the registry must be redeployed to clear the blob metadata cache: oc rollout restart deployment/image-registry -n openshift-image-registry.

ocp-image-registry-cannot-be-mirror-target [IN] OBSERVATION

The OpenShift image registry cannot be used as a mirror target because it does not support pushing without a tag.

ocp-imagestreamimage-name-format [IN] OBSERVATION

ImageStreamImage resources are accessed using the name format <STREAM>@<DIGEST>.

ocp-imagestreamimport-preview-before-tagging [IN] OBSERVATION

ImageStreamImport allows users to find, preview metadata, and import images from external registries before actually tagging them in an ImageStream.

ocp-imagestreammapping-privileged-only [IN] OBSERVATION

ImageStreamMapping is for privileged integrators only; creating a mapping exposes the image to anyone who can view the stream.

ocp-includes-builtin-container-registry [IN] OBSERVATION

OpenShift Container Platform includes a built-in private container registry installed with the cluster.

ocp-ingress-capability-must-be-enabled [IN] OBSERVATION

The Ingress capability must always be enabled — OpenShift cluster installation fails without it.

ocp-ingress-controller-runs-as-pod [IN] OBSERVATION

The Ingress Controller runs as a scalable pod inside the cluster, not as a separate infrastructure component.

ocp-ingress-controller-uses-haproxy [IN] OBSERVATION

OpenShift uses HAProxy as the underlying technology for Ingress Controllers.

ocp-ingress-converts-tls10-to-tls11 [IN] OBSERVATION

The Ingress Controller converts TLS 1.0 to TLS 1.1 when using Old or Custom TLS profiles.

ocp-ingress-inherits-apiserver-tls [IN] OBSERVATION

The Ingress Controller's TLS profile defaults to the API server's TLS profile setting if not explicitly configured.

ocp-ingress-metrics-top10-filters [IN] OBSERVATION

Ingress dashboard metrics can be filtered by Top 10 Per Route, Top 10 Per Namespace, and Top 10 Per Shard.

ocp-ingress-operator-namespace [IN] OBSERVATION

The Ingress Controller is managed in the openshift-ingress-operator namespace.

ocp-ingress-translates-to-routes [IN] OBSERVATION

Kubernetes Ingress resources are automatically translated into Route objects by OpenShift.

ocp-inhibit-rules-source-target-matching [IN] OBSERVATION

Alertmanager inhibit rules use sourceMatch and targetMatch with an equal labels list — when source alerts fire, target alerts with the same equal label values are suppressed.

ocp-install-config-declarative [IN] OBSERVATION

OCP installation configuration is declarative, defined in install-config.yaml before the installer runs.

ocp-install-config-immutable-after-install [IN] OBSERVATION

The install-config.yaml parameters are immutable after OpenShift cluster installation — networking, capabilities, FIPS, and workload partitioning cannot be changed post-install.

ocp-install-docs-organized-per-platform [IN] OBSERVATION

OpenShift Container Platform installation documentation is organized per-platform, with each supported platform (AWS, Azure, GCP, bare metal, vSphere, etc.) having its own dedicated installation path.

ocp-install-existing-vpc-vnet-supported [IN] OBSERVATION

OpenShift supports installation into existing VPC (AWS, GCP) or existing VNet (Azure).

ocp-install-methods-ipi-and-upi [IN] OBSERVATION

OpenShift Container Platform offers two primary installation approaches: Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI).

ocp-install-time-vs-day2-config [IN] OBSERVATION

Some OCP install-time configuration choices are immutable or hard to change after installation, distinct from day-2 configuration that can be modified on a running cluster.

ocp-installation-12-stages [IN] OBSERVATION

OCP installation proceeds through 12 stages: Ignition creation → bootstrap boot → control plane fetch → etcd cluster formation → temporary control plane → production control plane handoff → bootstrap shutdown → worker setup → Operator installation → day-2 configuration.

ocp-installation-validation-troubleshooting-phase [IN] OBSERVATION

OCP has a dedicated validation and troubleshooting workflow as a post-installation phase in the cluster lifecycle

ocp-integrated-registry-managed-by-operator [IN] OBSERVATION

OpenShift Container Platform ships with an integrated container image registry managed by the Image Registry Operator.

ocp-integrated-registry-pull-requires-layers-permission [IN] OBSERVATION

Pulling from the integrated container registry requires get imagestreams/layers permission on the image stream.

ocp-internal-oauth-server [IN] OBSERVATION

OpenShift runs an internal OAuth server for authentication; identity providers are configured on this OAuth server.

ocp-ip-failover-uses-vrrp [IN] OBSERVATION

OpenShift IP failover provides high availability for external-facing IP addresses using VRRP (Virtual Router Redundancy Protocol)

ocp-ipi-default-installation-method [IN] OBSERVATION

Installer-provisioned infrastructure (IPI) is the default installation method for OpenShift; UPI requires manual creation of infrastructure resources.

ocp-jenkins-legacy-cicd [IN] OBSERVATION

Jenkins is the legacy CI/CD option in OpenShift, being de-emphasized in favor of Tekton-based Pipelines.

ocp-jenkins-legacy-deprecated [IN] OBSERVATION

Jenkins on OpenShift is a legacy approach; the platform has shifted toward Pipelines (Tekton) and GitOps (Argo CD).

ocp-key-cluster-scoped-resources [IN] OBSERVATION

Key cluster-level API resources in OpenShift include: ClusterVersion, Infrastructure, OAuth, DNS, Network, Ingress, Proxy, Scheduler, FeatureGate, Image, Build, and Project.

ocp-kubeadmin-default-account [IN] OBSERVATION

After installation, OpenShift uses a temporary kubeadmin admin account; a real identity provider must be configured for production and kubeadmin should then be removed.

ocp-kubelet-tls-change-triggers-reboot [IN] OBSERVATION

Changing kubelet TLS settings via KubeletConfig triggers node reboots, applied by the Machine Config Operator.

ocp-kubelet-tls-verify-path [IN] OBSERVATION

Kubelet TLS settings can be verified by checking /etc/kubernetes/kubelet.conf on the node.

ocp-kuryr-deprecated-414-removed-416 [IN] OBSERVATION

Kuryr network plugin was deprecated as of OCP 4.14 and removed in OCP 4.16.

ocp-latest-tag-no-auto-update [IN] OBSERVATION

The OpenShift latest tracking tag does not automatically update to the newest version — it must be manually updated, unlike Docker's latest behavior.

ocp-ldap-group-sync [IN] OBSERVATION

Groups can be synced from external LDAP directories using oc adm groups sync.

ocp-link-local-not-reachable-from-pod-network [IN] OBSERVATION

The link-local CIDR 169.254.0.0/16 is not reachable from the pod network; pods must use hostNetwork to access it.

ocp-logging-cluster-admin-responsibility [IN] OBSERVATION

Deploying and managing the OpenShift logging stack is a cluster administrator responsibility.

ocp-logging-distinct-from-monitoring [IN] OBSERVATION

OpenShift Logging is a distinct subsystem from OpenShift monitoring (Prometheus/Alertmanager) — they serve different observability purposes.

ocp-logging-four-functions [IN] OBSERVATION

OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.

ocp-logging-not-installed-by-default [IN] OBSERVATION

OpenShift Logging is not installed by default — it requires installing the Cluster Logging Operator (and typically a log store operator like Loki Operator).

ocp-logging-separate-documentation [IN] OBSERVATION

Logging 6 documentation is maintained as a separate documentation set at docs.redhat.com/en/documentation/redhatopenshift_logging/, not in the main OCP docs.

ocp-logging-separate-release-cadence [IN] OBSERVATION

OpenShift Logging releases on a separate cadence from OpenShift Container Platform itself and is versioned independently.

ocp-logging-three-log-types [IN] OBSERVATION

OpenShift Logging collects three distinct log types: node system audit logs, application container logs, and infrastructure logs.

ocp-login-templates-stored-in-secrets [IN] OBSERVATION

Custom login page templates (login, provider selection, error) are stored in Secrets in the openshift-config namespace, not ConfigMaps.

ocp-lokistack-alerts-require-logging-5-7 [IN] OBSERVATION

LokiStack-based customized alerts and recorded metrics require Logging version 5.7 or later.

ocp-machine-sets-compute-and-control-plane [IN] OBSERVATION

Machine sets are used to manage both compute and control plane machines in OpenShift.

ocp-machineapi-only-disableable-with-upi [IN] OBSERVATION

The MachineAPI capability can only be disabled when using user-provisioned infrastructure (UPI).

ocp-managed-image-annotation-required [IN] OBSERVATION

An image must have the openshift.io/image.managed annotation to be eligible for pruning by the image pruner.

ocp-management-state-unmanaged-stops-reconciliation [IN] OBSERVATION

Setting an operator's managementState to Unmanaged stops the operator from reconciling its managed component.

ocp-management-state-values-managed-unmanaged-removed [IN] OBSERVATION

The managementState field on OpenShift operator resources accepts three values: Managed (default, operator reconciles), Unmanaged (running but not reconciled), and Removed (disabled entirely). This pattern is common across many OpenShift operators.

ocp-mco-maxunavailable-default-1 [IN] OBSERVATION

The Machine Config Operator (MCO) maxUnavailable defaults to 1 during cluster updates, controlling how many nodes are cordoned simultaneously

ocp-mcp-groups-8-10-nodes-staged-rollout [IN] OBSERVATION

Worker nodes should be divided into MachineConfigPool groups of approximately 8-10 nodes for staged rolling updates in telco CNF environments.

ocp-mcp-pausing-controls-worker-reboot [IN] OBSERVATION

MachineConfigPool pausing (spec.paused: true/false) is the mechanism to control when worker nodes reboot during OpenShift updates.

ocp-metadata-name-max-14-chars [IN] OBSERVATION

The metadata.name field in install-config.yaml must be 14 characters or fewer, using only lowercase letters, hyphens, and periods.

ocp-metallb-loadbalancer-bare-metal [IN] OBSERVATION

The MetalLB Operator provides external IP addresses for LoadBalancer-type services on bare metal clusters.

ocp-min-node-topologies [IN] OBSERVATION

OpenShift supports minimum node topologies: SNO (1 node), TNO (2 nodes), and standard HA (3 control plane + workers).

ocp-monitoring-api-objects-include-servicemonitor-prometheusrule [IN] OBSERVATION

OpenShift monitoring API objects include AlertingRule, AlertRelabelConfig, PrometheusRule, ServiceMonitor, and PodMonitor custom resources.

ocp-monitoring-apis-separate-api-group [IN] OBSERVATION

OpenShift Container Platform exposes dedicated Monitoring API objects as Custom Resource Definitions, separate from core Kubernetes APIs and operator APIs.

ocp-monitoring-apis-separate-from-k8s [IN] OBSERVATION

OpenShift Container Platform has dedicated monitoring API objects (PrometheusRule, ServiceMonitor, PodMonitor, AlertmanagerConfig, etc.) beyond what upstream Kubernetes provides

ocp-monitoring-config-via-configmap [IN] OBSERVATION

Monitoring configuration is done via ConfigMap objects in the openshift-monitoring and openshift-user-workload-monitoring namespaces.

ocp-monitoring-deployed-by-default [IN] OBSERVATION

Monitoring is the only observability component deployed by default in every OpenShift Container Platform installation; all other observability components must be installed separately.

ocp-monitoring-stack-based-on-prometheus [IN] OBSERVATION

The OpenShift monitoring stack is based on the Prometheus ecosystem (Prometheus, Alertmanager, Thanos).

ocp-monitoring-stack-builtin [IN] OBSERVATION

The OpenShift Container Platform monitoring stack is built-in and ships pre-configured — it is not an optional add-on.

ocp-monitoring-stack-components [IN] OBSERVATION

The OpenShift monitoring stack is based on Prometheus (metrics collection), Alertmanager (alert routing), and Thanos Querier (federated querying).

ocp-monitoring-stack-enabled-by-default [IN] OBSERVATION

The OpenShift monitoring stack is pre-configured and deployed by default on OpenShift clusters — no installation required.

ocp-monitoring-stack-preinstalled [IN] OBSERVATION

OpenShift Container Platform ships with a preconfigured, preinstalled, and self-updating monitoring stack for core platform components

ocp-monitoring-stack-self-updating [IN] OBSERVATION

The OCP monitoring stack is self-updating as part of the platform — no manual operator installation is needed for platform monitoring

ocp-mtc-migration-tool [IN] OBSERVATION

Migration Toolkit for Containers (MTC) is the tool for migrating workloads between clusters or from v3 to v4

ocp-multus-cni-enables-multiple-network-interfaces [IN] OBSERVATION

The Multus CNI meta-plugin enables attaching multiple network interfaces to pods in OpenShift.

ocp-multus-cni-multiple-interfaces [IN] OBSERVATION

Multus CNI enables multiple network interfaces on pods, connecting to SR-IOV, Macvlan, and other additional network types

ocp-namespace-project-equivalence [IN] OBSERVATION

OpenShift maps Kubernetes Namespaces to Projects — the terms are related but Project adds additional features

ocp-network-apis-managed-by-cno-and-ingress-operator [IN] OBSERVATION

Network APIs are managed by the Cluster Network Operator and the Ingress Operator.

ocp-network-observability-operator-not-default [IN] OBSERVATION

The Network Observability Operator is a separate installation — it is not enabled by default.

ocp-network-observability-stores-in-loki [IN] OBSERVATION

The Network Observability Operator stores flow logs in a Loki instance for querying, with optional Kafka as an intermediate message broker.

ocp-network-observability-uses-ebpf [IN] OBSERVATION

The Network Observability Operator uses eBPF agents on nodes to capture network flow data.

ocp-network-policies-namespace-scoped [IN] OBSERVATION

Network policies in OpenShift are namespace-scoped and use label selectors to define allowed traffic

ocp-networking-dashboards-path [IN] OBSERVATION

OpenShift networking dashboards are accessed via Observe → Dashboards in the web console.

ocp-networking-managed-by-operators [IN] OBSERVATION

OpenShift manages networking components through Operators (e.g., Cluster Network Operator, DNS Operator, Ingress Operator) rather than static configuration.

ocp-networking-multiple-specialized-operators [IN] OBSERVATION

OpenShift Container Platform networking is managed through multiple specialized Operators (Ingress, DNS, CNO, MetalLB, SR-IOV, PTP, NMState), not a single monolithic component.

ocp-networking-operators-cno-default [IN] OBSERVATION

The Cluster Network Operator (CNO) is installed by default in OpenShift and manages the pod network (SDN/OVN-Kubernetes)

ocp-networking-operators-dns-default [IN] OBSERVATION

The DNS Operator is installed by default in OpenShift and runs CoreDNS pods for cluster DNS resolution

ocp-networking-operators-ingress-default [IN] OBSERVATION

The Ingress Operator is installed by default in OpenShift and manages HAProxy-based IngressControllers for route/ingress traffic

ocp-node-apis-distinct-category [IN] OBSERVATION

OpenShift organizes its APIs into distinct categories, with Node APIs being a specific category governing how nodes are defined, configured, and managed.

ocp-nodes-run-rhcos [IN] OBSERVATION

OpenShift Container Platform nodes run Red Hat Enterprise Linux CoreOS (RHCOS).

ocp-nodes-run-rhcos-or-rhel [IN] OBSERVATION

OpenShift Container Platform nodes run as RHCOS (Red Hat Enterprise Linux CoreOS) or RHEL.

ocp-oauth-apiserver-revision-based-deployments [IN] OBSERVATION

The OAuth API server uses revision-based deployments tracked by latestAvailableRevision; new revisions trigger pod redeployments.

ocp-observability-components-separate-release-cycles [IN] OBSERVATION

All observability components except Monitoring follow separate release cycles from core OpenShift Container Platform releases.

ocp-observability-stack-components [IN] OBSERVATION

The OCP observability stack includes Monitoring, Logging, Network Observability, Distributed Tracing, OpenTelemetry, Power Monitoring, and Cluster Observability Operator

ocp-oc-cli-distinct-from-kubectl [IN] OBSERVATION

OpenShift has its own CLI (oc) that is distinct from but compatible with kubectl.

ocp-oc-explain-inspects-api-schemas [IN] OBSERVATION

The oc explain <resource> command is used to inspect API object schemas at runtime, and oc api-resources lists available API resources.

ocp-oc-expose-creates-route [IN] OBSERVATION

oc expose svc/<service-name> is the quickest way to create a non-TLS route from an existing service.

ocp-odd-releases-18-month-support [IN] OBSERVATION

Odd-numbered OpenShift Container Platform releases (e.g., 4.17) receive 18-month support; even-numbered releases are Extended Update Support (EUS).

ocp-olm-v1-current [IN] OBSERVATION

OLM v1 (Operator Lifecycle Manager) is the current extension mechanism in OCP 4.21

ocp-onprem-installers-assisted-and-agent [IN] OBSERVATION

Two on-premise installation methods exist: Assisted Installer and Agent-based Installer

ocp-open-service-broker-api-provisioning [IN] OBSERVATION

OpenShift Container Platform references the Open Service Broker API as a mechanism for provisioning and managing service instances.

ocp-operator-loglevel-values [IN] OBSERVATION

Operator logLevel valid values are Normal (default), Debug, Trace, and TraceAll.

ocp-operators-primary-extension-mechanism [IN] OBSERVATION

Operators are the primary extension mechanism for OCP; most additional components (networking, security, observability, CI/CD, etc.) are delivered as Operators.

ocp-optional-networking-operators-via-operatorhub [IN] OBSERVATION

MetalLB, External DNS, and Ingress Node Firewall operators are optional and installed via OperatorHub

ocp-ovn-kubernetes-default-network-plugin [IN] OBSERVATION

OVN-Kubernetes is the default/primary network plugin for OpenShift Container Platform

ocp-perspective-ids-admin-dev [IN] OBSERVATION

The two default web console perspective IDs are admin and dev, with visibility states Enabled, Disabled, or AccessReview.

ocp-pipelines-based-on-tekton [IN] OBSERVATION

OpenShift Pipelines is based on Tekton, a cloud-native Kubernetes-native CI/CD pipeline framework.

ocp-pipelines-based-on-tekton-kubernetes-resources [IN] OBSERVATION

Red Hat OpenShift Pipelines is a cloud-native CI/CD solution based on Kubernetes resources (Tekton).

ocp-pipelines-gitops-installed-as-operators [IN] OBSERVATION

Both OpenShift Pipelines and OpenShift GitOps are installed as Operators from OperatorHub.

ocp-poddisruptionbudget-is-policy-api [IN] OBSERVATION

PodDisruptionBudget and Eviction are Policy API objects in OpenShift, controlling voluntary pod disruptions and eviction requests respectively.

ocp-podtemplate-is-core-v1-not-openshift [IN] OBSERVATION

PodTemplate is a core Kubernetes v1 resource, not an OpenShift-specific extension — unlike Template, TemplateInstance, and BrokerTemplateInstance which are template.openshift.io/v1

ocp-policy-apis-distinct-group [IN] OBSERVATION

OpenShift Container Platform organizes its APIs into distinct groups, with Policy APIs being one such group covering access control, authorization, and policy enforcement.

ocp-port-6443-api-22623-mcs [IN] OBSERVATION

Port 6443 is the Kubernetes API server port (load balanced to control plane); port 22623 is the Machine Config Server port (internal load balancer to control plane).

ocp-power-monitoring-container-level-per-namespace [IN] OBSERVATION

The Power Monitoring Operator tracks power consumption metrics (CPU, DRAM) at the container level and reports per namespace.

ocp-power-monitoring-cpu-dram-container-level [IN] OBSERVATION

Power Monitoring in OpenShift tracks CPU and DRAM power consumption at container-level granularity and must be explicitly configured (not enabled by default).

ocp-power-monitoring-kepler-prometheus [IN] OBSERVATION

Power Monitoring in OpenShift is typically powered by Kepler (Kubernetes-based Efficient Power Level Exporter), which exports power metrics as Prometheus metrics scraped by the in-cluster monitoring stack.

ocp-power-monitoring-tech-preview [IN] OBSERVATION

Power Monitoring in OpenShift is a Technology Preview feature.

ocp-primary-ex280-certification-target [IN] OBSERVATION

Red Hat OpenShift Container Platform is the core self-managed product and the primary target of the EX280/DO280 certification track.

ocp-project-api-group [IN] OBSERVATION

The API group for OpenShift project resources is project.openshift.io/v1.

ocp-project-deletion-active-terminating-removed [IN] OBSERVATION

Project deletion transitions through states: Active → Terminating → removed; no new content can be added during Terminating.

ocp-project-extends-namespace [IN] OBSERVATION

OpenShift Projects extend Kubernetes namespaces with additional metadata including display name, description, and requesting user annotations.

ocp-project-required-before-app-creation [IN] OBSERVATION

A project (or access to one with appropriate roles) is required before creating an application in OpenShift.

ocp-project-self-provisioning-cli [IN] OBSERVATION

Projects can be self-provisioned by users (controlled by the self-provisioners cluster role binding), managed via oc new-project, oc project, and oc projects commands, and customized via ProjectRequestTemplate.

ocp-projects-extend-k8s-namespaces [IN] OBSERVATION

OpenShift Projects wrap Kubernetes namespaces with additional metadata and policy, serving as the primary multi-tenancy boundary; the Project API is an OpenShift-specific extension, not a vanilla Kubernetes API.

ocp-projects-wrap-namespaces [IN] OBSERVATION

OpenShift projects are OpenShift's abstraction over Kubernetes namespaces, serving as the organizational boundary for applications.

ocp-prometheus-default-evaluation-interval-30s [IN] OBSERVATION

The default Prometheus evaluation interval is 30 seconds unless overridden per rule group.

ocp-provides-multiple-cicd-solutions [IN] OBSERVATION

OpenShift Container Platform provides multiple CI/CD solutions, not a single integrated pipeline.

ocp-provisioning-apis-bare-metal-metal3-ironic [IN] OBSERVATION

Provisioning APIs in OpenShift underpin the Bare Metal IPI workflow, managing BareMetalHost and Provisioning custom resources, and integrate with Metal³ and Ironic for bare-metal host discovery and provisioning.

ocp-provisioning-vs-machine-api-distinction [IN] OBSERVATION

Provisioning APIs handle lower-level infrastructure provisioning while Machine APIs manage the OpenShift-level machine lifecycle; these are separate API groups in OpenShift.

ocp-prune-commands-default-dry-run [IN] OBSERVATION

All oc adm prune commands default to dry-run mode; the --confirm flag is required to actually delete objects.

ocp-prune-default-retention-values [IN] OBSERVATION

Default pruning retention values: --keep-complete=5, --keep-failed=1, --keep-younger-than=60m, --keep-tag-revisions=3.

ocp-prune-over-size-limit-exclusive [IN] OBSERVATION

The --prune-over-size-limit flag cannot be combined with --keep-tag-revisions or --keep-younger-than; they are mutually exclusive strategies.

ocp-publish-internal-private-cluster [IN] OBSERVATION

Setting publish: Internal in install-config.yaml creates a private cluster inaccessible from the internet.

ocp-pull-secret-no-drain-since-474 [IN] OBSERVATION

As of OCP 4.7.4, changes to the global pull secret no longer trigger node drains or reboots

ocp-quickstart-access-review-resources-rbac [IN] OBSERVATION

The accessReviewResources field on ConsoleQuickStart controls which users can see a quick start based on RBAC permissions.

ocp-quickstart-cr-api-group [IN] OBSERVATION

Quick starts are defined by the ConsoleQuickStart custom resource in API group console.openshift.io/v1.

ocp-quickstart-next-references-cr-name [IN] OBSERVATION

The nextQuickStart field references other quick starts by their CR metadata name, not their displayName.

ocp-quota-besteffort-scope-pods-only [IN] OBSERVATION

The BestEffort quota scope can only restrict the pods count (not CPU or memory).

ocp-quota-cpu-requests-cpu-interchangeable [IN] OBSERVATION

In ResourceQuota, cpu and requests.cpu are interchangeable; same for memory/requests.memory and ephemeral-storage/requests.ephemeral-storage.

ocp-quota-forces-explicit-resource-specs [IN] OBSERVATION

When a quota specifies requests.cpu or limits.memory, every incoming container must explicitly declare those values or creation is rejected.

ocp-quota-object-count-syntax [IN] OBSERVATION

Object count quotas use the count/<resource>.<group> syntax (e.g., count/deployments.apps).

ocp-quota-storage-class-zero-prevents-use [IN] OBSERVATION

Setting a storage class quota value to "0" prevents any use of that storage class in the project.

ocp-rbac-subject-types [IN] OBSERVATION

The four types of subjects in OpenShift RBAC are: Users, Groups, Service Accounts, and system identities.

ocp-rbac-two-levels [IN] OBSERVATION

RBAC in OpenShift operates at two levels: cluster roles (cluster-wide) and local/project roles (namespace-scoped).

ocp-requesting-user-gets-admin-role [IN] OBSERVATION

The user who creates a project is automatically assigned the admin role for that project (via the default project template).

ocp-required-dns-records [IN] OBSERVATION

Required DNS records for OCP: api.<cluster>.<domain> (public+private), api-int.<cluster>.<domain> (private only), *.apps.<cluster>.<domain> (public+private), plus etcd A records and etcd-server-ssl.tcp SRV records

ocp-reserved-project-prefixes-require-adm [IN] OBSERVATION

Projects starting with openshift- or kube- cannot be created with oc new-project; they require oc adm new-project.

ocp-restricted-network-requires-local-osus [IN] OBSERVATION

Restricted/disconnected network clusters require a locally installed OpenShift Update Service (OSUS) instance and mirrored images

ocp-restricted-network-requires-mirror-registry [IN] OBSERVATION

Restricted network (disconnected) installations require a mirror registry containing OCP images; the cluster shows "Unable to retrieve available updates" and Developer Catalog is unavailable by default.

ocp-rhcos-ssh-core-user [IN] OBSERVATION

SSH access to RHCOS nodes uses the core user; the SSH key is injected via Ignition config

ocp-rhdh-uses-janus-idp-backstage [IN] OBSERVATION

Red Hat Developer Hub (RHDH) is based on the Janus IDP platform (upstream Backstage) and provides a centralized software catalog.

ocp-rhel-workers-api-before-kubelet [IN] OBSERVATION

RHEL worker nodes require the OpenShift API to be updated before the kubelet during cluster upgrades

ocp-rhosp-upi-dns-manual-cleanup [IN] OBSERVATION

DNS records must be manually cleaned up after running the RHOSP UPI teardown playbooks.

ocp-rhosp-upi-requires-nova-neutron-secgroups [IN] OBSERVATION

For UPI on RHOSP, you must manually create Nova servers, Neutron ports, and security groups.

ocp-rhosp-upi-teardown-order [IN] OBSERVATION

RHOSP UPI teardown playbook order: down-bootstrap, down-control-plane, down-compute-nodes, down-load-balancers, down-network, down-security-groups (dependent resources removed before infrastructure).

ocp-rhosp-upi-uninstall-uses-ansible-playbooks [IN] OBSERVATION

UPI cluster removal on RHOSP uses Ansible playbooks prefixed with "down-", not the openshift-install binary (which is used for IPI).

ocp-rollback-not-supported [IN] OBSERVATION

Rolling back an OCP cluster to a previous version is not supported — only forward updates are allowed.

ocp-route-is-openshift-specific-not-core-k8s [IN] OBSERVATION

The Route API object is an OpenShift-specific resource, not a core Kubernetes resource.

ocp-route-lb-strategies [IN] OBSERVATION

Load balancing strategy can be configured per-route with options: roundrobin, leastconn, source.

ocp-route-tls-termination-types [IN] OBSERVATION

OpenShift Routes support three TLS termination types: edge, passthrough, and re-encrypt.

ocp-routes-openshift-specific-resource [IN] OBSERVATION

Routes are an OpenShift-specific resource for exposing services externally; Ingress is the upstream Kubernetes equivalent — OCP supports both

ocp-routes-vs-ingress-features [IN] OBSERVATION

OpenShift Routes support TLS re-encryption, TLS passthrough, and blue-green traffic splitting — features not available in standard Kubernetes Ingress resources.

ocp-runs-fsck-before-mount [IN] OBSERVATION

OpenShift automatically runs fsck on volumes before mounting them.

ocp-runs-on-rhcos [IN] OBSERVATION

OpenShift Container Platform runs on Red Hat Enterprise Linux CoreOS (RHCOS) and uses kdump for kernel crash analysis.

ocp-scalability-performance-top-level-section [IN] OBSERVATION

Scalability and Performance is a top-level documentation section in OpenShift Container Platform covering both cluster scaling (changing capacity) and performance tuning (optimizing existing resources).

ocp-scc-distinct-from-rbac [IN] OBSERVATION

Security Context Constraints (SCCs) are an authorization mechanism for pod-level security that is related to but distinct from RBAC.

ocp-scc-unique-to-openshift [IN] OBSERVATION

SecurityContextConstraints (SCCs) are unique to OpenShift and not present in vanilla Kubernetes, available via the security.openshift.io API group.

ocp-secondary-network-types-sriov-macvlan-bridge-ipvlan [IN] OBSERVATION

Supported secondary network types in OpenShift include SR-IOV, Macvlan, Bridge, and IPVLAN.

ocp-secondary-networks-defined-by-nad [IN] OBSERVATION

Secondary network configurations are defined using NetworkAttachmentDefinition (NAD) custom resources.

ocp-security-fips-install-time-only [IN] OBSERVATION

FIPS compliance mode in OpenShift Container Platform must be enabled at install time and cannot be enabled post-install.

ocp-security-three-domains [IN] OBSERVATION

OpenShift security documentation spans three domains: container security, certificate configuration, and encryption.

ocp-self-provisioner-bound-to-authenticated-oauth [IN] OBSERVATION

The self-provisioner cluster role is bound to system:authenticated:oauth by default via the self-provisioners cluster role binding.

ocp-separate-subscription-rhacm-acs-odf-quay [IN] OBSERVATION

RHACM, ACS, ODF, and Red Hat Quay require separate subscriptions regardless of whether you have OKE or OCP.

ocp-serverless-based-on-knative [IN] OBSERVATION

OpenShift Serverless is built on Knative and provides Kubernetes-native building blocks for serverless, event-driven applications on OpenShift.

ocp-serverless-operator-changes-default-resource [IN] OBSERVATION

When the OpenShift Serverless Operator is installed, the default resource type for new applications changes to Serverless Deployment

ocp-serverless-optional-install [IN] OBSERVATION

OpenShift Serverless is an optional component, not enabled by default, installed via the OpenShift Serverless Operator.

ocp-service-mesh-built-on-istio [IN] OBSERVATION

OpenShift Service Mesh is built on Istio and deployed via the OpenShift Service Mesh Operator along with dependent operators like Kiali and Jaeger/Tempo.

ocp-service-mesh-two-active-versions [IN] OBSERVATION

OpenShift Service Mesh has two active major versions (2.x and 3.x); 3.x was in tech preview as of OCP 4.17.

ocp-service-mesh-under-integration [IN] OBSERVATION

Service Mesh is categorized under Integration in OpenShift documentation, not under Networking

ocp-seven-observability-tools [IN] OBSERVATION

OpenShift Observability encompasses seven tools: Monitoring, Network Observability, Logging, OpenTelemetry, Distributed Tracing, Insights, and Power Monitoring.

ocp-six-observability-components [IN] OBSERVATION

OpenShift Observability has six core components: Monitoring, Logging, Distributed Tracing, Red Hat build of OpenTelemetry, Network Observability, and Power Monitoring.

ocp-sno-and-two-node-topologies [IN] OBSERVATION

Single Node OpenShift (SNO) and Two Node OpenShift are supported deployment topologies

ocp-specialized-cli-tools [IN] OBSERVATION

OpenShift provides multiple specialized CLI tools beyond oc: kn (Serverless), tkn (Pipelines), helm (charts), oc-mirror (disconnected image mirroring), odo (developer), argocd (GitOps).

ocp-ssh-access-disaster-recovery-only [IN] OBSERVATION

Direct SSH access to OpenShift nodes should only be used for disaster recovery; when the Kubernetes API is responsive, use privileged pods instead

ocp-storage-model-pv-pvc-storageclass [IN] OBSERVATION

OpenShift uses persistent volumes (PVs), persistent volume claims (PVCs), and StorageClasses as its core storage model with support for dynamic provisioning.

ocp-storage-uses-csi-plugin-architecture [IN] OBSERVATION

OpenShift 4.x uses the Container Storage Interface (CSI) as its standard plugin architecture for storage backends.

ocp-supported-accelerator-hardware [IN] OBSERVATION

Three specific hardware accelerators are supported by OCP: NVIDIA GPU, AMD Instinct GPU, and Intel Gaudi.

ocp-supported-architectures-x86-ppc64le-s390x [IN] OBSERVATION

OpenShift Container Platform supports multiple CPU architectures: x86_64 (amd64), ppc64le (IBM Power), and s390x (IBM Z).

ocp-supported-cloud-platforms-list [IN] OBSERVATION

The primary supported cloud/infrastructure installation targets for OCP include AWS, Azure, Azure Stack Hub, GCP, bare metal, and vSphere.

ocp-supported-install-platforms [IN] OBSERVATION

OCP 4.17 supports installation on AWS, Azure, Azure Stack Hub, GCP, IBM Cloud, IBM Z/LinuxONE, IBM Power, Alibaba Cloud, Nutanix, OpenStack, OCI, VMware vSphere, bare metal (UPI and IPI), and single node.

ocp-supports-dual-stack-ipv4-ipv6 [IN] OBSERVATION

OpenShift Container Platform supports IPv4, IPv6, and dual-stack (IPv4 + IPv6) addressing

ocp-supports-ibm-cloud-bare-metal-classic [IN] OBSERVATION

OpenShift Container Platform supports installation on IBM Cloud Bare Metal (Classic) infrastructure as of OCP 4.21.

ocp-supports-ibm-power-ppc64le [IN] OBSERVATION

OpenShift Container Platform supports installation on IBM Power systems using the ppc64le architecture.

ocp-supports-ibm-power-virtual-server [IN] OBSERVATION

IBM Power Virtual Server (cloud-based IaaS for Power architecture) is a supported installation platform for OCP 4.21, distinct from IBM Power bare metal.

ocp-supports-ibm-powervc [IN] OBSERVATION

OpenShift Container Platform supports installation on IBM PowerVC as a distinct platform option from other IBM Power deployment methods.

ocp-supports-ibm-z-s390x [IN] OBSERVATION

OpenShift Container Platform supports installation on IBM Z and IBM LinuxONE using the s390x architecture.

ocp-supports-multi-arch-clusters [IN] OBSERVATION

OCP 4.17 supports heterogeneous multi-architecture clusters that can include Power nodes alongside other architectures.

ocp-supports-ptp-hardware-time-sync [IN] OBSERVATION

OpenShift Container Platform supports PTP (Precision Time Protocol) hardware for time synchronization in latency-sensitive workloads.

ocp-supports-sctp [IN] OBSERVATION

OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as an advanced networking feature beyond TCP/UDP.

ocp-supports-sctp-transport-protocol [IN] OBSERVATION

OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as a transport-layer protocol, relevant for telecom workloads.

ocp-telemeter-client-sends-data-to-redhat [IN] OBSERVATION

The Telemeter Client sends a subset of platform Prometheus data to Red Hat for Remote Health Monitoring.

ocp-template-hardcoded-namespace-removed [IN] OBSERVATION

Hardcoded namespace values in Template objects are removed during instantiation; only ${PARAMETER_REFERENCE} namespace values are preserved

ocp-template-instantiate-via-processedtemplates [IN] OBSERVATION

To process/instantiate a template via the API, POST to the processedtemplates endpoint (/apis/template.openshift.io/v1/namespaces/{namespace}/processedtemplates)

ocp-template-objects-only-required-field [IN] OBSERVATION

The only required field in an OpenShift Template is objects — the array of resources to include

ocp-template-only-generator-expression [IN] OBSERVATION

The only supported generator type for Template parameters is "expression", which produces random strings from regex-like patterns (e.g., [a-zA-Z0-9]{8})

ocp-template-param-value-overrides-generator [IN] OBSERVATION

A Template parameter's value field takes precedence over the generate/from generator — if value is set, the generator is ignored

ocp-template-parameter-syntax-dollar-brace [IN] OBSERVATION

Template parameters are referenced using ${PARAMETER_NAME} syntax (not {{}} or other formats)

ocp-template-process-command [IN] OBSERVATION

oc process is the CLI command to process a template into a list of resources

ocp-template-vs-templateinstance-distinction [IN] OBSERVATION

A Template is the definition with parameters; a TemplateInstance is the record of an instantiation of that template

ocp-templates-cluster-wide-via-openshift-namespace [IN] OBSERVATION

Templates can be stored in a project namespace or in the openshift namespace for cluster-wide availability

ocp-templates-openshift-specific-not-upstream [IN] OBSERVATION

Templates are an OpenShift-specific resource type (API group template.openshift.io/v1), not available in vanilla Kubernetes

ocp-three-networking-dashboard-categories [IN] OBSERVATION

OCP provides three networking dashboard categories: Networking/Linux Subsystem Stats (utilisation, saturation, errors), Networking/Infrastructure (OVN-Kubernetes metrics), and Networking/Ingress (Ingress Operator metrics).

ocp-three-observability-pillars [IN] OBSERVATION

The three pillars of observability in OpenShift are monitoring (metrics via Prometheus/Alertmanager), logging (Loki/Vector), and distributed tracing.

ocp-three-oracle-install-targets [IN] OBSERVATION

OCP supports three distinct Oracle installation targets: Oracle Cloud Infrastructure (OCI), Oracle Distributed Cloud, and Oracle Edge Cloud.

ocp-tls-default-profile-intermediate [IN] OBSERVATION

The default TLS security profile for all OpenShift components (Ingress Controller, control plane, kubelet) is Intermediate, with minimum TLS 1.2.

ocp-tls-four-profile-types [IN] OBSERVATION

OpenShift supports four TLS security profile types: Old, Intermediate, Modern, and Custom, based on Mozilla recommended configurations.

ocp-tls-version-format [IN] OBSERVATION

TLS version values in OpenShift use the format VersionTLS11, VersionTLS12, VersionTLS13.

ocp-topology-view-in-developer-perspective [IN] OBSERVATION

The Topology view is in the Developer perspective (not Administrator) and is the primary UI for managing application lifecycle.

ocp-tracing-jaeger-deprecated-for-tempo [IN] OBSERVATION

Jaeger has been deprecated in favor of Tempo as the tracing backend in recent OpenShift Container Platform versions.

ocp-tracing-operator-managed-olm [IN] OBSERVATION

Distributed tracing components in OpenShift are installed and managed via OLM Operators (OpenTelemetry Operator and Tempo Operator).

ocp-tracing-two-components-otel-tempo [IN] OBSERVATION

OpenShift distributed tracing has two main components: Red Hat build of OpenTelemetry (collecting/forwarding trace data) and Red Hat distributed tracing platform Tempo (storing/querying traces).

ocp-two-authorization-api-groups [IN] OBSERVATION

OpenShift has two parallel authorization API groups: authorization.openshift.io/v1 (6 resources) and authorization.k8s.io/v1 (4 resources).

ocp-two-build-systems [IN] OBSERVATION

OCP has two build systems: the traditional BuildConfig-based system (available since OpenShift 3.x) and the newer Shipwright-based Builds system.

ocp-two-build-systems-shipwright-buildconfig [IN] OBSERVATION

OpenShift has two coexisting build systems: Shipwright (newer, extensible) and BuildConfig (legacy)

ocp-two-console-resources-different-api-groups [IN] OBSERVATION

There are two Console resources: one under config.openshift.io (edited via oc edit for console config) and one under operator.openshift.io (used for operator management and quick start configuration).

ocp-two-node-topology-421 [IN] OBSERVATION

Two Node OpenShift (TNO) is a supported cluster topology starting in OCP 4.21, distinct from SNO (1 node) and standard HA clusters (3+ control plane nodes).

ocp-unsupported-config-overrides-blocks-upgrades [IN] OBSERVATION

The unsupportedConfigOverrides field on operator resources is unsupported by Red Hat and blocks cluster upgrades; it must be removed before upgrading.

ocp-update-channels-progression [IN] OBSERVATION

OpenShift update channel stability progression is: candidate → fast → stable → eus.

ocp-update-non-disruptive [IN] OBSERVATION

OCP cluster updates are non-disruptive — the cluster remains online during the update process (except single-node OpenShift which requires downtime)

ocp-update-rollback-not-supported [IN] OBSERVATION

Rolling back a failed OCP cluster update is not supported — contact Red Hat support instead

ocp-update-upgrade-interchangeable [IN] OBSERVATION

The terms "updating" and "upgrading" are used interchangeably in OCP documentation

ocp-updates-zero-downtime [IN] OBSERVATION

OCP cluster updates are designed to be performed without taking the cluster offline (in-place, zero-downtime model).

ocp-upi-csr-manual-approval [IN] OBSERVATION

In UPI installations, kubelet serving certificate CSRs must be manually approved because the machine-approver cannot validate them automatically

ocp-upi-minimum-machines [IN] OBSERVATION

UPI installation requires a minimum of 1 temporary bootstrap machine, 3 control plane machines, and 2 compute (worker) machines

ocp-upi-orphaned-resources-risk [IN] OBSERVATION

UPI clusters may leave orphaned Azure resources that require manual cleanup since the installer didn't create all of them.

ocp-user-group-apis-not-native-k8s [IN] OBSERVATION

OpenShift extends Kubernetes with its own User and Group custom resource types that are not native to upstream Kubernetes.

ocp-user-workload-monitoring-requires-explicit-enable [IN] OBSERVATION

User workload monitoring must be explicitly enabled; it is not active by default even though cluster monitoring is.

ocp-users-cluster-scoped [IN] OBSERVATION

User objects in OpenShift are cluster-scoped resources (not namespaced).

ocp-v411-baseline-capabilities [IN] OBSERVATION

The v4.11 baselineCapabilitySet includes only: baremetal, MachineAPI, marketplace, and openshift-samples.

ocp-version-format [IN] OBSERVATION

OCP release versioning format: in 4.13.2, 4 = major, 13 = minor, 2 = z-stream.

ocp-versioning-major-minor-scheme [IN] OBSERVATION

OpenShift Container Platform versioning follows a major.minor scheme (e.g., 4.17).

ocp-view-capabilities-command [IN] OBSERVATION

Cluster capabilities can be viewed with oc get clusterversion version -o jsonpath='{.spec.capabilities}' (desired) and oc get clusterversion version -o jsonpath='{.status.capabilities}' (actual).

ocp-virt-417-requires-ocp-417 [IN] OBSERVATION

OpenShift Virtualization 4.17 requires OCP 4.17 — version alignment is mandatory.

ocp-virt-aws-ebs-gp3-no-live-migration [IN] OBSERVATION

On AWS, EBS gp3 storage does not support live migration or cloning; EFS does not support cloning or snapshots.

ocp-virt-bandwidth-per-migration-zero-unlimited [IN] OBSERVATION

In OpenShift Virtualization, bandwidthPerMigration: 0 means unlimited bandwidth (this is the default).

ocp-virt-boot-sources-namespace [IN] OBSERVATION

Boot source images are stored in the openshift-virtualization-os-images namespace.

ocp-virt-cannot-run-single-stack-ipv6 [IN] OBSERVATION

OpenShift Virtualization cannot run on single-stack IPv6 clusters.

ocp-virt-cdi-scratch-space [IN] OBSERVATION

CDI requires scratch space (a temporary PVC equal to the destination DataVolume size) during import and upload operations.

ocp-virt-checkup-framework-tech-preview [IN] OBSERVATION

The cluster checkup framework for OpenShift Virtualization is Technology Preview in OCP 4.17 and includes three types: latency, DPDK, and storage checkups.

ocp-virt-checkup-results-in-configmap [IN] OBSERVATION

Cluster checkup results are stored in the same ConfigMap used for input (status fields are appended).

ocp-virt-cloning-strategies [IN] OBSERVATION

Three cloning strategies for VM disks: snapshot (default when snapshots available), csi-clone (must be explicitly configured), and copy (host-assisted, least efficient).

ocp-virt-components-openshift-cnv-namespace [IN] OBSERVATION

All OpenShift Virtualization components run in the openshift-cnv namespace.

ocp-virt-dedicated-multus-network-recommended [IN] OBSERVATION

A dedicated Multus network for live migration traffic is highly recommended to avoid saturating tenant workload networks.

ocp-virt-default-fs-overhead-5-5-percent [IN] OBSERVATION

Default file system overhead for VM PVCs is 5.5% of PVC space.

ocp-virt-default-mincpu-penryn [IN] OBSERVATION

The default minCPU model for CPU feature labeling in OpenShift Virtualization is Penryn.

ocp-virt-default-parallel-migrations-5 [IN] OBSERVATION

The default parallel migration limit in OpenShift Virtualization is 5 cluster-wide and 2 outbound per node.

ocp-virt-default-pod-network-interrupted-live-migration [IN] OBSERVATION

Traffic on the default pod network is interrupted during live migration of VMs.

ocp-virt-default-storage-class-annotation [IN] OBSERVATION

The annotation storageclass.kubevirt.io/is-default-virt-class: "true" marks a storage class as the virtualization default; if both OCP and virtualization default storage classes exist, the virtualization class takes precedence for VM disks.

ocp-virt-dpdk-checkup-zero-packet-loss [IN] OBSERVATION

The DPDK checkup verifies that VMs can run Data Plane Development Kit workloads with zero packet loss, and requires SR-IOV networking.

ocp-virt-enable-common-boot-image-import-feature-gate [IN] OBSERVATION

The enableCommonBootImageImport feature gate in HyperConverged CR controls automatic updates for Red Hat boot sources; custom boot sources are not affected by this gate.

ocp-virt-eviction-livemigrate-default-multinode [IN] OBSERVATION

The default VM eviction strategy is LiveMigrate for multi-node clusters and None for single-node OpenShift (SNO).

ocp-virt-failed-node-drain-force [IN] OBSERVATION

For failed/offline nodes, oc adm drain --force=true is required; hardware should be powered down before proceeding to avoid data corruption on shared storage.

ocp-virt-hotplug-memory-cpu-ga-417 [IN] OBSERVATION

Hot-plug memory and CPU from the web console are GA in OpenShift Virtualization 4.17.

ocp-virt-hpp-same-nodes-requirement [IN] OBSERVATION

HostPathProvisioner (HPP) pods must run on the same nodes as OpenShift Virtualization components — this is a hard requirement.

ocp-virt-hyperconverged-cr-required [IN] OBSERVATION

After installing the OpenShift Virtualization operator, a HyperConverged custom resource must be created to deploy the virtualization platform.

ocp-virt-hyperconverged-separate-infra-workloads [IN] OBSERVATION

The HyperConverged CR has separate spec.infra.nodePlacement and spec.workloads.nodePlacement sections for placing infrastructure vs workload components.

ocp-virt-initiate-migration-vmim-object [IN] OBSERVATION

To initiate live migration via CLI, create a VirtualMachineInstanceMigration object; to cancel, delete it with oc delete vmim. Alternatively, use virtctl migrate and virtctl migrate-cancel.

ocp-virt-integrated-feature [IN] OBSERVATION

OpenShift Virtualization is an integrated feature of OpenShift Container Platform that allows running and managing virtual machines alongside containers, not a separate product.

ocp-virt-ipam-not-supported-vm-nad [IN] OBSERVATION

IPAM is not supported in Network Attachment Definitions (NADs) for virtual machines.

ocp-virt-kubemacpool-unique-mac [IN] OBSERVATION

KubeMacPool allocates unique MAC addresses from a shared pool for VMs; addresses persist across reboots.

ocp-virt-latency-checkup-requirements [IN] OBSERVATION

The latency checkup requires a bridge interface on cluster nodes, at least two worker nodes, and a configured NetworkAttachmentDefinition.

ocp-virt-live-migration-defaults [IN] OBSERVATION

Default live migration settings: completionTimeoutPerGiB=800, parallelMigrationsPerCluster=5, parallelOutboundMigrationsPerNode=2, progressTimeout=150.

ocp-virt-live-migration-nad-openshift-cnv-namespace [IN] OBSERVATION

The live migration network NAD must be created in the openshift-cnv namespace.

ocp-virt-live-migration-pre-copy-default [IN] OBSERVATION

Live migration uses pre-copy mode by default (iteratively copies memory pages while VM runs); post-copy mode is opt-in via allowPostCopy: true and not recommended for critical data or unstable networks.

ocp-virt-live-migration-requires-rwx [IN] OBSERVATION

Live migration requires ReadWriteMany (RWX) shared storage as a hard requirement.

ocp-virt-localnet-requires-nncp-layer2-does-not [IN] OBSERVATION

OVN-Kubernetes localnet requires OVS bridge configuration via NNCP before creating the NAD; layer2 topology does not require NNCP.

ocp-virt-localnet-supports-netpol-not-trunk [IN] OBSERVATION

OVN-Kubernetes localnet supports network policies but not trunk access; Linux bridge supports trunk access but not network policies.

ocp-virt-masquerade-default-pod-network [IN] OBSERVATION

Masquerade mode is the required binding mode for connecting VMs to the default pod network; it uses NAT via a Linux bridge.

ocp-virt-mellanox-reboot-on-vf-increase [IN] OBSERVATION

SR-IOV with Mellanox NICs causes node reboots when VFs are increased; Intel NICs reboot only if intel_iommu=on and iommu=pt kernel params are missing.

ocp-virt-migration-config-in-hyperconverged [IN] OBSERVATION

Live migration cluster-wide settings are configured in the HyperConverged CR under spec.liveMigrationConfig in the openshift-cnv namespace.

ocp-virt-migration-policy-label-selectors [IN] OBSERVATION

MigrationPolicy objects allow per-group migration configurations using label selectors on VMs and/or namespaces; when multiple policies match, the one with the most matching labels wins, with ties broken alphabetically by label key.

ocp-virt-migration-tls-encrypted-default [IN] OBSERVATION

Live migration traffic in OpenShift Virtualization is encrypted with TLS by default.

ocp-virt-multus-enables-multiple-networks [IN] OBSERVATION

Multus is a meta CNI plugin that enables pods and VMs to connect to multiple network interfaces using other CNI plugins.

ocp-virt-namespace-openshift-cnv [IN] OBSERVATION

OpenShift Virtualization must be installed into the openshift-cnv namespace; installing to any other namespace causes failure.

ocp-virt-nmo-standalone-operator [IN] OBSERVATION

The Node Maintenance Operator (NMO) is a standalone Operator deployed from OperatorHub — it is no longer shipped with OpenShift Virtualization.

ocp-virt-no-single-stack-ipv6 [IN] OBSERVATION

OpenShift Virtualization cannot run on single-stack IPv6 clusters.

ocp-virt-node-exporter-daemonset-in-vm [IN] OBSERVATION

Custom VM metrics in OpenShift Virtualization are exposed via node-exporter running as a DaemonSet inside the VM, not on the host.

ocp-virt-nonmigratable-livemigrate-blocks-upgrades [IN] OBSERVATION

Non-migratable VMs with LiveMigrate eviction strategy will block node drains and cluster upgrades; use LiveMigrateIfPossible or None instead.

ocp-virt-odf-best-practice-rbd-block [IN] OBSERVATION

ODF best practice for OpenShift Virtualization: use ocs-storagecluster-ceph-rbd storage class with VolumeMode: Block for best performance.

ocp-virt-odf-dedicated-storage-windows [IN] OBSERVATION

OpenShift Data Foundation deployments require a dedicated storage class for Windows VM disks.

ocp-virt-operator-name [IN] OBSERVATION

The OpenShift Virtualization operator is called kubevirt-hyperconverged and is installed via OLM from the redhat-operators catalog source.

ocp-virt-ovn-kubernetes-required-cni [IN] OBSERVATION

OVN-Kubernetes is the supported (required) network provider for OpenShift Virtualization.

ocp-virt-ovn-localnet-recommended-underlay [IN] OBSERVATION

OVN-Kubernetes localnet is the recommended method to expose VMs to the underlying physical network (preferred over Linux bridge).

ocp-virt-ports-49152-49153-reserved [IN] OBSERVATION

Ports 49152 and 49153 are reserved by the libvirt platform and incoming traffic to these ports is dropped.

ocp-virt-postcopy-live-migration-ga-417 [IN] OBSERVATION

Post-copy live migration is GA in OpenShift Virtualization 4.17.

ocp-virt-run-strategies [IN] OBSERVATION

VM run strategies are: Always (same as running:true), RerunOnFailure, Manual, and Halted (same as running:false).

ocp-virt-runstrategy-running-mutually-exclusive [IN] OBSERVATION

spec.runStrategy and spec.running are mutually exclusive in a VirtualMachine spec — using both is invalid.

ocp-virt-rwo-no-live-migrate [IN] OBSERVATION

VMs with RWO storage or passthrough devices (GPUs) cannot live migrate; they require evictionStrategy: None.

ocp-virt-rwx-block-best-practice [IN] OBSERVATION

ReadWriteMany (RWX) access mode and Block volume mode are the recommended best practice for VM disks in OpenShift Virtualization.

ocp-virt-rwx-pvc-required-live-migration [IN] OBSERVATION

VMs require RWX (ReadWriteMany) PVCs to be live migrated during node maintenance.

ocp-virt-sno-no-live-migration [IN] OBSERVATION

Single-node OpenShift (SNO) does not support live migration, HA, pod disruption budgets, or eviction strategies for OpenShift Virtualization.

ocp-virt-sriov-setup-order [IN] OBSERVATION

SR-IOV setup order for VMs: SriovNetworkNodePolicy → SriovNetwork → VM config.

ocp-virt-storage-checkup-cluster-reader [IN] OBSERVATION

The storage checkup service account requires a cluster-reader ClusterRoleBinding (cluster-scoped, not namespace-scoped).

ocp-virt-storage-profile-per-storage-class [IN] OBSERVATION

One StorageProfile is automatically created per StorageClass; if CDI does not recognize the provisioner, manual configuration is required (empty status section indicates this).

ocp-virt-subscription-channel-stable [IN] OBSERVATION

The OpenShift Virtualization operator subscription channel must be set to stable.

ocp-virt-subscription-no-affinity [IN] OBSERVATION

The Subscription object for OpenShift Virtualization node placement supports only nodeSelector and tolerations — it does not support affinity.

ocp-virt-supported-platforms-bare-metal [IN] OBSERVATION

OpenShift Virtualization supported platforms include on-prem bare metal and AWS bare metal (c5n.metal); IBM Cloud Bare Metal is Tech Preview only; other cloud bare metal is not supported.

ocp-virt-underlay-not-supported-rosa [IN] OBSERVATION

Connecting VMs directly to the underlay network is not supported on ROSA (Red Hat OpenShift Service on AWS).

ocp-virt-virt-default-storage-class-overrides [IN] OBSERVATION

The virt-default storage class (annotated storageclass.kubevirt.io/is-default-virt-class: "true") takes precedence over the cluster default storage class for virtualization workloads.

ocp-virt-vm-name-max-47-chars [IN] OBSERVATION

VM name must not exceed 47 characters or live migration will fail.

ocp-virt-vms-must-dhcp-masquerade [IN] OBSERVATION

VMs must use DHCP to acquire IPv4 addresses when using masquerade mode on the default pod network.

ocp-virt-vtpm-data-ephemeral [IN] OBSERVATION

vTPM data is ephemeral in OpenShift Virtualization — lost on migration or restart (affects BitLocker).

ocp-virt-wasp-agent-memory-overcommit [IN] OBSERVATION

Memory overcommit in OpenShift Virtualization uses wasp-agent which assigns swap to worker nodes.

ocp-virt-watchdog-device-i6300esb [IN] OBSERVATION

The watchdog device type for OpenShift Virtualization VMs is i6300esb with supported actions: poweroff, reset, or shutdown; requires the watchdog package installed and enabled inside the VM.

ocp-virt-workers-must-be-rhcos [IN] OBSERVATION

OpenShift Virtualization worker nodes must run RHCOS; RHEL worker nodes are not supported.

ocp-vrf-supported-for-network-segmentation [IN] OBSERVATION

Virtual Routing and Forwarding (VRF) is supported in OpenShift for network segmentation, allowing multiple independent routing tables on the same node.

ocp-web-console-and-cli-first-class [IN] OBSERVATION

OpenShift Container Platform provides both a web console and CLI (oc) as first-class interfaces for cluster interaction

ocp-web-console-built-in-customizable [IN] OBSERVATION

The OpenShift web console is a built-in, customizable web-based UI component of OpenShift Container Platform (not a separate install).

ocp-web-console-capabilities-installed-via-operatorhub [IN] OBSERVATION

Optional web console capabilities (Pipelines, Serverless, Web Terminal) are installed as Operators through OperatorHub.

ocp-web-console-prefs-in-masthead [IN] OBSERVATION

Web console user preferences are accessed from the masthead (top navigation bar) under the user profile

ocp-web-console-two-perspectives [IN] OBSERVATION

The OpenShift web console has two perspectives: Administrator and Developer; the default can be set in user preferences

ocp-web-console-user-prefs-auto-saved [IN] OBSERVATION

OpenShift web console user preferences are automatically saved — no explicit save action is needed

ocp-web-terminal-operator-provides-browser-cli [IN] OBSERVATION

The Web Terminal Operator provides a browser-based terminal with common CLI tools for interacting with the cluster from the web console.

ocp-worker-wait-times [IN] OBSERVATION

When troubleshooting worker nodes, minimum wait times are 60 minutes for bare metal and 40 minutes for other platforms

ocp-workload-partitioning-install-time-only [IN] OBSERVATION

Workload partitioning (cpuPartitioningMode: AllNodes) can only be enabled at install time and cannot be disabled after installation.

ocp-workloads-api-includes-deploymentconfig-build [IN] OBSERVATION

OpenShift workload APIs extend upstream Kubernetes with additional objects like DeploymentConfig and Build

ocp3-to-4-migration-not-upgrade [IN] OBSERVATION

OCP 3 to 4 is a migration, not an in-place upgrade — the architectures are fundamentally different

ocp4-built-on-operators [IN] OBSERVATION

OpenShift Container Platform 4.x is fundamentally built on Operators — cluster Operators manage core platform components.

ocp4-core-components-managed-as-operators [IN] OBSERVATION

In OpenShift Container Platform 4.x, core platform components are managed as Operators.

ocp4-install-methods-ipi-upi [IN] OBSERVATION

OCP 4.x has two primary installation approaches: Installer-Provisioned Infrastructure (IPI, automated/opinionated) and User-Provisioned Infrastructure (UPI, manual/flexible).

ocp4-operator-based-architecture [IN] OBSERVATION

OCP 4.x uses a fundamentally different architecture than 3.x, based on operators and immutable infrastructure.

ocp4-rhcos-for-control-plane [IN] OBSERVATION

OCP 4 uses RHCOS (Red Hat Enterprise Linux CoreOS) for control plane nodes, replacing the traditional RHEL-based masters in OCP 3

ocp4-uses-openshift-install-binary [IN] OBSERVATION

OCP 4.x uses the openshift-install binary for installation, replacing the Ansible playbook approach used in OCP 3.x.

ocp410-default-ebs-type-gp3 [IN] OBSERVATION

The default EBS storage type for OpenShift Container Platform 4.10+ is gp3, provisioned via the AWS EBS CSI driver.

ocp417-csi-spec-v160 [IN] OBSERVATION

OpenShift Container Platform 4.17 supports CSI specification v1.6.0.

ocp417-default-scc-restricted-v2 [IN] OBSERVATION

In OCP 4.17, the restricted-v2 SCC is applied to all newly created pods by default, which enforces the runtime/default seccomp profile.

ocp417-infraenv-kernel-args-append-only [IN] OBSERVATION

In OCP 4.17, InfraEnv kernel arguments support only the append operation (no replace or delete).

ocp417-requires-ovn-kubernetes-migration [IN] OBSERVATION

OpenShift SDN is no longer supported in OCP 4.17; clusters must migrate to OVN-Kubernetes before upgrading to 4.17.

ocpvirt-arm64-linux-only-no-live-migration [IN] OBSERVATION

ARM64 OpenShift Virtualization supports Linux guests only with no live migration and no hotplug.

ocpvirt-aws-no-sriov-no-bridge-cni [IN] OBSERVATION

AWS bare metal OpenShift Virtualization does not support SR-IOV or bridge CNI; OVN-Kubernetes secondary overlay networks must be used instead.

ocpvirt-cnv-bridge-to-bridge-before-upgrade [IN] OBSERVATION

NetworkAttachmentDefinition spec.config.type must be changed from cnv-bridge to bridge before upgrading from OCP 4.12 or live migration will fail.

ocpvirt-dedicated-multus-migration-network-recommended [IN] OBSERVATION

A dedicated Multus network for live migration is highly recommended to avoid network saturation.

ocpvirt-default-parallel-migrations-5 [IN] OBSERVATION

The default maximum number of parallel live migrations per cluster is 5 in OpenShift Virtualization.

ocpvirt-default-virt-storage-class-annotation [IN] OBSERVATION

The annotation storageclass.kubevirt.io/is-default-virt-class: "true" designates the default virtualization storage class; it takes precedence over the OCP default storage class.

ocpvirt-google-cloud-tech-preview [IN] OBSERVATION

Google Cloud support for OpenShift Virtualization is Technology Preview only (as of 4.21).

ocpvirt-gpu-passthrough-no-live-migration [IN] OBSERVATION

VMs with GPU passthrough cannot be live migrated and must set evictionStrategy: None.

ocpvirt-hotplug-feature-gate [IN] OBSERVATION

Hot plugging volumes on running VMs requires enabling the HotplugVolumes feature gate on the HyperConverged CR in the openshift-cnv namespace.

ocpvirt-hyperconverged-cr-entrypoint [IN] OBSERVATION

The HyperConverged CR is the single entrypoint for configuring OpenShift Virtualization and creates CRs for all sub-operators.

ocpvirt-ibmz-default-cpu-gen15b [IN] OBSERVATION

IBM Z OpenShift Virtualization uses default CPU model gen15b and does not support memory hotplug, SR-IOV, PCI passthrough, vTPM, UEFI, Windows VMs, HugePages, or FIPS mode.

ocpvirt-infra-cpu-overhead-4-cores [IN] OBSERVATION

OpenShift Virtualization infrastructure nodes require 4 additional CPU cores total; each worker node needs 2 additional cores for virtualization management.

ocpvirt-integrated-ocp-feature [IN] OBSERVATION

OpenShift Virtualization is an integrated feature of OpenShift Container Platform (not a separate product), enabling VMs to run alongside containers on the same platform.

ocpvirt-layer2-udn-preserves-ip-live-migration [IN] OBSERVATION

Layer2 topology User-Defined Networks (UDNs) preserve VM IP addresses during live migration without NAT.

ocpvirt-libvirt-session-mode-nonroot [IN] OBSERVATION

virt-launcher pods run libvirt in session mode as non-root (unprivileged), adhering to the restricted Kubernetes pod security standards profile.

ocpvirt-live-migration-defaults [IN] OBSERVATION

Default live migration limits: 2 outbound migrations per node, 5 concurrent migrations per cluster.

ocpvirt-localnet-supports-network-policies-bridge-does-not [IN] OBSERVATION

OVN-Kubernetes localnet topology supports network policies and layer 2 access on primary NICs; Linux bridge supports trunk access but does not support network policies.

ocpvirt-masquerade-default-binding-mode [IN] OBSERVATION

Masquerade is the default binding mode for connecting VMs to the pod network in OpenShift Virtualization; it uses NAT via a Linux bridge to hide VM traffic behind the pod IP.

ocpvirt-memory-dump-pvc-sizing [IN] OBSERVATION

Memory dump PVC must use FileSystem volume mode and be sized as (VMMemorySize + 100Mi) × FileSystemOverhead.

ocpvirt-memory-overhead-formula [IN] OBSERVATION

VM memory overhead ≈ (0.002 × requested memory) + 218 MiB + (8 MiB × vCPUs) + (16 MiB × graphics devices), plus additional overhead for SR-IOV/GPU (1 GiB each), SEV (256 MiB), and TPM (53 MiB).

ocpvirt-mtv-separate-from-ocpvirt [IN] OBSERVATION

Migration Toolkit for Virtualization (MTV) is a separate product from OpenShift Virtualization, requiring separate installation, and supports migration from VMware vSphere, RHOSP, RHV, OVA files, and other OCP clusters.

ocpvirt-multus-meta-cni-plugin [IN] OBSERVATION

Multus is a meta CNI plugin that enables pods and VMs to attach to multiple network interfaces via other CNI plugins using NetworkAttachmentDefinition CRDs.

ocpvirt-node-labels-not-removed-on-uninstall [IN] OBSERVATION

Node labels (feature.node.kubevirt.io) are not automatically removed when uninstalling OpenShift Virtualization and must be cleaned up manually.

ocpvirt-oadp-requires-1-3-x [IN] OBSERVATION

OADP 1.3.x+ is required for OpenShift Virtualization 4.14+; OADP supports only CSI backups and CSI backups with DataMover (not file system backup or volume snapshot backup/restore).

ocpvirt-online-snapshot-5min-deadline [IN] OBSERVATION

Online VM snapshots have a default 5-minute failure deadline, configurable via FailureDeadline in the snapshot spec.

ocpvirt-ossm-compatibility-321 [IN] OBSERVATION

OpenShift Virtualization 4.21 requires OSSM 3.0.4 / Istio 1.24.4 for service mesh compatibility; OSSM 3.1.1 / Istio ≥1.25 are incompatible.

ocpvirt-ports-49152-49153-reserved-libvirt [IN] OBSERVATION

Ports 49152 and 49153 are reserved by the libvirt platform in OpenShift Virtualization; incoming traffic to these ports is dropped.

ocpvirt-public-clouds-use-layer2-udn [IN] OBSERVATION

Public clouds (AWS, Azure, GCP, OCI) cannot connect VMs directly to the underlay; layer2 topology UDNs must be used instead.

ocpvirt-qemu-guest-agent-consistent-snapshots [IN] OBSERVATION

The QEMU guest agent is required for application-consistent (quiesced) online snapshots; without it, only best-effort snapshots are taken.

ocpvirt-rwo-blocks-live-migration [IN] OBSERVATION

VMs with ReadWriteOnce (RWO) storage cannot live migrate and must set evictionStrategy: None.

ocpvirt-rwx-block-recommended [IN] OBSERVATION

The recommended storage configuration for OpenShift Virtualization VMs is ReadWriteMany (RWX) access mode with Block volume mode.

ocpvirt-rwx-block-recommended-storage [IN] OBSERVATION

ReadWriteMany (RWX) access mode with Block volume mode is the recommended storage configuration for OpenShift Virtualization.

ocpvirt-rwx-required-live-migration [IN] OBSERVATION

RWX access mode is required for live migration of VMs; VMs with RWO access mode cannot be live migrated.

ocpvirt-service-account-tokens-invalid-after-migration [IN] OBSERVATION

Service account tokens become invalid after VM migration because they are bound to the original pod; user accounts should be used instead.

ocpvirt-single-stack-ipv6-tech-preview [IN] OBSERVATION

Single-stack IPv6 support in OpenShift Virtualization is Technology Preview only, limited to OVN-Kubernetes localnet and Linux bridge CNI.

ocpvirt-snapshot-feature-gate [IN] OBSERVATION

The Snapshot feature gate must be enabled in the kubevirt CR under spec.developerConfiguration.featureGates for VM snapshots to work.

ocpvirt-snapshot-three-crds [IN] OBSERVATION

VM snapshot management uses three CRDs: VirtualMachineSnapshot (create request), VirtualMachineSnapshotContent (provisioned resource, 1:1 with snapshot), and VirtualMachineRestore (restore request), all in API group snapshot.kubevirt.io/v1beta1.

ocpvirt-sno-no-ha-no-livemigration [IN] OBSERVATION

Single-node OpenShift (SNO) does not support high availability, pod disruption, live migration, or eviction strategies for VMs.

ocpvirt-sno-no-live-migration-ha [IN] OBSERVATION

Single-node OpenShift (SNO) does not support live migration, high availability, pod disruption budgets, or eviction strategies for OpenShift Virtualization.

ocpvirt-sriov-requires-bare-metal-or-rhosp [IN] OBSERVATION

SR-IOV in OpenShift Virtualization requires bare metal or RHOSP — it is not available on public clouds.

ocpvirt-storage-overhead-10gib-per-node [IN] OBSERVATION

OpenShift Virtualization installation requires approximately 10 GiB storage overhead per node.

ocpvirt-svvp-certified-rhcos-intel-amd [IN] OBSERVATION

OpenShift Virtualization is SVVP-certified for Windows Server workloads on RHCOS workers with Intel/AMD CPUs only.

ocpvirt-tested-limits [IN] OBSERVATION

OpenShift Virtualization tested maximums: 216 vCPUs per VM, 6 TB RAM per VM, 500 hosts per cluster, 10,000 defined VMs per cluster.

ocpvirt-tls-rotation-cadence [IN] OBSERVATION

TLS certificate rotation cadence: KubeVirt rotates daily, CDI every 15 days, MAC pool yearly — all automatic with no disruption.

ocpvirt-udn-namespace-label-required [IN] OBSERVATION

Namespaces using a primary User-Defined Network must have the label k8s.ovn.org/primary-user-defined-network.

ocpvirt-virtctl-ssh-explicit-prefix-required [IN] OBSERVATION

Legacy virtctl ssh syntax (type/name.namespace) is removed; must use explicit vmi/<name> or vm/<name> format.

ocpvirt-vm-disk-migration-native-no-mtc [IN] OBSERVATION

VM disk storage class migration is now native to OpenShift Virtualization (no longer requires Migration Toolkit for Containers) and supports cross-namespace bulk migration.

ocpvirt-vm-name-limit-47-chars [IN] OBSERVATION

Live migration fails if the VM name exceeds 47 characters in OpenShift Virtualization.

ocpvirt-vms-pod-network-default [IN] OBSERVATION

VMs connect to the pod network by default; secondary networks (Linux bridge, OVN-Kubernetes, SR-IOV) require explicit configuration.

ocpvirt-vtpm-no-snapshot-clone [IN] OBSERVATION

VMs with vTPM devices cannot be cloned or created from snapshots.

ocpvirt-windows-odf-dedicated-storageclass [IN] OBSERVATION

Windows VMs on OpenShift Data Foundation require a dedicated storage class, with Ceph RBD preferred over CephFS.

ocpvirt-windows-vm-manual-mtu-config [IN] OBSERVATION

Windows VMs require manual MTU configuration with netsh because the Windows DHCP client does not read MTU options.

ocpvirt-worker-nodes-require-rhcos [IN] OBSERVATION

OpenShift Virtualization worker nodes must run Red Hat Enterprise Linux CoreOS (RHCOS); RHEL worker nodes are not supported.

oda-distinct-from-oci [IN] OBSERVATION

Oracle Database Appliance (ODA) is a distinct installation target from Oracle Cloud Infrastructure (OCI) in OpenShift documentation.

odf-dr-metro-regional-stretch-ga-420 [IN] OBSERVATION

ODF 4.20 supports Metropolitan DR, Regional DR, and stretch cluster disaster recovery configurations, all GA.

odf-internal-and-external-modes [IN] OBSERVATION

ODF supports internal mode (storage runs on OCP nodes) and external mode (connects to external Red Hat Ceph Storage or IBM FlashSystem).

odf-multiple-storage-clusters [IN] OBSERVATION

Multiple ODF storage clusters can coexist — an external cluster can be deployed alongside an existing internal cluster.

odf-noobaa-multicloud-object-gateway [IN] OBSERVATION

The Multicloud Object Gateway (NooBaa) is the ODF component that enables hybrid and multicloud object storage resource management.

odf-provides-block-file-object-storage [IN] OBSERVATION

Red Hat OpenShift Data Foundation (ODF) provides block, file, and object storage as a software-defined storage solution for OpenShift.

odf-provides-file-block-object-storage [IN] OBSERVATION

OpenShift Data Foundation (ODF) provides agnostic persistent storage supporting file, block, and object storage for OCP.

odo-not-officially-supported-docs [IN] OBSERVATION

The odo CLI tool is no longer covered in official OpenShift documentation; it falls under Cooperative Community Support, not standard Red Hat product support.

oke-cluster-monitoring-included-uwm-excluded [IN] OBSERVATION

OKE includes cluster monitoring (Prometheus) but excludes User Workload Monitoring.

oke-excludes-developer-experience [IN] OBSERVATION

OKE excludes developer console, S2I/builder automation, OpenShift Pipelines, odo CLI, and Dev Spaces.

oke-excludes-service-mesh-serverless-logging [IN] OBSERVATION

OKE excludes Service Mesh (Istio/Kiali), Serverless (Knative/Kourier), Distributed Tracing, and Platform Logging.

oke-includes-openshift-virtualization [IN] OBSERVATION

OpenShift Kubernetes Engine (OKE) includes OpenShift Virtualization.

oke-log-forwarding-included-platform-logging-excluded [IN] OBSERVATION

OKE includes log forwarding but excludes Platform Logging (Elasticsearch/Fluentd/Kibana stack).

oke-renamed-april-2020 [IN] OBSERVATION

OpenShift Container Engine was renamed to OpenShift Kubernetes Engine in April 2020.

oke-same-binary-as-ocp [IN] OBSERVATION

OpenShift Kubernetes Engine (OKE) and OpenShift Container Platform (OCP) are the same binary download — the difference is subscription entitlement only.

olm-csv-dual-role [IN] OBSERVATION

A Cluster Service Version (CSV) contains both user-facing metadata (logo, description, version) and technical specification (RBAC rules, managed/dependent CRs) required by OLM to run an Operator.

olm-default-catalogsources-namespace [IN] OBSERVATION

Default CatalogSources (redhat-operators, certified-operators, community-operators) live in the openshift-marketplace namespace

olm-dependency-resolution-via-crd-api [IN] OBSERVATION

OLM resolves Operator dependencies by finding Operators in a catalog that satisfy required CRD APIs, not through direct package or bundle references.

olm-deployed-by-default-ocp [IN] OBSERVATION

Operator Lifecycle Manager (OLM) is deployed by default in OpenShift Container Platform.

olm-deployed-by-default-ocp417 [IN] OBSERVATION

OLM (Operator Lifecycle Manager) is deployed by default in OpenShift Container Platform 4.17 and manages Operator installation, upgrades, and RBAC.

olm-deprecations-schema [IN] OBSERVATION

The olm.deprecations schema in file-based catalogs allows deprecating entire packages, channels, or specific bundles with custom messages.

olm-full-lifecycle-chain [IN] DERIVED

OLM operator installation follows a deterministic chain: CatalogSource → Subscription → InstallPlan → CSV → Operator Deployment, where Subscriptions track channels and InstallPlans require explicit approval fields.

olm-included-since-ocp-4-0 [IN] OBSERVATION

OLM (Operator Lifecycle Manager) has been included with OpenShift Container Platform since the initial OCP 4.0 release.

olm-index-image-managed-with-opm [IN] OBSERVATION

Index images (containing Operator bundle database snapshots with CSVs, CRDs, all versions) are managed with the opm CLI tool.

olm-install-chain [IN] OBSERVATION

OLM operator installation lifecycle chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion.

olm-install-plan-calculated-resource-list [IN] OBSERVATION

An install plan is a calculated list of resources to be created for automatic CSV installation or upgrade.

olm-operator-group-watch-scope [IN] OBSERVATION

An Operator group configures all Operators in a namespace to watch for custom resources in a list of namespaces or cluster-wide.

olm-original-included-since-ocp-40 [IN] OBSERVATION

The original Operator Lifecycle Manager (OLM) has been included in OpenShift Container Platform since the 4.0 initial release.

olm-resource-chain [IN] OBSERVATION

OLM operator installation lifecycle follows: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion → OperatorGroup.

olm-subscription-tracks-channel [IN] OBSERVATION

A Subscription keeps CSVs up to date by tracking a channel in a package.

olm-supports-disconnected-environments [IN] OBSERVATION

OLM supports disconnected/restricted network environments for Operator installation and management.

olm-transitioning-between-generations [IN] DERIVED

OLM is in active generational transition: v1 (CatalogSource→Subscription→InstallPlan→CSV chain) is production GA with FBC catalogs, while v1 extension (ClusterExtension replacing Subscription+OperatorGroup) is emerging — operators must navigate both the established lifecycle chain and its incoming replacement.

olm-v1-api-renamed-from-operator-in-416 [IN] OBSERVATION

The OLM v1 API was renamed from Operator to ClusterExtension in OCP 4.16.

olm-v1-cannot-auth-private-registries [IN] OBSERVATION

OLM v1 cannot authenticate to private registries including Red Hat-provided catalogs (known issue OCPBUGS-36364)

olm-v1-catalogd-namespace [IN] OBSERVATION

The OLM v1 catalog server runs in the openshift-catalogd namespace.

olm-v1-clusterextension-api-version [IN] OBSERVATION

The ClusterExtension custom resource uses apiVersion olm.operatorframework.io/v1alpha1.

olm-v1-clusterextension-cluster-scoped [IN] OBSERVATION

ClusterExtension objects in OLM v1 are cluster-scoped, unlike original OLM where Operators could be namespace- or cluster-scoped.

olm-v1-extension-requirements [IN] OBSERVATION

Extensions supported by OLM v1 must use registry+v1 bundle format, support AllNamespaces install mode, must not use webhooks, and must not declare dependencies via olm.gvk.required, olm.package.required, or olm.constraint.

olm-v1-extensions-superset-of-operators [IN] OBSERVATION

In OLM v1 terminology, "extensions" is the broader category that generalizes beyond just Operators; Operators are one type of extension.

olm-v1-https-catalog-communication [IN] OBSERVATION

OLM v1 uses HTTPS encryption for catalogd server responses.

olm-v1-no-builtin-install-permissions [IN] OBSERVATION

OLM v1 does not have built-in permissions to install extensions; a ServiceAccount with explicit RBAC (ServiceAccount + ClusterRole + ClusterRoleBinding) must be created before installation.

olm-v1-no-etcd-bundle-size-limit [IN] OBSERVATION

OLM v1 removes the etcd value size limit constraint on bundle size that existed in original OLM.

olm-v1-ocp-421 [IN] OBSERVATION

OCP 4.21 uses OLM v1 (Operator Lifecycle Manager v1) for extension management, replacing the classic OLM (v0) with new APIs and workflows.

olm-v1-rebranded-extensions-ocp-417 [IN] OBSERVATION

OLM v1 documentation is referred to as "Extensions" in the reorganized documentation starting in OCP 4.17.

olm-v1-single-ownership-principle [IN] OBSERVATION

In OLM v1, each Kubernetes object can only be owned by one ClusterExtension at a time; CRD-providing bundles can only be installed once per cluster

olm-v1-tech-preview-in-417 [IN] OBSERVATION

OLM v1 (Operator Lifecycle Manager v1) is Technology Preview in OpenShift 4.17 — not GA.

olm-v1-tech-preview-ocp-417 [IN] OBSERVATION

OLM v1 is a Technology Preview feature in OpenShift Container Platform 4.17, not supported under production SLAs

olm-v1-two-components [IN] OBSERVATION

OLM v1 is composed of two main components: Operator Controller (installs/manages Operators) and Catalogd (unpacks file-based catalog content from container images)

olm-v1-two-core-components [IN] OBSERVATION

OLM v1 has two core components: Operator Controller (provides the ClusterExtension API) and catalogd (provides the Catalog API and unpacks catalog content).

olm-v1-upgrade-constraint-policy-selfcertified [IN] OBSERVATION

Setting upgradeConstraintPolicy: SelfCertified in a ClusterExtension CR bypasses upgrade path constraints in OLM v1.

olmconfig-cluster-scoped-singleton [IN] OBSERVATION

OLMConfig is a cluster-scoped singleton resource in operators.coreos.com/v1 that configures OLM behavior globally.

olmconfig-disable-copied-csvs [IN] OBSERVATION

OLMConfig spec.features.disableCopiedCSVs disables the Copied CSV feature for cluster-scoped operators (OperatorGroup targeting all namespaces); re-enabling causes OLM to recreate them.

olmconfig-packageserver-sync-interval-units [IN] OBSERVATION

OLMConfig spec.features.packageServerSyncInterval controls packageserver CatalogSource polling frequency and only accepts h, m, s duration units.

on-cluster-containerfile-from-configs [IN] OBSERVATION

On-cluster layering Containerfiles use FROM configs AS final as the base stage; out-of-cluster Containerfiles use the full RHCOS image reference.

on-cluster-layering-push-pull-secret-different [IN] OBSERVATION

For on-cluster image layering builds, the push secret and pull secret must be different secrets.

on-cluster-layering-tech-preview [IN] OBSERVATION

On-cluster RHCOS image layering is Technology Preview and requires the TechPreviewNoUpgrade feature gate to be enabled.

one-operatorgroup-per-namespace [IN] OBSERVATION

Only one OperatorGroup is allowed per namespace — this is a hard constraint enforced by OLM.

one-primary-multiple-secondary-networks [IN] OBSERVATION

Only one primary network can be created per pod; multiple secondary networks are allowed.

only-ovn-kubernetes-supports-mtu-change [IN] OBSERVATION

Only the OVN-Kubernetes network plugin supports changing the MTU value on an existing OpenShift cluster.

only-ovn-kubernetes-supports-post-install-mtu-change [IN] OBSERVATION

Only OVN-Kubernetes supports changing the cluster network MTU post-installation; OpenShift SDN does not.

oom-kills-use-crio-metric [IN] OBSERVATION

OOM kill tracking in the Node Metrics Dashboard uses the CRI-O specific counter containerruntimecriocontainersoomcounttotal.

opc-tech-preview-only [IN] OBSERVATION

The opc binary included in the tkn package is a Technology Preview feature and not supported for production use.

open-service-broker-api-provisions-services [IN] OBSERVATION

The Open Service Broker API is the mechanism for provisioning and binding to external managed services (databases, message queues, etc.) within OCP.

openshift-ai-cloud-service-runs-on-osd-or-rosa [IN] OBSERVATION

OpenShift AI Cloud Service installs on OpenShift Dedicated or ROSA — not on self-managed OCP.

openshift-ai-feature-store-tech-preview [IN] OBSERVATION

OpenShift AI Feature Store is a Technology Preview feature, not GA.

openshift-ai-integrates-s3-compatible-storage [IN] OBSERVATION

OpenShift AI uses S3-compatible object stores as the primary data storage integration pattern.

openshift-ai-plus-ocp-ai-platform [IN] OBSERVATION

Red Hat OpenShift AI combined with OpenShift Container Platform forms the enterprise AI application platform.

openshift-ai-three-user-roles [IN] OBSERVATION

OpenShift AI defines three distinct user roles: OpenShift cluster administrators, OpenShift AI administrators, and OpenShift AI users (ML Ops Engineers / Data Scientists).

openshift-api-docs-organized-by-category [IN] OBSERVATION

OpenShift organizes its API reference documentation by functional category, with Metadata being one of the primary categories

openshift-api-mgmt-managed-service-on-3scale [IN] OBSERVATION

Red Hat OpenShift API Management is a managed service add-on built on 3scale API Management, running on managed OpenShift offerings (ROSA/OSD).

openshift-api-mgmt-not-self-installed [IN] OBSERVATION

OpenShift API Management is a managed service, not a self-installed operator — distinct from self-managed 3scale.

openshift-apis-organized-by-category [IN] OBSERVATION

OpenShift organizes its APIs into categories including Workloads, Networking, Storage, Security, Config, Metadata, and Operator APIs

openshift-apiserver-separate-from-kube-apiserver [IN] OBSERVATION

The OpenShift API Server handles OpenShift-specific APIs (Routes, DeploymentConfigs, Builds) and is separate from the Kubernetes API Server which handles core Kubernetes resources

openshift-builtin-oauth-server [IN] OBSERVATION

OpenShift has a built-in OAuth server managed by the Authentication operator; this is a key differentiator from vanilla Kubernetes.

openshift-cloud-services-rosa-aro [IN] OBSERVATION

OpenShift cloud services (managed) editions include ROSA (Red Hat OpenShift Service on AWS) and ARO (Microsoft Azure Red Hat OpenShift).

openshift-controller-manager-separate-from-kube-cm [IN] OBSERVATION

The openshift-controller-manager is separate from kube-controller-manager and handles OpenShift-specific controllers for builds, deployments, images, and service accounts

openshift-extends-k8s-authorization-model [IN] DERIVED

OpenShift has dual authorization systems: its own authorization API group alongside the Kubernetes RBAC API, with OpenShift-specific resources (SCC, ClusterRoles like self-provisioner) layered on top.

openshift-extends-kubernetes-api [IN] OBSERVATION

OpenShift extends the Kubernetes API with platform-specific Extension API resources such as Route, BuildConfig, DeploymentConfig, ImageStream, Project, ClusterVersion, and MachineSet

openshift-extension-apis-beyond-kubernetes [IN] OBSERVATION

OpenShift extends the Kubernetes API with its own extension API objects including Route, DeploymentConfig, BuildConfig, ImageStream, Project, and SecurityContextConstraints.

openshift-gitops-is-argocd-distribution [IN] OBSERVATION

OpenShift GitOps is Red Hat's supported distribution of Argo CD.

openshift-gitops-uses-argocd [IN] OBSERVATION

OpenShift GitOps is an Operator that uses Argo CD as its declarative GitOps engine, enabling GitOps workflows across multicluster OpenShift and Kubernetes infrastructure.

openshift-gitops-wraps-argocd [IN] OBSERVATION

OpenShift GitOps is an Operator (installed via OLM/OperatorHub) that wraps Argo CD as its declarative GitOps engine for continuous deployment.

openshift-has-own-authorization-api [IN] OBSERVATION

OpenShift has its own Authorization API (com.github.openshift.api.authorization.v1) with Role, ClusterRole, RoleBinding, and ClusterRoleBinding alongside the Kubernetes RBAC equivalents (io.k8s.api.rbac.v1).

openshift-has-own-authorization-api-group [IN] OBSERVATION

OpenShift has its own authorization API group (authorization.openshift.io) in addition to Kubernetes-native RBAC (rbac.authorization.k8s.io)

openshift-identity-lifecycle-chain [IN] DERIVED

OpenShift identity management operates as a chain: OAuth config (singleton, requires IntegratedOAuth) → identity providers → User objects (user.openshift.io) → UserIdentityMapping → Identity, with session revocation via OAuthClientAuthorization deletion.

openshift-ingress-translates-to-routes [IN] OBSERVATION

In OpenShift, the ingress controller typically translates Kubernetes Ingress objects into Route objects

openshift-install-destroy-requires-metadata [IN] OBSERVATION

The openshift-install destroy cluster command requires the original installation directory containing metadata.json and the same installer version used to create the cluster.

openshift-mtu-change-post-install [IN] OBSERVATION

OpenShift supports changing MTU (Maximum Transmission Unit) settings post-installation.

openshift-pipelines-based-on-tekton [IN] OBSERVATION

OpenShift Pipelines is a Kubernetes-native CI/CD framework based on Tekton where each pipeline step runs in its own container.

openshift-pipelines-installed-via-operator [IN] OBSERVATION

OpenShift Pipelines is typically installed via the OpenShift Pipelines Operator from OperatorHub.

openshift-pipelines-kubernetes-native-crds [IN] OBSERVATION

OpenShift Pipelines defines pipelines as Kubernetes custom resources (CRDs), not as external server configurations, making them portable across Kubernetes clusters.

openshift-pipelines-separate-release-cadence [IN] OBSERVATION

OpenShift Pipelines releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.

openshift-pipelines-serverless-ephemeral [IN] OBSERVATION

OpenShift Pipelines is serverless in nature — pipeline runs are ephemeral and do not require a persistent CI server.

openshift-pipelines-serverless-no-central-controller [IN] OBSERVATION

OpenShift Pipelines is serverless and distributed with no central controller dependency, unlike Jenkins which requires a central controller node.

openshift-pipelines-tekton-replaces-jenkins [IN] OBSERVATION

OpenShift Pipelines (Tekton) is the strategic replacement for Jenkins as the CI/CD engine in OpenShift Container Platform.

openshift-pipelines-tekton-strategic-cicd [IN] OBSERVATION

OpenShift Pipelines (Tekton-based) is the strategic CI/CD solution replacing Jenkins in OpenShift Container Platform.

openshift-pipelines-uses-kubernetes-crds [IN] OBSERVATION

OpenShift Pipelines uses Kubernetes custom resources (Tasks, Pipelines, PipelineRuns, Triggers) as its primitives.

openshift-project-wraps-namespace [IN] OBSERVATION

In OpenShift, Projects wrap Namespaces with additional annotations and RBAC; every Project creates a corresponding Namespace

openshift-ptp-hardware-support [IN] OBSERVATION

OpenShift provides PTP (Precision Time Protocol) hardware support for high-accuracy time synchronization use cases.

openshift-sdn-deprecated [IN] OBSERVATION

OpenShift SDN is deprecated; migration to OVN-Kubernetes is expected.

openshift-self-managed-ocp-platform-plus [IN] OBSERVATION

OpenShift self-managed editions include OpenShift Container Platform (OCP) and OpenShift Platform Plus, which bundles OCP with ACS, ACM, and Quay.

openshift-serverless-based-on-knative [IN] OBSERVATION

OpenShift Serverless is the Red Hat-supported distribution of Knative on OpenShift Container Platform.

openshift-specific-api-groups [IN] OBSERVATION

build.openshift.io/v1 and apps.openshift.io/v1 are OpenShift-specific API groups; apps/v1 and batch/v1 are standard Kubernetes.

openshift-supports-sctp-protocol [IN] OBSERVATION

OpenShift supports SCTP (Stream Control Transmission Protocol) as a transport protocol beyond TCP/UDP, relevant for telecom workloads.

openshift-uses-metal3-ironic-for-bare-metal [IN] OBSERVATION

OpenShift uses Metal3 (Metal³) and Ironic for bare-metal provisioning; the provisioning service (Ironic) is deployed automatically during bare-metal IPI installations

openshift-virt-engine-separate-edition [IN] OBSERVATION

OpenShift Virtualization Engine is a separate, standalone edition of Red Hat OpenShift purpose-built for virtualization workloads — distinct from the OpenShift Virtualization operator/feature within full OCP.

openshift-virt-supported-vm-maximums-per-node [IN] OBSERVATION

OpenShift Virtualization has defined supported maximum numbers of VMs per node, documented as part of tuning and scaling guidance.

openshift-virt-versions-track-ocp [IN] OBSERVATION

OpenShift Virtualization version numbers align with OpenShift Container Platform version numbers (e.g., OCP 4.21 = OpenShift Virtualization 4.21).

openshift-virtualization-is-ocp-feature [IN] OBSERVATION

OpenShift Virtualization is a feature within OpenShift Container Platform that enables creating, deploying, and managing virtual machines alongside containers.

openstack-supported-ocp-install-platform [IN] OBSERVATION

Red Hat OpenStack Platform (RHOSP) is a supported installation platform for OpenShift Container Platform.

openstack-supports-ipi-and-upi [IN] OBSERVATION

OCP supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods on OpenStack.

opentelemetry-separate-operator [IN] OBSERVATION

Red Hat build of OpenTelemetry is a separate Operator from the cluster monitoring stack and the distributed tracing platform Operator, installed via OperatorHub.

opentelemetry-three-signal-types [IN] OBSERVATION

Red Hat build of OpenTelemetry collects three signal types: traces, metrics, and logs.

opentelemetry-vendor-neutral-standard [IN] OBSERVATION

OpenTelemetry is the vendor-neutral, open standard for telemetry collection in OpenShift, not tied to a specific observability backend.

operator-apis-backed-by-crds [IN] OBSERVATION

Each OpenShift Operator API is backed by a CustomResourceDefinition (CRD).

operator-apis-distinct-from-config-apis [IN] OBSERVATION

OpenShift distinguishes Operator APIs from Config APIs, Machine APIs, and core Kubernetes APIs in its documentation taxonomy.

operator-apis-implemented-as-crds [IN] OBSERVATION

OpenShift Operator APIs are implemented as CustomResourceDefinitions (CRDs) registered in the cluster, distinct from core Kubernetes APIs.

operator-bundle-exactly-one-csv [IN] OBSERVATION

Each Operator bundle must contain exactly one Cluster Service Version (CSV) and belong to at least one channel.

operator-catalog-to-deployment-pipeline [IN] DERIVED

Operator delivery follows an end-to-end pipeline: FBC catalogs (replacing SQLite) feed into the OLM lifecycle chain (CatalogSource → Subscription → InstallPlan → CSV → Deployment), creating a fully declarative operator supply chain.

operator-configs-singleton-named-cluster [IN] OBSERVATION

Most operator.openshift.io/v1 configuration resources are singleton objects named "cluster"

operator-delivery-through-console-integration [IN] DERIVED

Operators follow a complete delivery pipeline from catalog to UI: FBC catalogs feed through OLM lifecycle (CatalogSource → Subscription → InstallPlan → CSV → Deployment), and then extend the web console via HTTPS-backed ConsolePlugins registered through OLM, making OLM the single delivery mechanism for both backend and frontend operator components.

operator-dependency-types [IN] OBSERVATION

OLM supports three Operator dependency types: olm.package (version-based), olm.gvk (API group/version/kind), and olm.constraint (generic constraints).

operator-driven-immutable-platform-model [IN] DERIVED

The entire OpenShift platform operates through an operator-driven model: operators are delivered via the FBC→OLM→Console pipeline and then manage immutable nodes through singleton CRs, creating a closed loop where the delivery mechanism and the management mechanism are both operator-mediated.

operator-framework-four-components [IN] OBSERVATION

The Operator Framework consists of four components: Operator SDK, Operator Lifecycle Manager (OLM), Operator Registry, and OperatorHub.

operator-install-chain [IN] OBSERVATION

The Operator install chain is: OperatorHub → PackageManifest → Subscription → InstallPlan → CSV.

operator-lifecycle-bounded-by-platform-constraints [IN] DERIVED

The operator-driven immutable platform model must operate within hard lifecycle boundaries: operators deliver and manage everything, but install-time irreversible decisions and version-coupling constraints define the envelope within which operators can act — creating a tension between operator-mediated flexibility and platform-level rigidity.

operator-lifecycle-classifications-since-414 [IN] OBSERVATION

Operator lifecycle classifications (Platform Aligned, Platform Agnostic, Rolling Stream) were introduced in OCP 4.14.

operator-log-level-separate-from-operand [IN] OBSERVATION

OpenShift operator resources have two separate log level controls: logLevel for the operand and operatorLogLevel for the operator itself

operator-log-levels-four-values [IN] OBSERVATION

Valid log levels across OpenShift operators are: Normal, Debug, Trace, and TraceAll (default is Normal).

operator-log-levels-normal-debug-trace-traceall [IN] OBSERVATION

OpenShift operator CRs accept log level values Normal, Debug, Trace, and TraceAll for both logLevel (operand) and operatorLogLevel (operator).

operator-loglevel-vs-operatorloglevel [IN] OBSERVATION

logLevel controls logging for the operand while operatorLogLevel controls logging for the operator process itself

operator-management-state-three-values [IN] OBSERVATION

The managementState field on OpenShift operators supports three values: Managed (actively reconciles), Unmanaged (stops reconciling), and Removed (deletes managed resources).

operator-manager-default-watches-own-namespace [IN] OBSERVATION

The Operator Manager default behavior watches only the namespace where the Operator runs; set Namespace: "" to watch all namespaces.

operator-maturity-model-five-levels [IN] OBSERVATION

The Operator maturity model defines five phases: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot.

operator-observed-config-lives-in-spec [IN] OBSERVATION

The observedConfig field lives in .spec (not .status) because it serves as input to the operator's reconciliation logic.

operator-pattern-replicates-across-platforms [IN] DERIVED

The operator-driven immutable platform model is not unique to OCP — RHOSO replicates the same pattern (master operator orchestrating sub-operators, CRD-based configuration, running on OCP as substrate), demonstrating that the operator model is a reusable platform architecture, not an OCP-specific design.

operator-pki-cert-rotation [IN] OBSERVATION

OperatorPKI CA cert validity is 10 years (rotated after 9 years); target cert validity is 6 months (rotated after 3 months)

operator-sdk-ansible-helm-base-images-not-deprecated [IN] OBSERVATION

Base images for Ansible-based and Helm-based Operator projects are not deprecated and remain supported for bug fixes and CVEs, even though the Operator SDK CLI itself is deprecated.

operator-sdk-deprecated-ocp-417 [IN] OBSERVATION

The Red Hat-supported Operator SDK CLI is deprecated in OpenShift Container Platform 4.17 and planned for removal in a future release.

operator-sdk-deprecated-ocp417 [IN] OBSERVATION

The Red Hat-supported Operator SDK CLI is deprecated as of OpenShift Container Platform 4.17 and planned for removal in a future release.

operator-sdk-embeds-kubebuilder [IN] OBSERVATION

Kubebuilder is embedded into the Operator SDK as the scaffolding solution for Go-based Operators; existing Kubebuilder projects work as-is.

operator-sdk-init-go-plugin-default [IN] OBSERVATION

The operator-sdk init command uses the Go plugin by default.

operator-sdk-make-bundle-shortcut [IN] OBSERVATION

Running make bundle automates executing operator-sdk generate kustomize manifests followed by operator-sdk generate bundle.

operator-sdk-official-build-tool [IN] OBSERVATION

The Operator SDK is the official tool for building custom Operators in OpenShift.

operator-sdk-part-of-operator-framework [IN] OBSERVATION

The Operator SDK is a component of the Operator Framework, used to build, test, and deploy Operators.

operator-sdk-repo-flag-required-outside-gopath [IN] OBSERVATION

The --repo flag is required when creating an Operator SDK project outside $GOPATH/src/.

operator-sdk-restricted-security-context-not-default-ns [IN] OBSERVATION

The --security-context-config restricted flag for operator-sdk run bundle is not compatible with the default namespace.

operator-sdk-scorecard-default-config-path [IN] OBSERVATION

The default scorecard configuration path is bundle/tests/scorecard/config.yaml.

operator-sdk-supported-types [IN] OBSERVATION

The Operator SDK supports building Operators based on Go, Ansible, Helm, or Java.

operator-sdk-supports-four-languages [IN] OBSERVATION

The Operator SDK supports four project types: Go, Ansible, Helm, and Java.

operator-sdk-three-types [IN] OBSERVATION

Operator SDK supports three Operator types: Helm (lower maturity), Ansible, and Go (enables highest maturity level).

operator-sdk-version-ocp-417 [IN] OBSERVATION

OpenShift Container Platform 4.17 supports Operator SDK v1.36.1.

operator-sdk-version-ocp417 [IN] OBSERVATION

OpenShift Container Platform 4.17 ships Operator SDK v1.36.1.

operatorcondition-upgradeable-false-blocks [IN] OBSERVATION

An OperatorCondition with Upgradeable=False blocks OLM from upgrading that Operator

operatorgroup-api-group-v1 [IN] OBSERVATION

The OperatorGroup resource uses API group operators.coreos.com/v1

operatorgroup-default-upgrade-strategy-blocks-failed [IN] OBSERVATION

OperatorGroup Default upgrade strategy blocks operator upgrades when a prior install/upgrade has failed (CSVs can only move to Replacing from Succeeded)

operatorgroup-failforward-techpreview-unsafe [IN] OBSERVATION

OperatorGroup TechPreviewUnsafeFailForward upgrade strategy allows CSVs to move to Replacing from Succeeded or Failed, and triggers new InstallPlan generation on catalog updates

operatorgroup-namespace-scopes [IN] OBSERVATION

OperatorGroups control which namespaces an Operator can watch, with options: AllNamespaces, OwnNamespace, or a specific set of namespaces.

operatorgroup-one-per-namespace [IN] OBSERVATION

Only one OperatorGroup should exist per namespace; multiple OperatorGroups cause conflicts

operatorgroup-serviceaccountname-deploy-identity [IN] OBSERVATION

OperatorGroup serviceAccountName specifies the service account used to deploy operators within the group, enabling least-privilege configurations

operatorgroup-targetnamespaces-overrides-selector [IN] OBSERVATION

In an OperatorGroup, targetNamespaces takes precedence over selector; if both are set, the selector is ignored

operatorgroup-unit-of-multitenancy [IN] OBSERVATION

OperatorGroup is the unit of multitenancy for OLM-managed operators, constraining which namespaces an operator can watch and manage

operatorhub-apis-group-operators-coreos [IN] OBSERVATION

OperatorHub API objects (CatalogSource, Subscription, InstallPlan, CSV, OperatorGroup, OperatorCondition) are CRDs under the operators.coreos.com API group, managed by OLM.

operatorhub-apis-namespace-coreos [IN] OBSERVATION

OperatorHub API resources are in the operators.coreos.com API group, discoverable via oc api-resources | grep operators.coreos.com.

operatorhub-available-every-ocp4-cluster [IN] OBSERVATION

OperatorHub is available in every OpenShift Container Platform 4.x cluster.

operatorhub-controls-default-sources-only [IN] OBSERVATION

OperatorHub config controls default catalog sources only; custom CatalogSource resources are managed separately and are not affected

operatorhub-default-catalogsources [IN] OBSERVATION

The default CatalogSources in the openshift-marketplace namespace are: redhat-operators, certified-operators, community-operators, and redhat-marketplace.

operatorhub-deployed-by-default-ocp417 [IN] OBSERVATION

OperatorHub is deployed by default in OpenShift Container Platform 4.17 for Operator discovery via the web console.

operatorhub-disable-all-disconnected [IN] OBSERVATION

Setting disableAllDefaultSources: true on OperatorHub is a required step for disconnected/air-gapped installations

operatorhub-install-pipeline-order [IN] OBSERVATION

The Operator installation pipeline follows the chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion (CSV).

operatorhub-singleton-named-cluster [IN] OBSERVATION

The OperatorHub resource (config.openshift.io/v1) is a cluster-scoped singleton named cluster that controls default hub catalog sources

operatorhub-sources-override-disableall [IN] OBSERVATION

When disableAllDefaultSources is true, individual spec.sources[] entries can selectively re-enable specific default catalog sources

operatorpki-api-group [IN] OBSERVATION

OperatorPKI is a custom resource in the network.operator.openshift.io/v1 API group, managed exclusively by the Cluster Network Operator (CNO) for internal PKI needs

operatorpki-ca-validity-10-years [IN] OBSERVATION

OperatorPKI CA certificate validity is 10 years, rotated after 9 years

operatorpki-creates-three-resources [IN] OBSERVATION

The CNO creates three resources per OperatorPKI named <name>: Secret <name>-ca, ConfigMap <name>-ca, and Secret <name>-cert

operatorpki-required-field-commonname [IN] OBSERVATION

The only required spec field for OperatorPKI is spec.targetCert.commonName

operatorpki-target-cert-extended-key-usages [IN] OBSERVATION

OperatorPKI target certificates have both ClientAuth and ServerAuth extended key usages enabled

operatorpki-target-cert-validity-6-months [IN] OBSERVATION

OperatorPKI target certificate validity is 6 months, rotated after 3 months

operators-and-updates-share-security-constraint-hierarchy [IN] DERIVED

Operators and cluster updates are constrained by the same security hierarchy: install-time locks (FIPS, CPU partitioning) permanently bound both the operator runtime environment and the update path, runtime TLS/IPsec enforcement governs both operator and update traffic, and API governance controls both operator CRD stability and update version ordering

operators-control-loop-pattern [IN] OBSERVATION

Kubernetes Operators use the control loop pattern: they continuously compare desired state vs. actual state and act to reconcile differences. They manage applications using custom resources.

operators-day1-day2 [IN] OBSERVATION

Operators automate both Day 1 operations (installation and configuration) and Day 2 operations (autoscaling, backups, ongoing maintenance).

operators-subset-of-extensions-olm-v1 [IN] OBSERVATION

In OLM v1, Operators are framed as a subset of the broader category "extensions", and OLM v1 introduces different CRDs replacing classic OLM concepts like Subscriptions and CSVs.

operators-three-roles [IN] OBSERVATION

Operators documentation addresses three distinct roles: cluster administrators (install/manage), developers (consume), and Operator authors (build with Operator SDK).

opm-cli-for-operator-catalogs [IN] OBSERVATION

The opm CLI is used to create and maintain Operator catalogs, distinct from the Operator SDK which builds/tests/deploys Operators.

opm-file-based-catalog-default-since-411 [IN] OBSERVATION

File-based catalog (FBC) is the default Operator catalog format since OpenShift Container Platform 4.11, replacing the deprecated SQLite-based format.

opm-index-add-graph-update-modes [IN] OBSERVATION

The opm index add --mode flag supports graph update modes: replaces (default), semver, and semver-skippatch.

opm-index-subcommands-sqlite-only [IN] OBSERVATION

The opm index subcommands (add, prune, prune-stranded, rm) work only with SQLite-based catalogs and do not work with file-based catalogs.

opm-migrate-sqlite-to-fbc [IN] OBSERVATION

The opm migrate command converts a SQLite-based catalog index to file-based catalog format.

opm-not-forward-compatible [IN] OBSERVATION

The opm CLI is not forward compatible — the version used to generate catalog content must be less than or equal to the version used to serve it.

opm-render-converts-to-fbc [IN] OBSERVATION

opm render <image-reference> converts an existing catalog image into file-based catalog format

opm-serve-default-port-50051 [IN] OBSERVATION

The opm serve command serves declarative configs via gRPC on default port 50051.

opm-serve-loads-config-at-startup-only [IN] OBSERVATION

The opm serve command loads configuration at startup only; runtime changes to the declarative config are not reflected.

opm-validate-checks-catalog [IN] OBSERVATION

opm validate <catalog-directory> checks catalog validity including duplicate detection and schema violations

opm-validate-command [IN] OBSERVATION

The opm validate <catalog-dir> command validates a file-based Operator catalog.

optional-cluster-capabilities [IN] OBSERVATION

Optional cluster capabilities that can be disabled at install time include: Baremetal, CSI Snapshot Controller, Cluster Samples, Cluster Storage, Console, and Insights.

oracle-database-appliance-supported-platform [IN] OBSERVATION

Oracle Database Appliance (ODA) is a supported installation platform for OCP as of version 4.21.

oracle-dci-definition [IN] OBSERVATION

Oracle Distributed Cloud Infrastructure refers to Oracle's cloud services deployed outside of Oracle's public cloud regions (e.g., at customer data centers or edge locations).

oracle-distributed-cloud-supported-platform [IN] OBSERVATION

Oracle Distributed Cloud Infrastructure (DCI) is a supported installation target for OCP, distinct from standard Oracle Cloud Infrastructure (OCI).

oracle-edge-cloud-supported-platform [IN] OBSERVATION

Oracle Edge Cloud is a supported installation platform for OCP 4.21, distinct from Oracle Cloud Infrastructure (OCI).

osd-ci-cd-ecosystem [IN] OBSERVATION

OpenShift Dedicated supports Tekton Pipelines, Shipwright builds, BuildConfig (legacy), GitOps (Argo CD), and Jenkins for CI/CD.

osd-provisioned-via-openshift-cluster-manager [IN] OBSERVATION

OpenShift Dedicated clusters are provisioned and configured through OpenShift Cluster Manager (OCM), not directly via openshift-install.

osd-runs-on-aws-and-gcp-only [IN] OBSERVATION

OpenShift Dedicated (OSD) runs on AWS and Google Cloud only — no Azure or on-prem support.

osd-shared-responsibility-model [IN] OBSERVATION

OpenShift Dedicated has a shared responsibility model — Red Hat manages the control plane and infrastructure; customers manage workloads.

osd-uses-ovn-kubernetes-network-plugin [IN] OBSERVATION

OpenShift Dedicated uses OVN-Kubernetes as its network plugin (not OpenShift SDN).

out-of-service-taint-evicts-all-pods [IN] OBSERVATION

Applying the out-of-service taint evicts all pods from the node (not just those using volumes) and must be removed after the node restarts.

out-of-service-taint-key [IN] OBSERVATION

The out-of-service taint for non-graceful node shutdown is node.kubernetes.io/out-of-service=nodeshutdown:NoExecute.

out-of-service-taint-manual [IN] OBSERVATION

The out-of-service taint must be manually applied by a cluster-admin; it is not automatic, and must only be applied after confirming the node is fully shut down.

out-of-service-taint-running-node-corruption [IN] OBSERVATION

Applying the out-of-service taint to a node that is still running risks filesystem corruption.

ove-ansible-full-vm-lifecycle [IN] OBSERVATION

Red Hat Ansible Automation Platform manages the full VM lifecycle on OpenShift Virtualization Engine: provisioning, patching, configuration enforcement, and migration.

ove-installed-via-assisted-installer [IN] OBSERVATION

OpenShift Virtualization Engine is installed via the Assisted Installer for OpenShift Container Platform.

ove-migration-sources-vsphere-and-rhv [IN] OBSERVATION

OpenShift Virtualization Engine supports migration from VMware vSphere and Red Hat Virtualization (RHV) via the Migration Toolkit for Virtualization.

ove-rhacm-multi-cluster-management [IN] OBSERVATION

Red Hat Advanced Cluster Management (RHACM) provides single-console multi-cluster management with built-in security policies and compliance for OpenShift Virtualization Engine clusters.

ovn-databases-run-on-each-node [IN] OBSERVATION

All OVN databases (nbdb, sbdb) and northd run on each node (not centralized), processing mostly local information.

ovn-dual-stack-same-gateway-interface [IN] OBSERVATION

OVN-Kubernetes dual-stack limitation: both IPv4 and IPv6 must use the same default gateway interface; violation causes CrashLoopBackOff in ovnkube-node pods.

ovn-geneve-port-6081 [IN] OBSERVATION

OVN-Kubernetes uses Geneve encapsulation (not VXLAN) with default port 6081 and default MTU 1400

ovn-internal-subnets-immutable [IN] OBSERVATION

v4InternalSubnet (100.64.0.0/16), v6InternalSubnet (fd98::/48), and internalTransitSwitchSubnet cannot be changed after installation

ovn-ipv6-disable-causes-crashloop [IN] OBSERVATION

Setting ipv6.disable=1 in kernel arguments causes CrashLoopBackOff in ovnkube-node pods and blocks cluster upgrades.

ovn-k-secondary-cni-type [IN] OBSERVATION

OVN-Kubernetes secondary networks require CNI type ovn-k8s-cni-overlay with cniVersion: 0.3.1.

ovn-k-secondary-topologies [IN] OBSERVATION

OVN-Kubernetes supports three secondary network topologies: layer2 (cluster-wide logical switch, L2 only), localnet (connects workloads to physical network via OVS bridge), and layer3 (routed).

ovn-kubernetes-built-on-ovn-ovs [IN] OBSERVATION

OVN-Kubernetes is built on Open Virtual Network (OVN), which itself builds on Open vSwitch (OVS).

ovn-kubernetes-default-cni [IN] OBSERVATION

OVN-Kubernetes is the default Container Network Interface (CNI) for OpenShift Container Platform clusters.

ovn-kubernetes-default-cni-plugin [IN] OBSERVATION

OVN-Kubernetes is the default CNI network plugin in OpenShift Container Platform (replacing OpenShift SDN as default from OCP 4.12+)

ovn-kubernetes-default-network-plugin [IN] OBSERVATION

OVN-Kubernetes is the default network plugin and supports both IPv4 and IPv6.

ovn-kubernetes-default-network-plugin-417 [IN] OBSERVATION

OVN-Kubernetes is the default network plugin in OpenShift Container Platform 4.17

ovn-kubernetes-default-sdn [IN] OBSERVATION

OVN-Kubernetes is the default SDN in OpenShift Container Platform; network issues should be checked in the openshift-ovn-kubernetes namespace.

ovn-kubernetes-enforces-network-policy [IN] OBSERVATION

OVN-Kubernetes natively enforces Kubernetes NetworkPolicy and OpenShift-specific network policy objects.

ovn-kubernetes-internal-subnets-must-not-overlap [IN] OBSERVATION

OVN-Kubernetes uses six reserved internal subnets (join, masquerade, transit for IPv4 and IPv6) that must never overlap with any other CIDR in the cluster

ovn-kubernetes-join-subnet-default [IN] OBSERVATION

The default OVN-Kubernetes V4JoinSubnet is 100.64.0.0/16 and V6JoinSubnet is fd98::/64

ovn-kubernetes-multicast-low-bandwidth-only [IN] OBSERVATION

OVN-Kubernetes default network multicast is suitable only for low-bandwidth use cases (coordination, service discovery); SR-IOV is required for high-bandwidth multicast.

ovn-kubernetes-namespace [IN] OBSERVATION

OVN-Kubernetes resources run in the openshift-ovn-kubernetes namespace.

ovn-kubernetes-overhead-100-bytes [IN] OBSERVATION

OVN-Kubernetes network plugin has a 100-byte overhead, so cluster network MTU should be set to hardware MTU minus 100.

ovn-kubernetes-overlay-overhead-100-bytes [IN] OBSERVATION

OVN-Kubernetes overlay overhead is exactly 100 bytes; cluster network MTU = hardware MTU - 100.

ovn-kubernetes-owns-egress-crds [IN] OBSERVATION

OVN-Kubernetes plugin owns most egress CRDs: EgressFirewall, EgressIP, EgressQoS, EgressService, and AdminPolicyBasedExternalRoute (all k8s.ovn.org/v1)

ovn-kubernetes-primary-network-plugin [IN] OBSERVATION

OVN-Kubernetes is the primary network plugin in OpenShift 4.x (replacing OpenShift SDN in newer versions).

ovn-kubernetes-single-service-network-block [IN] OBSERVATION

OVN-Kubernetes supports only a single IP address block for the service network.

ovn-kubernetes-supports-ipsec [IN] OBSERVATION

OVN-Kubernetes supports IPsec for encrypting cluster network traffic.

ovn-kubernetes-uses-geneve [IN] OBSERVATION

OVN-Kubernetes uses the Geneve protocol (not VXLAN) to create the overlay network between nodes.

ovn-masquerade-subnet-mutable [IN] OBSERVATION

internalMasqueradeSubnet (default 169.254.169.0/29 for IPv4, fd69::/125 for IPv6) can be changed after installation and must accommodate at least 6 IPs

ovn-session-affinity-last-packet [IN] OBSERVATION

OVN-Kubernetes session affinity stickiness timeout is calculated from the last packet received, not the first — continuous traffic keeps the session alive indefinitely.

ovnkube-control-plane-deployment-2-replicas [IN] OBSERVATION

ovnkube-control-plane runs as a Deployment with 2 replicas on separate control plane nodes, using leader election.

ovnkube-node-daemonset-8-containers [IN] OBSERVATION

ovnkube-node pods run as a DaemonSet (one per node) with 8 containers: ovn-controller, ovn-acl-logging, kube-rbac-proxy-node, kube-rbac-proxy-ovn-metrics, northd, nbdb, sbdb, ovnkube-controller.

ovnkubernetes-default-network-plugin [IN] OBSERVATION

OVNKubernetes is the default network plugin (CNI) for OpenShift Container Platform, supporting Linux and hybrid Linux/Windows networks.

ovnkubernetes-default-only-cni [IN] OBSERVATION

OVNKubernetes is the default and only supported networkType in OpenShift 4.17; it supports only a single service network CIDR.

ovs-bonding-two-modes [IN] OBSERVATION

OVS bonding supports two modes: active-backup and balance-slb.

ovs-bridge-architecture-br-ex-br-phy [IN] OBSERVATION

In OVN-Kubernetes networking, br-ex receives VM traffic, patch ports connect it to br-phy, and br-phy controls the SLB bond to physical NICs.

packagemanifest-api-group [IN] OBSERVATION

PackageManifest uses API group packages.operators.coreos.com/v1

packagemanifest-defaultchannel-behavior [IN] OBSERVATION

The PackageManifest defaultChannel field determines what channel gets installed when no channel is specified in a Subscription

packagemanifest-deprecation-three-levels [IN] OBSERVATION

PackageManifest deprecation can occur at three levels: entire package, individual channel, or individual entry (CSV) within a channel

packagemanifest-entries-upgrade-paths [IN] OBSERVATION

The entries[] array in a PackageManifest channel lists all CSVs with their upgrade edges, enabling OLM to compute valid upgrade paths

packagemanifest-read-only [IN] OBSERVATION

PackageManifest is a read-only resource with no POST/PUT/DELETE endpoints; it is generated from CatalogSource content

packagemanifests-list-available-operators [IN] OBSERVATION

oc get packagemanifests -n openshift-marketplace lists available Operators from OperatorHub catalogs.

pdb-api-group-policy-v1 [IN] OBSERVATION

PodDisruptionBudget (PDB) is a policy/v1 API resource, not in the apps or core API groups.

pdb-block-all-evictions-settings [IN] OBSERVATION

Setting maxUnavailable: 0 or minAvailable: 100% on a PDB blocks all voluntary evictions.

pdb-default-maxunavailable-1 [IN] OBSERVATION

Default maxUnavailable for machine config pools is 1; it should not be changed to 3 for the control plane.

pdb-minavailable-maxunavailable-mutually-exclusive [IN] OBSERVATION

minAvailable and maxUnavailable in a PDB spec are mutually exclusive — specifying both is invalid.

pdb-minavailable-or-maxunavailable [IN] OBSERVATION

PDB spec uses either minAvailable or maxUnavailable (not both) to define disruption tolerance.

pdb-misconfiguration-blocks-updates [IN] OBSERVATION

PodDisruptionBudget misconfiguration can prevent nodes from draining during cluster updates.

pdb-namespaced-resource [IN] OBSERVATION

PodDisruptionBudgets are namespaced resources.

pdb-null-vs-empty-selector [IN] OBSERVATION

A null PDB selector matches no pods; an empty selector {} matches all pods in the namespace.

pdb-only-voluntary-disruptions [IN] OBSERVATION

PodDisruptionBudgets only protect against voluntary disruptions (drains, evictions), not involuntary ones (node crashes, OOM kills).

pdb-unhealthy-pod-eviction-default [IN] OBSERVATION

The unhealthyPodEvictionPolicy field in PDB defaults to IfHealthyBudget behavior, meaning unhealthy running pods can only be evicted if currentHealthy >= desiredHealthy.

pdb-values-intorstring [IN] OBSERVATION

PDB minAvailable and maxUnavailable fields accept either an integer or a percentage string (IntOrString type).

pdb-voluntary-disruptions-only [IN] OBSERVATION

PDBs only affect voluntary disruptions (evictions); they do not protect against involuntary disruptions like node crashes or OOM kills.

pdb-voluntary-only [IN] OBSERVATION

PodDisruptionBudgets are only honored on voluntary evictions, not involuntary disruptions like node failures.

pending-csrs-after-restart [IN] OBSERVATION

After a graceful restart, pending CSRs may need to be manually approved with oc adm certificate approve for nodes to reach Ready state.

performanceprofile-1g-hugepage-removes-2m [IN] OBSERVATION

Setting PerformanceProfile defaultHugepagesSize to 1G removes all 2M hugepage folders from the node, making 2M hugepage configuration impossible.

performanceprofile-api-group-v2 [IN] OBSERVATION

PerformanceProfile uses API group performance.openshift.io/v2 (v2, not v1).

performanceprofile-balance-isolated-default-true [IN] OBSERVATION

PerformanceProfile balanceIsolated defaults to true; setting to false disables load balancing on isolated CPUs for most predictable latency.

performanceprofile-generates-tuned-and-runtimeclass [IN] OBSERVATION

PerformanceProfile controller auto-creates a RuntimeClass (name in .status.runtimeClass) and a Tuned CR (referenced in .status.tuned).

performanceprofile-highpower-perpod-mutually-exclusive [IN] OBSERVATION

PerformanceProfile workloadHints highPowerConsumption and perPodPowerManagement cannot be enabled together (mutually exclusive).

performanceprofile-net-queue-count-equals-reserved [IN] OBSERVATION

When userLevelNetworking is enabled in a PerformanceProfile, network device queue count is set equal to the reserved CPU count.

performanceprofile-numa-topology-default-best-effort [IN] OBSERVATION

PerformanceProfile NUMA topologyPolicy defaults to best-effort when TopologyManager is enabled.

performanceprofile-required-fields [IN] OBSERVATION

PerformanceProfile requires spec.cpu (with both isolated and reserved) and spec.nodeSelector.

performanceprofile-rt-kernel-requires-explicit-enable [IN] OBSERVATION

Real-time kernel packages are not installed on OpenShift nodes unless realTimeKernel.enabled: true is explicitly set in the PerformanceProfile.

perspective-switcher-requires-cluster-admin [IN] OBSERVATION

The perspective switcher (to toggle between Administrator and Developer views) is available only to cluster-admin users

pgt-bindingrules-must-match-siteconfig-labels [IN] OBSERVATION

PGT bindingRules labels must match labels in the SiteConfig CR — a mismatch means policies won't apply to the managed cluster.

pgt-deprecated-for-policygenerator [IN] OBSERVATION

PolicyGenTemplate (PGT) is deprecated in OCP 4.17 in favor of RHACM PolicyGenerator CRs.

pgt-namespace-cr-separate-file [IN] OBSERVATION

The Namespace CR must NOT be in the same file as the PolicyGenTemplate CR.

pgt-policy-naming-convention [IN] OBSERVATION

Generated ZTP policy names follow the pattern <PGT-metadata.name>-<policyName> (e.g., group-du-sno-config-policy).

pipelines-tekton-gitops-argocd [IN] OBSERVATION

OpenShift Pipelines is Tekton-based; OpenShift GitOps is Argo CD-based.

pipelines-vs-builds-distinction [IN] OBSERVATION

OpenShift Pipelines orchestrates multi-step CI/CD workflows, while OpenShift Builds focuses on container image creation — they are related but distinct.

platform-delivers-software-under-governance-across-topologies [IN] DERIVED

OpenShift unifies software delivery and platform governance across all topology variants: the same operator-driven pipeline (FBC→OLM→Console) and identity-to-node governance stack operate whether the cluster is standard HA, hosted control plane, or edge/SNO — with topology-specific operational divergences layered on top.

platform-governance-from-identity-to-node [IN] DERIVED

OpenShift governance is a unified stack spanning four layers: identity management (OAuth→User→Identity chain), resource access control (dual RBAC + SCC), namespace/project self-provisioning, and node-level immutable configuration — all enforced through singleton operator CRs.

platform-lifecycle-bounded-at-install-and-update [IN] DERIVED

OpenShift platform lifecycle is constrained at both boundaries: install-time decisions (FIPS, CPU partitioning, network plugin) are permanently irreversible, while post-install changes are gated by strict version coupling and update ordering (OCP before CNV, management before hosted) — the platform cannot be freely reconfigured at either end.

platform-lifecycle-spans-updates-and-recovery [IN] DERIVED

OpenShift lifecycle management operates under version governance at both ends: progressive updates (canary rollouts, EUS-to-EUS skips) and disaster recovery (etcd backup/restore) are both constrained by the same version coupling rules — recovery cannot escape the boundaries that updates must respect.

platform-model-with-topology-variants [IN] DERIVED

OpenShift operates through a single operator-driven immutable platform model that recognizes two sanctioned divergence paths — hosted control planes (control/data plane split) and edge/SNO (reduced capability profile) — each requiring distinct operational playbooks while sharing the same underlying operator and update governance.

platform-none-cannot-use-machine-api [IN] OBSERVATION

Clusters with infrastructure platform type none cannot use the Machine API, and this cannot be changed post-install.

platform-plus-bundles-ocp-acm-acs-quay [IN] OBSERVATION

OpenShift Platform Plus is a product SKU that bundles OpenShift Container Platform with Advanced Cluster Management (ACM), Advanced Cluster Security (ACS), and Quay.

platform-type-none-no-machine-api [IN] OBSERVATION

Clusters with infrastructure platform type none cannot use the Machine API, and this is immutable post-install.

pod-binding-endpoint-path [IN] OBSERVATION

The preferred (non-deprecated) pod binding endpoint is POST /api/v1/namespaces/{namespace}/pods/{name}/binding.

pod-bound-to-node-never-rebound [IN] OBSERVATION

Once a pod is bound to a node, it will never be rebound to another node.

pod-default-dns-policy-clusterfirst [IN] OBSERVATION

The default DNS policy for pods is ClusterFirst; to use DNS with hostNetwork: true, you must explicitly set ClusterFirstWithHostNet

pod-default-dnspolicy-clusterfirst [IN] OBSERVATION

The default Pod dnsPolicy is ClusterFirst.

pod-default-interface-eth0-secondary-net1 [IN] OBSERVATION

The default pod interface is always eth0; secondary network interfaces are named net1, net2, etc.

pod-default-restartpolicy-always [IN] OBSERVATION

The default Pod restartPolicy is Always.

pod-default-termination-grace-30 [IN] OBSERVATION

The default terminationGracePeriodSeconds for a Pod is 30 seconds.

pod-default-termination-grace-period-30s [IN] OBSERVATION

The default terminationGracePeriodSeconds for pods is 30 seconds

pod-network-name-info-metric-value-zero [IN] OBSERVATION

The podnetworkname_info metric always has a fixed value of 0 and exists solely as a label carrier for PromQL joins with container network metrics.

pod-network-name-info-promql-join-pattern [IN] OBSERVATION

To enrich containernetwork* metrics with network names, use + on(namespace,pod,interface) groupleft(networkname) ( podnetworkname_info ).

pod-only-required-field-containers [IN] OBSERVATION

The only required field in PodSpec is containers (at least one container must be specified).

pod-restart-policy-default-always [IN] OBSERVATION

Default pod restart policy is Always; exponential back-off delay (10s, 20s, 40s) caps at 5 minutes.

pod-scheduling-mechanisms [IN] OBSERVATION

Pod scheduling to nodes is controlled via node selectors, node affinity, and taints/tolerations.

pod-secondary-network-annotation [IN] OBSERVATION

Pods are attached to secondary networks using the annotation k8s.v1.cni.cncf.io/networks.

pod-serviceaccount-field-deprecated [IN] OBSERVATION

The serviceAccount field in PodSpec is deprecated — serviceAccountName should be used instead

pod-smallest-logical-unit [IN] OBSERVATION

The Pod is the smallest logical unit in Kubernetes, containing one or more containers running on a worker node.

pod-static-ip-layer2-localnet-no-subnets [IN] OBSERVATION

Static IP assignment for pods on secondary networks is only available on layer2/localnet topologies and only when subnets is NOT defined in the NAD.

podmetrics-container-names-match [IN] OBSERVATION

Container names in PodMetrics map directly to pod.spec.containers[].name; all container metrics within a pod are collected within the same time window.

podmetrics-endpoints [IN] OBSERVATION

PodMetrics API endpoints: /apis/metrics.k8s.io/v1beta1/pods (all namespaces), /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods (namespace-scoped), /apis/metrics.k8s.io/v1beta1/namespaces/{namespace}/pods/{name} (specific pod). All GET-only.

podmonitor-api-group-v1 [IN] OBSERVATION

PodMonitor is a CRD from the monitoring.coreos.com/v1 API group

podmonitor-auth-mutually-exclusive [IN] OBSERVATION

PodMonitor endpoint authentication options (authorization, basicAuth, oauth2) are mutually exclusive

podmonitor-bearer-token-secret-deprecated [IN] OBSERVATION

PodMonitor's bearerTokenSecret is deprecated; the replacement is the authorization field

podmonitor-default-path-metrics-scheme-http [IN] OBSERVATION

PodMonitor default scrape path is /metrics and default scheme is http

podmonitor-filter-running-default-enabled [IN] OBSERVATION

PodMonitor's filterRunning is enabled by default, dropping non-Running pods from target discovery

podmonitor-only-required-field-selector [IN] OBSERVATION

The only required field in PodMonitor .spec is selector, a label selector for pod discovery

podmonitor-relabelings-vs-metric-relabelings [IN] OBSERVATION

In PodMonitor, relabelings apply to target metadata labels before scrape; metricRelabelings apply to scraped samples before ingestion

podmonitor-scrapes-pods-directly [IN] OBSERVATION

PodMonitor targets pods directly without requiring a Service, unlike ServiceMonitor which targets Services

podnetworkconnectivitycheck-api-group [IN] OBSERVATION

PodNetworkConnectivityCheck belongs to API group controlplane.operator.openshift.io/v1alpha1 and has Compatibility Level 4 (no stability guarantees)

podnetworkconnectivitycheck-internal-api [IN] OBSERVATION

PodNetworkConnectivityCheck is an internal control plane API for cluster health monitoring, not intended for end-user application use

podnetworkconnectivitycheck-status-fields [IN] OBSERVATION

PodNetworkConnectivityCheck status tracks successes[], failures[] (individual log entries), and outages[] (time periods with start/end timestamps and boundary logs)

podnetworkconnectivitycheck-target-endpoint-format [IN] OBSERVATION

PodNetworkConnectivityCheck targetEndpoint uses host:port format; using an IP bypasses DNS resolution, using a DNS name causes failure if DNS resolution fails

podnetworkconnectivitycheck-tls-secret-same-namespace [IN] OBSERVATION

PodNetworkConnectivityCheck tlsClientCert must reference a kubernetes.io/tls type secret in the same namespace as the resource

pods-are-basic-deployable-unit [IN] OBSERVATION

Pods (not containers) are the basic unit of deployment, scaling, and management in Kubernetes/OpenShift.

pods-immutable-expendable [IN] OBSERVATION

Pods are immutable while running (changes require recreation) and expendable (do not maintain state when recreated).

pods-reference-nads-via-annotation [IN] OBSERVATION

Pods reference NetworkAttachmentDefinitions via the annotation k8s.v1.cni.cncf.io/networks

podsecuritypolicy-review-three-variants [IN] OBSERVATION

OpenShift has three PodSecurityPolicy review APIs: PodSecurityPolicyReview (which SAs can create a pod), PodSecurityPolicySelfSubjectReview (can the current user create it), and PodSecurityPolicySubjectReview (can a specific user/SA create it)

podsecuritypolicysubjectreview-allowedby-nil-means-denied [IN] OBSERVATION

In PodSecurityPolicySubjectReview, the status.allowedBy field references the SCC that permits the pod; when nil, the request was denied

podsecuritypolicysubjectreview-api-group [IN] OBSERVATION

PodSecurityPolicySubjectReview belongs to the security.openshift.io/v1 API group and is OpenShift-specific, not available in vanilla Kubernetes

podsecuritypolicysubjectreview-namespace-scoped [IN] OBSERVATION

PodSecurityPolicySubjectReview is a namespace-scoped resource accessed via POST /apis/security.openshift.io/v1/namespaces/{namespace}/podsecuritypolicysubjectreviews

podsecuritypolicysubjectreview-user-no-groups [IN] OBSERVATION

In PodSecurityPolicySubjectReview, if user is specified without groups, the user is tested as if belonging to no groups; if both are empty, only the serviceAccountName from the template is evaluated

podspec-containers-only-required-field [IN] OBSERVATION

The containers field is the only required field in a PodSpec — at least one container must be specified

policygenerator-namespace-must-prefix-ztp [IN] OBSERVATION

All PolicyGenerator CRs must be in a namespace prefixed with ztp.

policygentemplate-deprecated-for-policygenerator [IN] OBSERVATION

PolicyGenTemplate CRs are deprecated in favor of RHACM PolicyGenerator CRs for generating Day 2 configuration policies.

policyrule-empty-apigroups-means-both [IN] OBSERVATION

In a PolicyRule, an empty apiGroups field means both Kubernetes and OpenShift API groups are assumed.

policyrule-nonresourceurls-wildcard-final-segment [IN] OBSERVATION

In PolicyRules, nonResourceURLs supports * wildcards but only as the final path segment.

power-metrics-categories [IN] OBSERVATION

Power consumption metrics are categorized as total, active, and idle CPU power.

power-monitor-cr-name-must-be-exact [IN] OBSERVATION

The PowerMonitor custom resource instance must be named exactly power-monitor; all other instance names are ignored by the operator.

power-monitoring-container-level-granularity [IN] OBSERVATION

Power Monitoring in OCP tracks power consumption at the container level, not just node or pod level

power-monitoring-developer-dashboard-access [IN] OBSERVATION

Developers with view permissions on the openshift-power-monitoring namespace can access power monitoring dashboards but can only see the Overview dashboard, not the Namespace (Pods) dashboard.

power-monitoring-install-operator-then-cr [IN] OBSERVATION

Power monitoring installation requires two steps: install the Power monitoring Operator, then deploy the PowerMonitor custom resource.

power-monitoring-namespace [IN] OBSERVATION

Kepler is deployed in the openshift-power-monitoring namespace.

power-monitoring-operator-all-namespaces [IN] OBSERVATION

The Power Monitoring Operator installation makes power monitoring available across all namespaces.

power-monitoring-operator-installed [IN] OBSERVATION

Power Monitoring is an optional capability installed and managed via the Power Monitoring Operator

power-monitoring-prereqs-dashboards [IN] OBSERVATION

Power monitoring dashboards require three prerequisites: Power Monitoring Operator installed, Kepler deployed, and user-defined project monitoring enabled.

power-monitoring-requires-cluster-admin [IN] OBSERVATION

Installing, configuring, and uninstalling power monitoring requires the cluster-admin role.

power-monitoring-tech-preview [IN] OBSERVATION

Power monitoring for OpenShift is Technical Preview and not supported for production use.

power-monitoring-technology-preview [IN] OBSERVATION

Power monitoring in OpenShift Container Platform is a Technology Preview feature, not supported under production SLAs and not recommended for production use.

power-monitoring-technology-preview-ocp417 [IN] OBSERVATION

Power monitoring using Kepler is a Technology Preview feature in OCP 4.17, not supported under production SLAs.

power-monitoring-tracks-cpu-and-dram [IN] OBSERVATION

Power monitoring tracks power consumption of two specific hardware components: CPU and DRAM, at container granularity.

power-monitoring-two-dashboards [IN] OBSERVATION

Power monitoring provides two dashboards: "Power Monitor / Overview" (cluster/node level) and "Power Monitor / Namespace (Pods)" (namespace/pod level, showing top 10 power-consuming namespaces).

power-monitoring-uninstall-order [IN] OBSERVATION

Power monitoring uninstall must follow a specific order: delete Kepler instance first, then delete PowerMonitor CR, then uninstall the Power Monitoring Operator.

power-monitoring-uses-kepler [IN] OBSERVATION

Power monitoring for OpenShift is built on Kepler (Kubernetes-based Efficient Power Level Exporter) for collecting power consumption metrics.

power-monitoring-uses-kepler-upstream [IN] OBSERVATION

Power Monitoring is powered by Kepler (Kubernetes Efficient Power Level Exporter) as its upstream project

powermonitor-apiversion [IN] OBSERVATION

The PowerMonitor CR uses apiVersion kepler.system.sustainable.computing.io/v1alpha1.

powermonitor-must-be-named-power-monitor [IN] OBSERVATION

The PowerMonitor custom resource instance must be named power-monitor; all other names are rejected by the operator webhook.

precache-disk-must-be-wiped-first [IN] OBSERVATION

The disk must be wiped before partitioning with wipefs -a; the factory-precaching-cli tool fails on non-empty disks.

precache-du-profile-flag-day2-operators [IN] OBSERVATION

The --du-profile flag adds Day-2 Operator images for telco 5G RAN distributed unit workloads to the pre-cache.

precache-parallel-workers-80pct-cpus [IN] OBSERVATION

The factory-precaching-cli default parallel download workers is 80% of available CPUs, configurable via --parallel / -p.

precache-partition-end-of-disk-labelled-data [IN] OBSERVATION

The pre-cache data partition must be at the end of the disk and labelled data so that coreos-installer preserves it; formatted as XFS with GPT partition table.

preprovisioningimage-api-group-metal3-v1alpha1 [IN] OBSERVATION

The PreprovisioningImage custom resource belongs to API group metal3.io/v1alpha1 and is a namespaced resource.

preprovisioningimage-formats-iso-and-initrd [IN] OBSERVATION

PreprovisioningImage supports two image formats: iso and initrd; kernel-related fields (kernelUrl, extraKernelParams) only apply to initrd format.

preprovisioningimage-network-data-via-secret [IN] OBSERVATION

PreprovisioningImage injects network data via a Kubernetes Secret referenced by name in the spec field networkDataName.

preserve-images-from-pruning-by-digest-tag [IN] OBSERVATION

To preserve historical images from pruning, maintain a tag in the ImageStream spec pointing to the image by digest.

priorityclass-integer-scheduling [IN] OBSERVATION

PriorityClass (scheduling.k8s.io/v1) maps a priority class name to an integer value; higher values mean higher priority for both scheduling order and preemption behavior.

priorityclass-preemption-never-queues [IN] OBSERVATION

Setting preemptionPolicy: Never on a PriorityClass creates high-priority pods that queue instead of evicting lower-priority pods.

prioritylevelconfig-default-queuing [IN] OBSERVATION

PriorityLevelConfiguration default queuing parameters are 64 queues, hand size 8, and queue length limit 50; setting NominalConcurrencyShares to 0 creates a "jail" that holds requests indefinitely.

prioritylevelconfig-types-exempt-limited [IN] OBSERVATION

PriorityLevelConfiguration (flowcontrol.apiserver.k8s.io/v1) has exactly two types: Exempt (requests bypass all limits) and Limited (requests subject to concurrency limits); default NominalConcurrencyShares for Limited is 30.

privileged-projects-no-image-resolution [IN] OBSERVATION

Default/privileged projects (default, kube-public, kube-system, openshift, openshift-infra, openshift-node, and projects with openshift.io/run-level label 0 or 1) do not support image stream reference resolution.

privileged-projects-no-workloads [IN] OBSERVATION

Default/privileged projects (default, kube-public, kube-system, openshift, openshift-infra, openshift-node) should not run workloads — pod security admission and image reference resolution do not work in these projects.

probe-crd-api-group-v1 [IN] OBSERVATION

The Probe CRD belongs to the monitoring.coreos.com/v1 API group

probe-default-prober-path-probe [IN] OBSERVATION

The Probe CRD's default prober path is /probe, default scheme is http, default auth type is Bearer

probe-default-values [IN] OBSERVATION

Probe default values: initialDelaySeconds=0, periodSeconds=10, timeoutSeconds=1, successThreshold=1, failureThreshold=3.

probe-liveness-success-threshold-must-be-1 [IN] OBSERVATION

The successThreshold parameter must be 1 for liveness probes.

probe-oauth2-required-fields [IN] OBSERVATION

Probe OAuth2 configuration requires three fields: clientId, clientSecret, and tokenUrl

probe-prober-url-mandatory [IN] OBSERVATION

The Probe CRD's prober.url field is mandatory — targets cannot be probed without it

probe-startup-max-time-formula [IN] OBSERVATION

Startup probe maximum startup time is calculated as failureThreshold × periodSeconds.

probe-static-config-takes-precedence [IN] OBSERVATION

When both staticConfig and ingress targets are defined on a Probe, staticConfig takes precedence

probe-three-test-mechanisms [IN] OBSERVATION

Health check probes support three test mechanisms: HTTP GET (200–399 = success), container command/exec (exit 0 = success), and TCP socket (connection established = success).

probe-three-types [IN] OBSERVATION

OpenShift/Kubernetes supports three health check probe types: readiness (removes pod from endpoints on failure), liveness (kills/restarts container on failure), and startup (gates other probes until success).

probe-two-target-types [IN] OBSERVATION

Probe supports two target types: staticConfig (explicit host list) and ingress (auto-discovery from Ingress objects via label selectors)

progressive-update-across-heterogeneous-fleet [IN] DERIVED

OpenShift progressive update strategies (canary MCPs, EUS-to-EUS skips) must navigate the heterogeneous node fleet: RHCOS nodes accept updates via rpm-ostree atomic images while Windows nodes diverge entirely, and install-time locks (FIPS, network plugin) create irreversible boundaries that updates cannot cross.

progressive-update-within-lifecycle-bounds [IN] DERIVED

OpenShift update strategies (canary rollouts via custom MCPs and EUS-to-EUS skips for even minor versions) operate strictly within the platform's lifecycle boundaries — install-time decisions constrain what can be updated, and version coupling determines the order and scope of what canary pools can validate.

project-admin-cannot-change-own-quotas [IN] OBSERVATION

Project administrators cannot alter their own project quotas — only cluster administrators can modify quotas

project-api-group-openshift-io-v1 [IN] OBSERVATION

The Project and ProjectRequest resources belong to the project.openshift.io/v1 API group, not core Kubernetes

project-config-singleton-named-cluster [IN] OBSERVATION

The config.openshift.io/v1 Project resource is a cluster-wide singleton with the canonical name cluster.

project-config-vs-project-resource-api-groups [IN] OBSERVATION

config.openshift.io/v1 Project is the cluster config singleton; project.openshift.io/v1 Project represents individual project resources — they are distinct API groups.

project-listing-scoped-to-user-access [IN] OBSERVATION

Listing or watching projects returns only projects where the user has the reader role

project-one-to-one-namespace-mapping [IN] OBSERVATION

Every OpenShift Project maps 1:1 to a Kubernetes Namespace, but not every Namespace is necessarily a Project

project-request-message-shown-when-denied [IN] OBSERVATION

The spec.projectRequestMessage field on the Project config controls the message shown to users who cannot create projects via the projectrequest endpoint.

project-request-template-customizable [IN] OBSERVATION

The default project request template can be customized to inject default network policies, resource quotas, and limit ranges into every new project.

project-request-template-in-openshift-config-ns [IN] OBSERVATION

The custom project request template referenced by the Project config must reside in the openshift-config namespace.

project-self-provisioning-governance [IN] DERIVED

Project self-provisioning is governed by a three-part mechanism: admins can disable it (two-step process: remove subjects + set annotation), a custom request template controls project defaults, and a configurable message informs denied users — enabling fine-grained organizational control over namespace creation.

project-status-phase-active-or-terminating [IN] OBSERVATION

A Project's status phase is either Active (available for use) or Terminating (undergoing graceful termination)

project-three-roles-admin-edit-view [IN] OBSERVATION

Projects have three roles: admin (set membership), edit (create/manage resources), view (read-only, no container access)

project-watch-endpoints-deprecated [IN] OBSERVATION

The dedicated watch endpoints for Projects (/watch/projects) are deprecated — use the watch query parameter on list operations instead

project-wraps-namespace [IN] OBSERVATION

Project (project.openshift.io/v1) wraps Namespace (v1) with additional policy in OpenShift.

project-wraps-namespace-editable-by-users [IN] OBSERVATION

An OpenShift Project is an alternative representation of a Kubernetes Namespace; Projects are editable by end users while Namespaces are not

projecthelmchartrepo-ca-configmap-key [IN] OBSERVATION

The CA bundle ConfigMap for ProjectHelmChartRepository uses the key ca-bundle.crt; if empty, default system roots are used.

projecthelmchartrepo-namespace-scoped [IN] OBSERVATION

ProjectHelmChartRepository (helm.openshift.io/v1beta1) is namespace-scoped, while HelmChartRepository is cluster-scoped.

projecthelmchartrepo-secrets-same-namespace [IN] OBSERVATION

Secrets and ConfigMaps referenced by a ProjectHelmChartRepository for auth, TLS, and CA must be in the same namespace as the resource.

projectrequest-displayname-description-fields [IN] OBSERVATION

ProjectRequest has displayName and description fields that are OpenShift-specific metadata not present on Kubernetes Namespaces

projects-extend-namespaces [IN] OBSERVATION

OpenShift Projects extend Kubernetes namespaces with additional features including user self-provisioning, policies, constraints, and service accounts.

projects-fundamental-org-unit [IN] OBSERVATION

Projects are the fundamental organizational unit (namespace/tenancy boundary) for applications in OpenShift.

prometheusrule-api-group-v1 [IN] OBSERVATION

PrometheusRule belongs to API group monitoring.coreos.com/v1 and is namespace-scoped

prometheusrule-expr-required [IN] OBSERVATION

The expr field (PromQL expression) is required on every PrometheusRule rule

prometheusrule-for-user-defined-alerts [IN] OBSERVATION

User-defined project alerting rules use kind PrometheusRule with apiVersion monitoring.coreos.com/v1, created in the user's project namespace.

prometheusrule-for-vs-keep-firing-for [IN] OBSERVATION

In PrometheusRule, for controls how long a condition must be true before an alert fires; keepfiringfor controls how long an alert continues firing after the condition clears

prometheusrule-group-name-required [IN] OBSERVATION

The name field is required on every PrometheusRule rule group

prometheusrule-limit-requires-prometheus-231 [IN] OBSERVATION

PrometheusRule's limit field on rule groups requires Prometheus >= 2.31

prometheusrule-record-or-alert-not-both [IN] OBSERVATION

A PrometheusRule rule must set exactly one of record or alert, never both

prometheusrule-supports-both-rule-types [IN] OBSERVATION

PrometheusRule (monitoring.coreos.com/v1) supports both recording and alerting rules, unlike the OpenShift-specific AlertingRule which only supports alerting rules.

provisioning-apis-bare-metal-only [IN] OBSERVATION

Provisioning APIs (metal3.io group) are specific to bare-metal deployments and do not apply to cloud-based (AWS, Azure, GCP) or virtualized installations

provisioning-apis-use-metal3-api-group [IN] OBSERVATION

Provisioning APIs (BareMetalHost, Provisioning, HardwareData, PreprovisioningImage, HostFirmwareSettings, FirmwareSchema) belong to the metal3.io API group.

provisioning-consumed-by-cluster-baremetal-operator [IN] OBSERVATION

The Provisioning CR is consumed by the cluster-baremetal-operator to manage metal3 container lifecycle.

provisioning-cr-singleton-per-cluster [IN] OBSERVATION

The Provisioning custom resource (metal3.io/v1alpha1) is a singleton — only one exists per cluster, named cluster, created automatically by the OpenShift installer.

provisioning-default-dhcp-range-10-to-100 [IN] OBSERVATION

The default provisioning DHCP range is .10 to .100 of the provisioningNetworkCIDR.

provisioning-dhcp-external-deprecated [IN] OBSERVATION

The provisioningDHCPExternal field is deprecated in favor of the provisioningNetwork field on the Provisioning CR.

provisioning-dhcprange-only-mutable-post-install [IN] OBSERVATION

The provisioningDHCPRange field is the only field on the Provisioning CR that can be changed after installation.

provisioning-ip-inside-subnet-outside-dhcp [IN] OBSERVATION

The provisioningIP must be within the provisioning subnet (provisioningNetworkCIDR) but outside the DHCP range.

provisioning-ipv6-max-64-prefix [IN] OBSERVATION

IPv6 provisioning networks in Managed mode cannot exceed a /64 prefix length.

provisioning-network-three-modes [IN] OBSERVATION

The Provisioning CR supports three provisioningNetwork modes: Managed (full IPI management), Unmanaged (user manages DHCP), and Disabled (no provisioning network, requires virtual media or assisted installation).

provisioning-subsystem-uses-ironic [IN] OBSERVATION

The OpenShift bare metal provisioning subsystem uses Ironic under the covers for BMC communication via IPMI, Redfish, and iDRAC protocols.

provisioning-watch-all-namespaces-default-false [IN] OBSERVATION

The Provisioning CR field watchAllNamespaces defaults to false, meaning bare metal hosts are only provisioned in the openshift-machine-api namespace by default.

proxy-empty-fields-no-env-vars [IN] OBSERVATION

Empty values for httpProxy, httpsProxy, or noProxy in the Proxy resource mean no corresponding environment variable is set on pods.

proxy-merged-bundle-in-openshift-config-managed [IN] OBSERVATION

The proxy validator merges the custom CA bundle with system defaults and writes the result to trusted-ca-bundle ConfigMap in the openshift-config-managed namespace.

proxy-readiness-endpoints-verify-connectivity [IN] OBSERVATION

The Proxy resource's readinessEndpoints field is used to verify proxy connectivity before applying the configuration.

proxy-trustedca-in-openshift-config [IN] OBSERVATION

The Proxy resource's trustedCA field references a ConfigMap in the openshift-config namespace with key ca-bundle.crt.

pruner-behavior-depends-on-management-state [IN] OBSERVATION

When the registry Operator is Managed, the pruner uses --prune-registry=true (prunes blobs); when Removed, the pruner uses --prune-registry=false (only prunes etcd metadata).

ptp-clock-health-master-offset-range [IN] OBSERVATION

PTP clock health requires master_offset between -100 and +100 ns, gmPresent must be true, and portState should be SLAVE.

ptp-fast-events-cloud-event-proxy [IN] OBSERVATION

PTP fast event notifications use a pub-sub REST API delivered via cloud-event-proxy sidecar over HTTP.

ptp-gnss-requires-e810-nic [IN] OBSERVATION

GNSS timing for PTP is supported only with Intel E810 Westport Channel NICs.

ptp-linuxptp-daemons [IN] OBSERVATION

The linuxptp package provides ts2phc (grandmaster), ptp4l (boundary/ordinary clocks), phc2sys (system clock to PHC sync), and pmc daemons.

ptp-operator-bare-metal-only [IN] OBSERVATION

The PTP Operator works only on bare-metal infrastructure in OpenShift.

ptp-operator-namespace-openshift-ptp [IN] OBSERVATION

The PTP Operator is installed in the openshift-ptp namespace with label openshift.io/cluster-monitoring: "true".

ptp-requires-chronyd-disabled [IN] OBSERVATION

NTP/chronyd must be disabled via MachineConfig CR before enabling PTP on OpenShift nodes.

ptp-sub-microsecond-accuracy [IN] OBSERVATION

PTP (Precision Time Protocol) provides sub-microsecond clock accuracy using hardware support, more accurate than NTP.

ptp-three-clock-types [IN] OBSERVATION

PTP defines three clock types: Grandmaster (syncs to GNSS, authoritative source), Boundary (multi-port relay between upstream/downstream), and Ordinary (single-port, source or destination).

publish-internal-not-supported-non-cloud [IN] OBSERVATION

publish: Internal is not supported on non-cloud platforms.

publish-internal-private-cluster [IN] OBSERVATION

Setting publish: Internal in install-config.yaml creates a private cluster inaccessible from the internet.

pull-secret-types-docker-vs-podman [IN] OBSERVATION

Pull secret types: kubernetes.io/dockerconfigjson for Docker (~/.docker/config.json) and kubernetes.io/podmanconfigjson for Podman (~/.config/containers/auth.json).

pv-access-modes-rwo-rox-rwx-rwop [IN] OBSERVATION

OpenShift supports four PV access modes: RWO (ReadWriteOnce), ROX (ReadOnlyMany), RWX (ReadWriteMany), and RWOP (ReadWriteOncePod).

pv-bound-to-single-pvc [IN] OBSERVATION

Once a PV is bound to a PVC, it cannot bind to another PVC — the PV is effectively scoped to the binding project's namespace.

pv-cluster-scoped-pvc-namespace-scoped [IN] OBSERVATION

PersistentVolumes (PVs) are cluster-scoped resources; PersistentVolumeClaims (PVCs) are namespace/project-scoped resources.

pv-expansion-failure-recovery-procedure [IN] OBSERVATION

Recovery from failed PV expansion requires: set PV reclaim policy to Retain, delete the PVC, remove claimRef from PV spec, re-create PVC with valid size, restore original reclaim policy.

pv-lifecycle-phases [IN] OBSERVATION

PV lifecycle phases are: Available → Bound → Released → Failed.

pv-pvc-one-to-one-binding [IN] OBSERVATION

A PV bound to a PVC cannot be bound to additional PVCs — the binding is one-to-one.

pv-reclaim-policies-retain-recycle-delete [IN] OBSERVATION

PV reclaim policies are Retain, Recycle, and Delete — determining what happens to a PV after release.

pvc-access-modes-rwo-rox-rwx-rwop [IN] OBSERVATION

The four PV access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP).

pvc-binding-matches-access-mode-and-size [IN] OBSERVATION

PVC binding matches on access modes and size only, selecting the smallest sufficient PV.

pvc-binds-smallest-matching-pv [IN] OBSERVATION

OCP binds PVCs to the smallest PV that matches all criteria to minimize storage waste.

pvc-cannot-shrink [IN] OBSERVATION

PVCs cannot be shrunk — only expanded. A smaller value in .spec.resources.requests.storage is rejected.

pvc-datasourceref-more-flexible-than-datasource [IN] OBSERVATION

dataSourceRef is more flexible than dataSource on PVCs — it supports any non-core object, cross-namespace references (alpha), and preserves disallowed values as errors instead of silently dropping them.

pvc-default-volumemode-filesystem [IN] OBSERVATION

The default volumeMode for a PersistentVolumeClaim is Filesystem when not specified.

pvc-is-namespaced-pv-is-cluster-scoped [IN] OBSERVATION

PersistentVolumeClaims (PVCs) are namespaced resources; PersistentVolumes (PVs) are cluster-scoped resources.

pvc-three-phases [IN] OBSERVATION

A PVC has three phases: Pending (not yet bound), Bound (bound to a PV), and Lost (underlying PV no longer exists).

quay-container-security-operator-deprecated [IN] OBSERVATION

The Red Hat Quay Container Security Operator is deprecated and will be replaced by Red Hat Advanced Cluster Security (ACS) for Kubernetes.

quota-forces-complete-resource-declarations [IN] DERIVED

Resource quotas create a strict contract: when quotas specify CPU/memory, every container must declare those values, and extended resources like GPUs cannot be overcommitted — enforcing explicit resource accounting.

quota-openshift-io-api-group [IN] OBSERVATION

The quota.openshift.io/v1 API group contains OpenShift-specific quota resources (ClusterResourceQuota, AppliedClusterResourceQuota); LimitRange and ResourceQuota are core v1, PriorityClass is scheduling.k8s.io/v1, and flow control uses flowcontrol.apiserver.k8s.io/v1.

rangeallocation-cluster-scoped-level4 [IN] OBSERVATION

RangeAllocation (security.openshift.io/v1) is a cluster-scoped resource with Compatibility Level 4 (no stability guarantees)

rangeallocation-range-format [IN] OBSERVATION

RangeAllocation's range field uses the format "start-end/blockSize" (e.g., "1000000000-2000000000/10000") and both range and data fields are required

rangeallocation-tracks-namespace-uid-ranges [IN] OBSERVATION

RangeAllocation tracks which UID ranges have been assigned to namespaces using a bitmap stored in the data field, supporting OpenShift's multi-tenant UID isolation model

rangeallocation-tracks-uid-gid-ranges [IN] OBSERVATION

RangeAllocation is a Security API object that tracks UID/GID range assignments for namespaces in OpenShift.

rbac-api-groups-k8s-and-openshift [IN] OBSERVATION

RBAC APIs live under rbac.authorization.k8s.io/v1 (Kubernetes) and authorization.openshift.io/v1 (OpenShift extensions).

rbac-binding-references-not-contains [IN] OBSERVATION

RoleBindings and ClusterRoleBindings reference roles but do not contain them — they are separate API objects.

rbac-dual-api-groups [IN] OBSERVATION

OpenShift uses both Kubernetes-native RBAC (rbac.authorization.k8s.io) and OpenShift-specific authorization APIs (authorization.openshift.io) for role-based access control.

rbac-empty-string-core-api-group [IN] OBSERVATION

In RBAC rules, "" (empty string) represents the core API group containing pods, services, configmaps, etc.

rbac-four-core-resources [IN] OBSERVATION

The four core RBAC API resources in OpenShift/Kubernetes are ClusterRole, ClusterRoleBinding, Role, and RoleBinding, all under the rbac.authorization.k8s.io/v1 API group.

rbac-nonresourceurls-clusterrole-only [IN] OBSERVATION

The nonResourceURLs field in PolicyRules only works in ClusterRoles referenced by ClusterRoleBindings, not in namespace-scoped Roles.

rbac-oc-adm-policy-commands [IN] OBSERVATION

RBAC roles are managed via oc adm policy add-cluster-role-to-user <role> <user> for cluster-wide and oc adm policy add-role-to-user <role> <user> -n <namespace> for namespace-scoped bindings.

rbac-policyrule-verbs-required [IN] OBSERVATION

In a PolicyRule, verbs is the only required field; valid verbs include get, list, create, update, delete, and * (all).

rbac-role-namespace-scoped [IN] OBSERVATION

Role is namespace-scoped and only grants permissions within the namespace where it is created; ClusterRole is cluster-scoped.

rbac-role-requires-binding [IN] OBSERVATION

A Role alone does nothing — it must be paired with a RoleBinding to grant permissions to subjects.

rbac-rolebinding-can-reference-clusterrole [IN] OBSERVATION

A RoleBinding can reference a ClusterRole, which grants the ClusterRole's permissions but scoped only to the RoleBinding's namespace.

rbac-roleref-immutable [IN] OBSERVATION

The roleRef field on a RoleBinding is immutable after creation — the RoleBinding must be deleted and recreated to change the referenced role.

rbac-subject-apigroup-defaults [IN] OBSERVATION

ServiceAccount subjects use "" (empty) apiGroup and require a namespace field; User and Group subjects use rbac.authorization.k8s.io apiGroup and must not specify a namespace.

rbac-subject-kinds [IN] OBSERVATION

The three valid subject kinds in RoleBindings/ClusterRoleBindings are User, Group, and ServiceAccount.

recordtype-values [IN] OBSERVATION

_RecordType values are: flowLog (regular), newConnection, heartbeat, endConnection (for conversation tracking)

recreate-strategy-has-mid-hook [IN] OBSERVATION

The Recreate deployment strategy supports pre, mid, and post lifecycle hooks; the mid-hook runs between scale-down and scale-up. Rolling strategy only supports pre and post hooks.

recycle-reclaim-policy-deprecated-ocp4 [IN] OBSERVATION

The Recycle reclaim policy is deprecated in OpenShift Container Platform 4; dynamic provisioning is the recommended replacement.

redhat-aws-ami-owner-id [IN] OBSERVATION

Red Hat's AWS account ID for AMI ownership is 309956199498.

redhat-container-registry-url [IN] OBSERVATION

Red Hat's container registry is registry.redhat.io.

reference-policy-local-benefits [IN] OBSERVATION

referencePolicy.type: Local provides two key benefits: namespace-scoped credential isolation (via pull secrets) and offline resilience through local layer mirroring in the integrated registry.

reference-policy-local-pull-through [IN] OBSERVATION

--reference-policy=local forces image pulls through the integrated registry, enabling pull-through from insecure registries without container runtime --insecure flags.

referencepolicy-local-enables-layer-mirroring [IN] OBSERVATION

referencePolicy.type=Local on an ImageStreamTag points pulls to the integrated registry, enabling namespace-level credential management and layer mirroring so images remain available if the upstream registry goes down

registry-auth-uses-oauth-token [IN] OBSERVATION

Authentication to the exposed registry uses oc whoami -t to obtain an OAuth token, which is passed to podman login.

registry-auth-uses-token-not-username [IN] OBSERVATION

When using podman login to the internal registry, the token (oc whoami -t) carries all auth info; the username is largely irrelevant but must not contain colons.

registry-baremetal-vsphere-default-removed [IN] OBSERVATION

On bare metal and vSphere installations, the registry managementState defaults to Removed and must be changed to Managed with storage configured manually.

registry-ca-port-delimiter-double-dot [IN] OBSERVATION

In additional trusted CA ConfigMaps for external registries, the port delimiter is .. (double dot) not : — e.g., registry.example.com..5000.

registry-config-files-on-nodes [IN] OBSERVATION

Allowed registries are reflected in /etc/containers/policy.json; blocked registries in /etc/containers/registries.conf on cluster nodes

registry-cr-name-cluster [IN] OBSERVATION

The Image Registry Operator custom resource is always named cluster — full path: configs.imageregistry.operator.openshift.io/cluster.

registry-credential-secret-name [IN] OBSERVATION

Registry storage credentials are stored in a secret named image-registry-private-configuration-user in the openshift-image-registry namespace.

registry-custom-route-spec-fields [IN] OBSERVATION

Custom registry routes are configured in the operator CR's spec.routes array with fields name, hostname, and optionally secretName for custom TLS certificates.

registry-default-route-patch-command [IN] OBSERVATION

Setting spec.defaultRoute: true on configs.imageregistry.operator.openshift.io/cluster creates a route named default-route in the openshift-image-registry namespace.

registry-default-route-uses-ingress-cert [IN] OBSERVATION

The registry's default route uses the Ingress Operator's certificate (not a registry-specific certificate); the default secret is router-certs-default in openshift-ingress namespace.

registry-disable-redirect-proxies-traffic [IN] OBSERVATION

Setting disableRedirect: true on the registry CR forces traffic through the registry proxy instead of redirecting clients to object storage directly, increasing registry resource usage.

registry-emptydir-non-production-only [IN] OBSERVATION

The emptyDir storage backend for the registry is acceptable only for non-production use; data does not persist across pod restarts.

registry-logs-command [IN] OBSERVATION

Registry logs are viewed with oc logs deployments/image-registry -n openshift-image-registry.

registry-management-state-values [IN] OBSERVATION

The Image Registry Operator managementState has three values: Managed (actively manages), Unmanaged (ignores changes), and Removed (tears down registry and storage).

registry-metrics-endpoint-path [IN] OBSERVATION

The integrated registry exposes Prometheus metrics at /extensions/v2/metrics.

registry-not-exposed-by-default [IN] OBSERVATION

The OpenShift image registry is not exposed outside the cluster by default; external access requires explicitly creating a route.

registry-operator-cr-name [IN] OBSERVATION

The Image Registry Operator manages the registry via the configs.imageregistry.operator.openshift.io CR; the cluster-scoped instance is named cluster.

registry-push-format-project-name [IN] OBSERVATION

Repository names pushed to the internal registry must use <project>/<name> format; deeper paths cause authentication errors.

registry-pvc-namespace-and-annotation [IN] OBSERVATION

PVCs for the registry must be in the openshift-image-registry namespace with annotation imageregistry.openshift.io: "true".

registry-redhat-io-requires-auth [IN] OBSERVATION

registry.redhat.io requires authentication; registry.access.redhat.com is the deprecated unauthenticated alternative.

registry-s3-chunk-size-defaults [IN] OBSERVATION

The S3 storage backend default chunkSizeMiB is 10 MiB with a minimum of 5 MiB.

registry-storage-auto-config-ipi-only [IN] OBSERVATION

Registry storage is only auto-configured on installer-provisioned infrastructure (IPI) clusters on AWS, Azure, GCP, IBM, or RHOSP.

registry-storage-credentials-secret [IN] OBSERVATION

Custom storage credentials for the registry go in secret image-registry-private-configuration-user in namespace openshift-image-registry.

registry-storage-secret-keys-per-provider [IN] OBSERVATION

Registry storage credential secret keys by provider: AWS S3 uses REGISTRYSTORAGES3ACCESSKEY/REGISTRYSTORAGES3SECRETKEY, GCS uses REGISTRYSTORAGEGCSKEYFILE, Swift uses REGISTRYSTORAGESWIFTUSERNAME/REGISTRYSTORAGESWIFTPASSWORD, Azure uses REGISTRYSTORAGEAZUREACCOUNTKEY.

registry-viewer-pull-editor-push [IN] OBSERVATION

The registry-viewer role grants pull access and the registry-editor role grants push access to the integrated image registry.

release-channel-graduation-depends-on-telemetry [IN] OBSERVATION

Release channel graduation from fast to stable depends on connected cluster telemetry data about update success rates

release-images-hosted-in-quay [IN] OBSERVATION

OCP release artifacts are hosted in Quay as container images.

remote-health-monitoring-telemetry-and-insights [IN] OBSERVATION

Remote health monitoring in OpenShift consists of two mechanisms: Telemetry (metrics/usage data) and the Insights Operator (configuration analysis and recommendations).

remote-health-no-identifying-info [IN] OBSERVATION

Neither Telemetry nor the Insights Operator collects identifying information such as usernames, passwords, or certificates

remote-health-tls-mutual-cert-auth [IN] OBSERVATION

Remote health monitoring data is encrypted using TLS with mutual certificate authentication, both in transit and at rest

remote-workers-must-use-virtual-media-not-pxe [IN] OBSERVATION

Remote worker nodes must use virtual media (not PXE) for IPI bare metal deployments, configured via virtualMediaViaExternalNetwork: true.

remove-self-provisioner-prevents-project-creation [IN] OBSERVATION

Removing the self-provisioner ClusterRoleBinding from system:authenticated:oauth prevents users from creating their own projects.

replicaset-apps-v1-api-group [IN] OBSERVATION

ReplicaSets belong to the apps/v1 API group (not v1 or extensions).

replicaset-replicas-default-1 [IN] OBSERVATION

ReplicaSet .spec.replicas defaults to 1.

replicaset-selector-required [IN] OBSERVATION

The .spec.selector is the only required field in a ReplicaSet spec; it must match the pod template's labels.

replicationcontroller-v1-core-equality-selectors [IN] OBSERVATION

ReplicationController is a v1 core API resource that uses equality-based label selectors only, unlike ReplicaSet which supports set-based selectors.

reserved-isolated-cpu-sets-no-overlap [IN] OBSERVATION

In workload partitioning, reserved and isolated CPU sets must not overlap, and all non-isolated CPUs must be reserved.

resource-field-immutability-pattern [IN] DERIVED

Multiple OpenShift resources enforce field immutability after creation — Route host, IngressController domain, and IngressClass controller cannot be changed post-creation — establishing a pattern where identity-defining fields are write-once to prevent runtime conflicts and maintain stable addressing.

resource-verbs-vs-http-verbs [IN] OBSERVATION

SubjectAccessReview resourceAttributes uses Kubernetes verbs (get, list, watch, create, update, delete, proxy); HTTP verbs are used only for nonResourceAttributes

resourceaccessreview-is-cluster-scoped [IN] OBSERVATION

ResourceAccessReview (authorization.openshift.io/v1) is cluster-scoped (no namespace in the URL path: POST /apis/authorization.openshift.io/v1/resourceaccessreviews), unlike its namespace-scoped counterpart LocalResourceAccessReview.

resourceaccessreview-openshift-only [IN] OBSERVATION

ResourceAccessReview (returns which users/groups can perform an action) is an OpenShift-only resource with no Kubernetes equivalent.

resourceattributes-uses-k8s-verbs-nonresource-uses-http-verbs [IN] OBSERVATION

In LocalSubjectAccessReview, resourceAttributes.verb uses Kubernetes API verbs (get, list, watch, create, update, delete, proxy), while nonResourceAttributes.verb uses standard HTTP verbs.

resourcequota-limits-aggregate-per-namespace [IN] OBSERVATION

ResourceQuota limits aggregate resource consumption per namespace in OpenShift/Kubernetes.

resourcequota-limits-compute-objects-storage [IN] OBSERVATION

ResourceQuota can limit compute resources (CPU, memory), object counts (pods, services, configmaps), and storage requests; when a namespace would exceed its quota, new resource creation is blocked.

resourcequota-namespace-scoped [IN] OBSERVATION

ResourceQuota is a namespace-scoped Kubernetes API object (core v1) that enforces aggregate resource consumption limits within a single namespace.

resourcequota-scopes [IN] OBSERVATION

ResourceQuota scopes include BestEffort, NotBestEffort, Terminating (activeDeadlineSeconds >= 0), NotTerminating (activeDeadlineSeconds is nil), PriorityClass, and CrossNamespacePodAffinity; scope selectors use AND logic.

restricted-v2-more-restrictive-than-restricted [IN] OBSERVATION

The restricted-v2 SCC is more restrictive than restricted — it does not allow privilegeEscalation. In upgraded clusters both exist; in new OCP 4.11+ installs only restricted-v2 is available by default.

revision-limit-minus-one-unlimited [IN] OBSERVATION

Setting static pod operator revision limits to -1 enables unlimited revision retention

rh-marketplace-admin-launches-instances-via-crds [IN] OBSERVATION

Administrators can launch Marketplace application instances by browsing CRDs in the Installed Operators list.

rh-marketplace-developer-perspective-no-operator-install [IN] OBSERVATION

The Developer perspective in OCP does not include Operator installation or usage tracking — those are Administrator-only functions.

rh-marketplace-operator-three-functions [IN] OBSERVATION

The Red Hat Marketplace Operator performs three functions: updates image registry secrets, manages the catalog, and reports application usage.

rhacm-hub-validated-3500-sno-clusters [IN] OBSERVATION

Lab-validated scale: 3,500 virtual SNO clusters managed from a single RHACM hub cluster (tested with 50ms RTT, 0.02% packet loss, 20 Mbps bandwidth).

rhcos-default-ssh-user-core [IN] OBSERVATION

The default SSH username for RHCOS (Red Hat Enterprise Linux CoreOS) nodes is core

rhcos-default-user-core [IN] OBSERVATION

The default user on RHCOS is core, with SSH key injected via Ignition.

rhcos-fs-changes-not-preserved [IN] OBSERVATION

RHCOS filesystem modifications are not preserved across minor releases unless made through a supported Operator (MCO, Node Tuning Operator).

rhcos-immutable-container-os [IN] OBSERVATION

RHCOS (Red Hat Enterprise Linux CoreOS) is the immutable container host OS used on all OCP cluster machines, including kubelet, CRI-O runtime, and SELinux enabled by default

rhcos-immutable-update-model [IN] DERIVED

RHCOS nodes follow an immutable infrastructure model: changes applied via Operators (not SSH), OS updates via rpm-ostree atomic images, and custom layering verified through rpm-ostree status.

rhcos-nodes-immutable [IN] OBSERVATION

RHCOS nodes are immutable — changes are applied via Operators, not SSH. SSH is a last resort when API/kubelet is down.

rhcos-only-supported-os-control-plane [IN] OBSERVATION

RHCOS is the only supported operating system for control plane nodes in OpenShift Container Platform 4.x; workers can optionally run RHEL.

rhcos-qcow2-not-supported-for-ztp [IN] OBSERVATION

QCOW2 images are not supported for ZTP; RHCOS images must match or be less than or equal to the OCP version being installed.

rhcos-rpm-ostree-updates [IN] OBSERVATION

RHCOS uses rpm-ostree for atomic in-place OS updates, with OS updates delivered as bootable container images

rhcos-ssh-core-user [IN] OBSERVATION

SSH access to RHCOS nodes uses the core user: ssh core@<node>.

rhcos-usr-readonly [IN] OBSERVATION

On RHCOS, /usr is read-only; /etc, /boot, and /var are writable but intended to be changed only by the MCO.

rhel-compute-nodes-deprecated-ocp-416 [IN] OBSERVATION

RHEL compute nodes are deprecated as of OpenShift Container Platform 4.16 and will be removed in a future release.

rhel-trusted-ca-path [IN] OBSERVATION

The trusted CA certificate path on RHEL is /etc/pki/ca-trust/source/anchors/, updated with sudo update-ca-trust enable.

rhel-worker-csr-approval-two-rounds [IN] OBSERVATION

Adding RHEL workers requires two rounds of CSR approval (client CSRs first, then server CSRs) within 1 hour before certificates rotate.

rhel-worker-csr-one-hour-deadline [IN] OBSERVATION

CSRs for new worker nodes must be approved within one hour before certificate rotation creates additional certificates.

rhel-worker-csr-two-rounds-approval [IN] OBSERVATION

Adding RHEL workers requires two rounds of CSR approval: first client CSRs (from node-bootstrapper), then server/serving CSRs (from system:node:*).

rhel-worker-fast-datapath-repo-required [IN] OBSERVATION

RHEL compute nodes require the fast-datapath-for-rhel-8-x86_64-rpms repo, but the playbook machine does not.

rhel-worker-firewalld-must-be-disabled [IN] OBSERVATION

firewalld must be permanently disabled on RHEL worker nodes; re-enabling it breaks log access.

rhel-worker-four-repos-required [IN] OBSERVATION

Four repos must be enabled for RHEL 8 workers on OCP 4.17: rhel-8-for-x8664-baseos-rpms, rhel-8-for-x8664-appstream-rpms, rhocp-4.17-for-rhel-8-x8664-rpms, fast-datapath-for-rhel-8-x8664-rpms.

rhel-worker-manual-api-update [IN] OBSERVATION

RHEL worker nodes require manual OpenShift API update before the MCO can update the kubelet on those machines.

rhel-worker-min-version-8-8 [IN] OBSERVATION

RHEL compute nodes require RHEL 8.8 or later; RHEL 7 is not supported and RHEL 7 nodes must be replaced, not upgraded.

rhel-worker-minimum-version-8-8 [IN] OBSERVATION

RHEL 7 is not supported for OCP 4.17 worker nodes; minimum is RHEL 8.8.

rhel-worker-package-based-deprecated [IN] OBSERVATION

Package-based RHEL compute worker support is deprecated and will be replaced by RHCOS image layering.

rhel-worker-scaleup-playbook-path [IN] OBSERVATION

The Ansible scaleup playbook for adding RHEL workers is at /usr/share/ansible/openshift-ansible/playbooks/scaleup.yml.

rhel-worker-swap-disabled [IN] OBSERVATION

Swap memory is disabled on all RHEL compute machines and cannot be re-enabled.

rhel-workers-control-plane-must-be-rhcos [IN] OBSERVATION

Control plane nodes must be RHCOS; only compute/worker nodes can be RHEL.

rhel-workers-deprecated-for-image-layering [IN] OBSERVATION

Package-based RHEL compute nodes are deprecated in favor of RHCOS image layering.

rhel-workers-only-not-control-plane [IN] OBSERVATION

RHEL can only be used for compute (worker) nodes, never for control plane nodes; control plane must run RHCOS.

rhel-workers-x86-64-only [IN] OBSERVATION

RHEL compute machines are supported only on x86_64 architecture in OpenShift Container Platform.

rhel7-workers-no-inplace-update [IN] OBSERVATION

RHEL 7 workers cannot be updated in-place during cluster updates — they must be replaced with RHEL 8 or RHCOS workers

rhoai-distributed-workloads-gpu-autoscaling [IN] OBSERVATION

OpenShift AI distributed workloads support GPU-aware auto-scaling for distributing data processing and training jobs across GPUs.

rhoai-feature-store-reusable-ml-features [IN] OBSERVATION

OpenShift AI Feature Store defines, stores, and serves reusable ML features to models across both training and serving pipelines.

rhoai-guardrails-safety-layer [IN] OBSERVATION

Guardrails is the OpenShift AI safety mechanism for filtering model input and output on deployed models.

rhoai-install-modes-connected-disconnected [IN] OBSERVATION

OpenShift AI Self-Managed supports two installation modes: standard (connected) and disconnected (air-gapped) environment.

rhoai-llamastack-openai-compatible-rag [IN] OBSERVATION

The LlamaStack operator in OpenShift AI enables OpenAI-compatible RAG APIs, integrating with vLLM and vector stores.

rhoai-lmeval-evaluation-framework [IN] OBSERVATION

LM-Eval is the OpenShift AI evaluation framework, configured via LMEvalJob CRDs for benchmarking model performance.

rhoai-model-registry-rbac-groups [IN] OBSERVATION

The OpenShift AI Model Registry provides cross-project model sharing with RBAC group-based access control and version lifecycle management.

rhoai-model-serving-kserve-two-modes [IN] OBSERVATION

OpenShift AI model serving uses KServe with two deployment modes: RawDeployment and Knative.

rhoai-no-upgrade-2x-to-3x [IN] OBSERVATION

There is no upgrade path from Red Hat OpenShift AI 2.x to 3.x; a fresh installation is required.

rhoai-pipelines-kfp-based [IN] OBSERVATION

OpenShift AI pipelines are based on Kubeflow Pipelines (KFP) with S3-compatible artifact storage.

rhoai-runs-as-operator-on-ocp [IN] OBSERVATION

Red Hat OpenShift AI Self-Managed runs as an operator on OpenShift Container Platform.

rhoai-telemetry-admin-controllable [IN] OBSERVATION

OpenShift AI telemetry (usage data collection) can be enabled or disabled by administrators.

rhoso-compact-topology-default [IN] OBSERVATION

RHOSO default topology is "compact" where RHOSO and RHOCP control planes share the same physical nodes on a 3-node compact cluster.

rhoso-control-plane-runs-on-rhocp [IN] OBSERVATION

RHOSO 18.0 deploys the OpenStack control plane as pods on a Red Hat OpenShift Container Platform cluster, while the data plane runs on external RHEL nodes.

rhoso-controlplane-crd-apiversion [IN] OBSERVATION

The OpenStackControlPlane CRD uses apiVersion core.openstack.org/v1beta1.

rhoso-data-plane-ansible-automation [IN] OBSERVATION

RHOSO data plane RHEL nodes are configured via Ansible automation execution environments run by the OpenStack Operator.

rhoso-disabled-services-default [IN] OBSERVATION

RHOSO services disabled by default: ironic, horizon, designate, octavia, heat, and manila.

rhoso-disconnected-deployment-supported [IN] OBSERVATION

RHOSO 18.0 supports disconnected (air-gapped) deployment.

rhoso-follows-platform-operator-pattern [IN] DERIVED

Red Hat OpenStack Services on OpenShift follows the same operator-driven platform pattern as OCP itself: a single master operator (openstack-operator) installed via OperatorHub manages all sub-operators, the control plane is defined by a CRD (OpenStackControlPlane at core.openstack.org/v1beta1), and the control plane runs as pods on RHOCP — making RHOSO a nested instance of the operator-driven immutable platform model.

rhoso-multiple-environments-single-cluster [IN] OBSERVATION

Multiple RHOSO environments can coexist on a single RHOCP cluster.

rhoso-nfs-below-v4-not-supported [IN] OBSERVATION

NFS versions earlier than 4 are not supported across RHOSO services (Cinder, Nova, Glance).

rhoso-only-x86-64-supported [IN] OBSERVATION

RHOSO supports only x86_64 architecture for RHOCP master and worker nodes.

rhoso-openstack-operator-master-operator [IN] OBSERVATION

The openstack-operator is the single master operator installed via OperatorHub that installs and manages all individual RHOSO service operators.

rhoso-requires-rhocp-418 [IN] OBSERVATION

RHOSO 18.0 requires RHOCP 4.18 as the hosting platform.

rhoso-succeeds-director-tripleo [IN] OBSERVATION

RHOSO 18.0 is the successor to director/TripleO-based RHOSP deployments; the adoption path is from RHOSP 17.1 or director Operator environments (migration, not in-place upgrade).

rocminfo-amd-gpu-diagnostic [IN] OBSERVATION

rocminfo is the diagnostic command for verifying AMD GPU detection in OpenShift (analogous to nvidia-smi for NVIDIA).

role-apis-authorization-openshift-io-v1 [IN] OBSERVATION

The OpenShift-native RBAC API objects (ClusterRole, ClusterRoleBinding, Role, RoleBinding, RoleBindingRestriction) belong to the authorization.openshift.io/v1 API group, distinct from the Kubernetes rbac.authorization.k8s.io/v1 API.

role-apis-compatibility-level-1 [IN] OBSERVATION

All five OpenShift authorization API objects (ClusterRole, ClusterRoleBinding, Role, RoleBinding, RoleBindingRestriction) are Compatibility Level 1 — stable within a major release for at least 12 months or 3 minor releases.

role-namespace-scoped-clusterrole-cluster-scoped [IN] OBSERVATION

Role is namespace-scoped while ClusterRole is cluster-scoped; RoleBinding is namespace-scoped while ClusterRoleBinding is cluster-scoped.

role-rules-field-required [IN] OBSERVATION

A Role object requires the rules field, which is an array of PolicyRule objects; each PolicyRule requires verbs and resources fields.

rolebinding-can-reference-clusterrole [IN] OBSERVATION

A namespaced RoleBinding can reference a ClusterRole, granting its permissions only within the RoleBinding's namespace.

rolebinding-clusterrole-namespace-scoped [IN] OBSERVATION

A RoleBinding referencing a ClusterRole grants those ClusterRole permissions only within the RoleBinding's namespace, not cluster-wide.

rolebinding-master-namespace-exception [IN] OBSERVATION

RoleBindings only have effect in the namespace where they exist, except in the master namespace which has power across all namespaces.

rolebinding-references-role-not-embeds [IN] OBSERVATION

A RoleBinding references a Role via roleRef — it does not contain or embed the Role. Required fields are subjects and roleRef.

rolebinding-usernames-groupnames-legacy [IN] OBSERVATION

The userNames and groupNames fields on RoleBinding are legacy backward-compatibility fields; modern clients should use the subjects field exclusively.

rolebindingrestriction-openshift-specific [IN] OBSERVATION

RoleBindingRestriction is an OpenShift-specific resource (not in upstream Kubernetes) that controls which subjects (users, groups, service accounts) are allowed to have rolebindings in a given namespace.

rolebindingrestriction-permissive-or-matching [IN] OBSERVATION

RoleBindingRestriction uses permissive/OR matching: if any RoleBindingRestriction in a namespace matches a subject, rolebindings for that subject are allowed.

rolebindingrestriction-three-subject-types [IN] OBSERVATION

RoleBindingRestriction supports three restriction types: userrestriction, grouprestriction, and serviceaccountrestriction.

rolling-default-deployment-strategy [IN] OBSERVATION

Rolling is the default deployment strategy for DeploymentConfig, providing zero-downtime deployments.

rollout-undo-disables-image-triggers [IN] OBSERVATION

oc rollout undo dc/<name> reverts to the last successful revision and disables image change triggers; they must be re-enabled with oc set triggers dc/<name> --auto.

rootless-dpdk-requires-vhostnet-tap-selinux [IN] OBSERVATION

Rootless DPDK workloads (OCP 4.14+) require needVhostNet: true in SriovNetworkNodePolicy, TAP CNI plugin, SELinux boolean containerusedevices=on, and a performance profile runtime class

rosa-classic-protected-managed-resources [IN] OBSERVATION

ROSA Classic has protected/managed resources that are managed exclusively by Red Hat SRE and cannot be modified by customers.

rosa-classic-uses-aws-sts [IN] OBSERVATION

ROSA Classic uses AWS Secure Token Service (STS) for its deployment workflow with short-lived credentials.

rosa-cli-tools-rosa-and-oc [IN] OBSERVATION

ROSA is managed via two CLI tools (ROSA CLI and oc CLI) plus the OpenShift Cluster Manager (OCM) web UI.

rosa-create-network-uses-cloudformation [IN] OBSERVATION

The rosa create network command wraps AWS CloudFormation for VPC infrastructure provisioning and requires ROSA CLI v1.2.48+.

rosa-default-cidr-ranges [IN] OBSERVATION

ROSA HCP defaults: Machine CIDR 10.0.0.0/16, Service CIDR 172.30.0.0/16, Pod CIDR 10.128.0.0/14, Host prefix /23.

rosa-default-compute-m5xlarge-2-nodes [IN] OBSERVATION

ROSA HCP default compute configuration is 2x m5.xlarge instances (4 vCPU, 16 GiB RAM) with no autoscaling.

rosa-default-storage-class-gp3-csi [IN] OBSERVATION

ROSA HCP default storage class is gp3-csi using the ebs.csi.aws.com provisioner with 300 GiB GP3 node volumes.

rosa-hcp-control-plane-in-redhat-account [IN] OBSERVATION

ROSA HCP (hosted control planes) runs the control plane in Red Hat's AWS account, not the customer's.

rosa-logging-not-installed-by-default [IN] OBSERVATION

The ROSA logging subsystem is not installed by default — it must be added and can forward logs to external services.

rosa-network-plugin-ovn-kubernetes [IN] OBSERVATION

ROSA uses OVN-Kubernetes as its network plugin (both HCP and classic architectures).

rosa-requires-three-clis [IN] OBSERVATION

ROSA installation requires three CLI tools: aws CLI, rosa CLI, and oc (OpenShift client).

rosa-reserved-ip-172-20-0-1 [IN] OBSERVATION

The IP address 172.20.0.1 is reserved for the internal Kubernetes API in ROSA and CIDRs must not conflict with it.

rosa-shared-responsibility-three-parties [IN] OBSERVATION

ROSA follows a shared responsibility model split between Red Hat, AWS, and the customer.

rosa-subnet-tagging-requirements [IN] OBSERVATION

ROSA requires public subnets tagged with kubernetes.io/role/elb and private subnets tagged with kubernetes.io/role/internal-elb.

rosa-supports-aws-govcloud [IN] OBSERVATION

ROSA supports deployment into AWS GovCloud regions for government workloads.

rosa-two-architectures-hcp-and-classic [IN] OBSERVATION

ROSA has two deployment architectures: default (Hosted Control Planes/HCP) and classic, each with separate documentation sets.

route-api-group [IN] OBSERVATION

Route is under route.openshift.io/v1 — OpenShift's native ingress mechanism, distinct from Kubernetes Ingress (networking.k8s.io/v1).

route-api-version [IN] OBSERVATION

The Route resource uses API version route.openshift.io/v1 and is Compatibility Level 1 (stable within a major release for 12 months or 3 minor releases)

route-backend-weights [IN] OBSERVATION

Route backend weights range 0–256 (default 100); weight 0 suppresses traffic; all-zero weights return 503

route-destination-ca-cert-reencrypt [IN] OBSERVATION

The destinationCACertificate field is used with reencrypt termination for validating the backend's certificate during health checks

route-header-action-limits [IN] OBSERVATION

Route HTTP header actions allow max 20 actions each for request and response headers; reserved headers (Strict-Transport-Security, Proxy, Cookie, Set-Cookie) cannot be modified

route-header-action-precedence [IN] OBSERVATION

Route request header actions execute after IngressController actions; Route response header actions execute before IngressController actions

route-host-immutable [IN] OBSERVATION

A Route's host field cannot be changed after creation; routers resolve host conflicts by preferring the oldest route

route-host-immutable-after-creation [IN] OBSERVATION

OpenShift Route host field is immutable after creation; oldest route wins on host conflicts

route-hostname-pattern [IN] OBSERVATION

Route hostname pattern is <route-name>.<route-namespace>.<domain> based on the Ingress config spec.domain

route-http2-requires-custom-cert [IN] OBSERVATION

HTTP/2 ALPN on OpenShift Routes requires a custom (non-wildcard) certificate — not supported with the default ingress certificate

route-insecure-edge-termination-default [IN] OBSERVATION

Route insecureEdgeTerminationPolicy defaults to None; options are None, Allow, and Redirect

route-max-four-backends [IN] OBSERVATION

A Route supports maximum 4 backends total: 1 primary (spec.to) plus up to 3 alternate backends (spec.alternateBackends), all must be Services

route-openshift-ingress-kubernetes [IN] OBSERVATION

Route is OpenShift-specific; Ingress is the Kubernetes-native equivalent.

route-passthrough-no-header-actions [IN] OBSERVATION

Passthrough routes are incompatible with HTTP header actions

route-tls-termination-types [IN] OBSERVATION

Route TLS termination types: edge (terminated at router, HTTP to backend), passthrough (no termination, direct to backend), reencrypt (terminated at router, re-encrypted to backend)

routing-via-host-disables-offload [IN] OBSERVATION

Setting routingViaHost to true causes pod egress to exit via ovn-k8s-mp0 into the host stack and disables hardware offload

rpm-ostree-atomic-upgrades [IN] OBSERVATION

rpm-ostree delivers transactional, atomic OS upgrades via container images with single-reboot rollback capability.

rukpak-tech-preview-ocp417 [IN] OBSERVATION

RukPak is Tech Preview (not GA) in OCP 4.17, representing the next-gen OLM packaging component using the BundleDeployment API.

runtime-operations-require-integrated-networking-and-resource-governance [IN] DERIVED

Running workloads require two independently governed infrastructure stacks simultaneously: the networking/observability stack (OVN-Kubernetes + Multus + eBPF flow collection + dual-stack addressing) provides connectivity and visibility, while the resource governance stack (autoscaling + scheduling + quotas + storage placement) controls capacity and placement — both operating within the identity and quota governance model

runtimeclass-api-group-node-k8s-io-v1 [IN] OBSERVATION

RuntimeClass uses API group node.k8s.io/v1 and is a cluster-scoped resource.

runtimeclass-handler-required-immutable-lowercase [IN] OBSERVATION

RuntimeClass handler field is required, immutable once set, and must be a lowercase DNS label conforming to RFC 1123.

runtimeclass-manually-defined [IN] OBSERVATION

RuntimeClass resources are manually defined by users or cluster provisioners — they are not auto-discovered.

runtimeclass-scheduling-nodeselector-merged [IN] OBSERVATION

RuntimeClass scheduling.nodeSelector is merged with the pod's existing nodeSelector during admission; conflicts cause admission rejection.

runtimeclass-tolerations-appended [IN] OBSERVATION

RuntimeClass scheduling.tolerations are appended (not replaced) to the pod's tolerations during admission, excluding duplicates.

s2i-build-steps-order [IN] OBSERVATION

S2I build steps execute in order: FROM builder image → copy source code → run assemble script → set run script as default command → Buildah creates the container image.

s2i-buildah-creates-final-image [IN] OBSERVATION

Buildah is the tool that creates the final container image after S2I completes its build steps.

s2i-builder-tilde-syntax [IN] OBSERVATION

Source-to-Image (S2I) builds use the builder~git-url syntax (e.g., python~https://github.com/...) to trigger a source build that creates a BuildConfig, ImageStream, Deployment, and Service.

s2i-custom-scripts-directory [IN] OBSERVATION

Custom S2I scripts are placed in the .s2i/bin/ directory of the application source (e.g., .s2i/bin/assemble, .s2i/bin/run).

s2i-images-developer-catalog [IN] OBSERVATION

Source-to-Image (S2I) runtime base images are accessible from the Developer perspective via +Add → Developer Catalog.

s2i-recommended-default-strategy [IN] OBSERVATION

Source-to-Image (S2I) is the recommended default build strategy — it produces consistent images without requiring a Dockerfile.

s2i-required-scripts [IN] OBSERVATION

The two required S2I scripts are assemble (build the app) and run (execute the app)

s2i-run-wrapper-must-use-exec [IN] OBSERVATION

When wrapping the S2I run script, you must use exec to invoke the default run script to ensure proper signal handling; no commands can follow the exec call.

s2i-script-search-order [IN] OBSERVATION

S2I script search order: (1) build config, (2) .s2i/bin in application source, (3) io.openshift.s2i.scripts-url label on builder image

s2i-scripts-url-label [IN] OBSERVATION

The S2I scripts location is stored in the io.openshift.s2i.scripts-url label on the builder image (typically image:///usr/libexec/s2i).

sa-automount-token-pod-overrides-sa [IN] OBSERVATION

automountServiceAccountToken: false on a ServiceAccount disables automatic token mounting, but pod-level settings override SA-level settings.

sa-enforce-mountable-secrets-annotation [IN] OBSERVATION

The annotation kubernetes.io/enforce-mountable-secrets must be set to "true" on a ServiceAccount to restrict which secrets a pod can mount via the SA's secrets list.

sa-imagepullsecrets-used-by-kubelet [IN] OBSERVATION

ServiceAccount imagePullSecrets are accessed by the kubelet (not the pod) for pulling container images and are not mountable into pods.

sa-issuer-trust-24h-default-expiration [IN] OBSERVATION

Service account issuer trust has a 24-hour default expiration for previously-used issuers in the KubeAPIServer resource

sa-namespace-scoped-resource [IN] OBSERVATION

ServiceAccounts are namespace-scoped resources accessed via /api/v1/namespaces/{namespace}/serviceaccounts.

sa-tokenrequest-api-recommended-for-external-tokens [IN] OBSERVATION

The recommended way to obtain ServiceAccount tokens for use outside pods is the TokenRequest API, not auto-generated SA token secrets.

samples-operator-architecture-change-requires-removed [IN] OBSERVATION

To change the Cluster Samples Operator architecture, you must set state to Removed first, then change architecture and set back to Managed

samples-operator-bootstrap-removed-conditions [IN] OBSERVATION

The Cluster Samples Operator bootstraps as Removed when: registry unreachable after 3 minutes on fresh install, IPv6 network detected, or image controller config prevents image stream creation

samples-operator-config-resource [IN] OBSERVATION

The Cluster Samples Operator config resource is configs.samples.operator.openshift.io, kind Config, name cluster; edited via oc edit configs.samples.operator.openshift.io/cluster

samples-operator-default-managed [IN] OBSERVATION

The Cluster Samples Operator default management state is Managed and default registry is registry.redhat.io

samples-operator-default-registry [IN] OBSERVATION

The Samples Operator default registry for sample ImageStreams is registry.redhat.io.

samples-operator-imagestreamtag-to-image-configmap [IN] OBSERVATION

The imagestreamtag-to-image config map in openshift-cluster-samples-operator namespace maps imagestream tags to image references for mirroring guidance

samples-operator-import-retry-15min [IN] OBSERVATION

Failed image stream tag imports are retried every ~15 minutes; failing-import alerts start 2 hours after installation when state is Managed

samples-operator-manages-openshift-namespace [IN] OBSERVATION

The Samples Operator manages sample ImageStreams and Templates in the openshift namespace.

samples-operator-removed-deletes-all [IN] OBSERVATION

Setting the Samples Operator managementState: Removed causes it to delete all managed ImageStreams, Templates, and the registry secret.

samples-operator-skipped-requires-manual-delete [IN] OBSERVATION

Using skippedImagestreams/skippedTemplates in the Samples Operator prevents recreation but does not delete existing resources — admins must manually delete them.

samples-operator-supported-architectures [IN] OBSERVATION

The Samples Operator supports three architectures: x86_64, ppc64le, and s390x.

samples-operator-three-management-states [IN] OBSERVATION

The Cluster Samples Operator has three management states: Managed (actively manages samples), Unmanaged (ignores updates), and Removed (deletes all managed content then behaves like Unmanaged)

sandboxed-containers-kata-runtime [IN] OBSERVATION

OpenShift sandboxed containers use Kata Containers to run pods inside lightweight VMs, providing hardware-virtualization-based isolation stronger than namespace/cgroup isolation.

sandboxed-containers-operator-kataconfig [IN] OBSERVATION

OpenShift sandboxed containers are deployed via the OpenShift sandboxed containers Operator, and the KataConfig CR triggers deployment of the Kata runtime on selected nodes.

sandboxed-containers-runtimeclass-kata [IN] OBSERVATION

Workloads opt into OpenShift sandboxed containers by setting runtimeClassName: kata in the pod spec.

sandboxed-containers-uses-kata-runtime [IN] OBSERVATION

OpenShift sandboxed containers use Kata Containers as the underlying runtime technology for workload isolation beyond standard container boundaries.

sandboxed-containers-versioned-separately [IN] OBSERVATION

OpenShift sandboxed containers is versioned separately from core OCP (e.g., version 1.11).

sandboxed-vs-kubevirt-distinction [IN] OBSERVATION

OpenShift sandboxed containers and OpenShift Virtualization (KubeVirt) both use virtualization but serve different purposes — KubeVirt runs full VMs as workloads, while sandboxed containers run standard container images in lightweight VMs for isolation.

sar-empty-namespace-means-all [IN] OBSERVATION

Empty string for namespace in SubjectAccessReview resourceAttributes means "all namespaces" for namespace-scoped resources

sar-spec-requires-one-of-resource-or-nonresource [IN] OBSERVATION

SubjectAccessReview spec must contain exactly one of resourceAttributes or nonResourceAttributes

scale-machineset-command [IN] OBSERVATION

The command to scale a MachineSet is oc scale --replicas=<n> machinesets.machine.openshift.io <name> -n openshift-machine-api.

scale-subresource-autoscaling-v1 [IN] OBSERVATION

The Scale subresource is part of autoscaling/v1 and is accessed via /{resource-name}/scale — not a top-level API object

scale-subresource-four-resource-types [IN] OBSERVATION

Four resource types support the Scale subresource: Deployment, ReplicaSet, StatefulSet, and ReplicationController

scc-allow-privilege-escalation-defaults-true [IN] OBSERVATION

allowPrivilegeEscalation in an SCC defaults to true if unset.

scc-api-group-security-openshift [IN] OBSERVATION

SecurityContextConstraints (SCC) is under the security.openshift.io/v1 API group — OpenShift-specific, not standard Kubernetes.

scc-api-group-security-openshift-io [IN] OBSERVATION

SecurityContextConstraints (SCCs) belong to the security.openshift.io API group.

scc-api-group-security-openshift-io-v1 [IN] OBSERVATION

SecurityContextConstraints use the API group security.openshift.io/v1; the old core Kubernetes API group exposure is deprecated.

scc-cluster-scoped-resource [IN] OBSERVATION

SecurityContextConstraints (SCCs) are cluster-scoped resources, not namespaced.

scc-grant-command-oc-adm-policy [IN] OBSERVATION

SCCs are granted to users/service accounts via oc adm policy add-scc-to-user <scc-name> -z <service-account>.

scc-migrating-to-security-openshift-io [IN] OBSERVATION

SCC is migrating from the core API group to security.openshift.io; the core API group exposure is deprecated

scc-openshift-specific-compatibility-level1 [IN] OBSERVATION

SecurityContextConstraints (SCCs) are OpenShift-specific (not standard Kubernetes), have Compatibility Level 1 (stable 12+ months), and are the primary mechanism for controlling pod security privileges in OpenShift

scc-primary-openshift-security-api [IN] OBSERVATION

SecurityContextConstraints (SCCs) are the primary OpenShift-specific security API object, controlling what a pod can and cannot do.

scc-priority-higher-first [IN] OBSERVATION

SCC priority field determines evaluation order: higher priority SCCs are tried first; ties are broken by most-restrictive-first, then by name.

scc-replaces-psp [IN] OBSERVATION

SecurityContextConstraints (SCCs) are OpenShift-specific security controls with no direct Kubernetes equivalent; PodSecurityPolicies are deprecated.

scc-required-drop-capabilities-cannot-readd [IN] OBSERVATION

Capabilities listed in requiredDropCapabilities are always dropped and cannot be re-added via allowedCapabilities.

scc-seven-required-boolean-fields [IN] OBSERVATION

SCCs have seven required boolean fields: allowHostDirVolumePlugin, allowHostIPC, allowHostNetwork, allowHostPID, allowHostPorts, allowPrivilegedContainer, readOnlyRootFilesystem.

scc-volume-whitelist-star-all-none-none [IN] OBSERVATION

SCC volumes field uses "*" to allow all volume types and ["none"] to allow none.

scheduled-reimport-flag [IN] OBSERVATION

oc tag <source> <stream>:<tag> --scheduled=true enables periodic re-import of a tag from an external registry.

scheduler-config-vs-operator-api [IN] OBSERVATION

The Scheduler config API (config.openshift.io/v1) defines scheduling profiles and policies, while the KubeScheduler operator API (operator.openshift.io/v1) manages how the scheduler is deployed

scheduler-default-node-selector-intersection [IN] OBSERVATION

The Scheduler resource's defaultNodeSelector creates an intersection with existing pod nodeSelectors (constrains further, does not replace).

scheduler-default-profile-low-node-utilization [IN] OBSERVATION

The default OpenShift scheduler profile is LowNodeUtilization, which spreads pods evenly across nodes

scheduler-masters-not-schedulable-by-default [IN] OBSERVATION

The Scheduler resource's mastersSchedulable defaults to false — master/control plane nodes do not run workload pods by default.

scheduler-ns-annotation-overrides-default-selector [IN] OBSERVATION

The namespace-level openshift.io/node-selector annotation overrides the cluster-wide defaultNodeSelector from the Scheduler config.

scheduler-policy-deprecated [IN] OBSERVATION

The Scheduler resource's policy field (ConfigMap-based custom scheduler policy in openshift-config) is deprecated, replaced by scheduling profiles.

scheduler-prefers-maximumvolumesize-over-capacity [IN] OBSERVATION

The kube-scheduler prefers maximumVolumeSize over capacity when filtering nodes for volume placement; if neither is set, the node is considered to have insufficient capacity.

scheduler-profile-config-object [IN] OBSERVATION

The scheduler profile is configured on the Scheduler object named cluster (API config.openshift.io/v1) via spec.profile, requiring cluster-admin role

scheduler-three-profiles [IN] OBSERVATION

The Scheduler resource supports three profiles: LowNodeUtilization (default, spreads pods), HighNodeUtilization (packs pods onto fewer nodes), and NoScoring (skips scoring for faster scheduling).

scheduler-three-step-process [IN] OBSERVATION

The default scheduler operates in 3 steps: (1) filter nodes using predicates, (2) prioritize using scoring functions (0–10 scale multiplied by weight), (3) select highest-scoring node with random tiebreaker

scheduling-constraints-multi-dimensional [IN] DERIVED

OpenShift pod scheduling operates across multiple constraint dimensions simultaneously: node selectors with six operators (In/NotIn/Exists/DoesNotExist/Gt/Lt), affinity/anti-affinity rules, taint effects (NoSchedule/PreferNoSchedule/NoExecute), scheduling gates (creation-time only), topology manager NUMA policies, and default node selectors that intersect with pod-level selectors — creating a constraint-satisfaction problem, not a simple placement decision.

scheduling-gates-set-at-creation-only [IN] OBSERVATION

Pod schedulingGates can only be set at creation time and removed afterward; they cannot be added post-creation.

sctp-enabled-via-machineconfig-kernel-module [IN] OBSERVATION

SCTP is enabled on OpenShift by loading the sctp kernel module via MachineConfig (clearing blacklist in /etc/modprobe.d/sctp-blacklist.conf and adding to /etc/modules-load.d/sctp-load.conf).

seccomp-cannot-apply-privileged-containers [IN] OBSERVATION

Seccomp profiles cannot be applied to privileged containers.

seccomp-pod-annotation-deprecated-417 [IN] OBSERVATION

The pod annotation method for seccomp (seccomp.security.alpha.kubernetes.io/pod) is deprecated in OCP 4.17; the current method uses seccompProfile.type: Localhost with localhostProfile in the security context.

seccomp-profiles-path-var-lib-kubelet [IN] OBSERVATION

Custom seccomp profiles are stored as JSON files at /var/lib/kubelet/seccomp/ on each node and must be deployed to all worker nodes via MachineConfig.

secondary-network-cr-types [IN] OBSERVATION

Secondary networks can be defined using either a UserDefinedNetwork CR or a NetworkAttachmentDefinition CR.

secret-data-base64-not-encrypted [IN] OBSERVATION

Kubernetes Secret data values are base64-encoded (not encrypted at rest by default), and total bytes of all values in data must be less than MaxSecretSize (1 MB)

secret-data-key-allowed-chars [IN] OBSERVATION

Keys in Secret data fields must consist of alphanumeric characters, -, _, or .

secret-immutable-field [IN] OBSERVATION

Setting immutable: true on a Secret prevents data modifications; only metadata can be changed afterward

secret-stringdata-write-only [IN] OBSERVATION

The Secret stringData field is write-only: it accepts plain strings on creation/update that are merged into data as base64, but is never returned in API responses

secret-type-tls-required-keys [IN] OBSERVATION

A Secret with type: kubernetes.io/tls requires the keys tls.crt and tls.key

secretlist-endpoint-read-only [IN] OBSERVATION

The ImageStream secrets endpoint is read-only (only GET is defined); secrets are managed through the core Secret API

secretlist-is-imagestream-subresource [IN] OBSERVATION

SecretList is accessed as a sub-resource of ImageStream via GET /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/secrets

secretlist-items-only-required-field [IN] OBSERVATION

The items field is the only required field in the SecretList resource

secrets-create-and-attach-syntax [IN] OBSERVATION

Secrets are created with oc create secret generic <name> --from-literal=KEY=VALUE and attached to deployments with oc set env --from=secret/<name> deploy/<name>.

security-and-governance-unified-across-all-topologies [IN] DERIVED

OpenShift enforces both software delivery governance (build→operator→console pipeline) and security enforcement (FIPS, TLS, SCCs, admission) as topology-invariant properties: whether the cluster is standalone HA, hosted control plane, or single-node edge, the same governance pipeline delivers software and the same security stack constrains it

security-and-governance-unified-enforcement-stack [IN] DERIVED

OpenShift enforces a unified security and governance stack: install-time locks (FIPS, CPU partitioning) set the foundation, identity management (OAuth→User→Identity) controls who, dual authorization (RBAC+SCC) controls what, node immutability (MCO pipeline) ensures infrastructure integrity — all reinforced by API admission and runtime TLS/IPsec enforcement.

security-api-compatibility-levels [IN] OBSERVATION

Security API compatibility levels: SCC is Level 1 (stable 12 months/4 minor releases), PodSecurityPolicy reviews are Level 2 (stable 9 months/3 minor releases), RangeAllocation is Level 4 (no guarantees)

security-constrains-entire-update-path [IN] DERIVED

Security enforcement shapes the entire progressive update path: install-time locks (FIPS, CPU partitioning) persist immutably through all updates, TLS profiles must be maintained during rolling upgrades across heterogeneous node fleets, and API stability tiers gate which deprecations can occur at each version boundary.

security-enforced-at-install-runtime-and-api-boundary [IN] DERIVED

OpenShift security operates as a three-layer enforcement model: install-time constraints lock FIPS mode and CPU partitioning permanently, runtime TLS profiles and IPsec govern network encryption, and API-boundary controls (webhooks with mandatory TLS, admission with 13s timeout cap, tiered stability guarantees) prevent unauthorized or unstable mutations — creating defense-in-depth from cluster birth through ongoing operations.

security-invariant-across-topology-variants [IN] DERIVED

Security enforcement is the invariant that holds across all topology variants: install-time locks (FIPS, CPU partitioning) apply regardless of whether control planes are standalone, hosted, or edge; TLS/IPsec spans all network topologies; and API governance prevents circumventing security via any operational model — divergent topologies cannot escape the unified security stack.

security-openshift-io-v1-mixed-tiers [IN] OBSERVATION

security.openshift.io/v1 is Tier 1 except RangeAllocation (Tier 4) and *Reviews (Tier 2).

self-provisioner-clusterrolebinding-controls-project-creation [IN] OBSERVATION

Project self-provisioning can be enabled or disabled cluster-wide by modifying the self-provisioner ClusterRoleBinding

self-provisioners-controls-project-creation [IN] OBSERVATION

Cluster admins can restrict project self-provisioning by removing the self-provisioners cluster role binding.

selfsubjectrulesreview-resource-vs-nonresource-rules [IN] OBSERVATION

SelfSubjectRulesReview status contains resourceRules (actions on API resources with K8s verbs) and nonResourceRules (actions on non-resource URL paths like /healthz with HTTP verbs).

selfsubjectrulesreview-results-can-be-incomplete [IN] OBSERVATION

SelfSubjectRulesReview results can be incomplete — the status.incomplete boolean and status.evaluationError string indicate this. However, authorization rules are additive: presence in the list confirms permission even if the list is incomplete.

selfsubjectrulesreview-ui-only [IN] OBSERVATION

SelfSubjectRulesReview should only be used for UI show/hide hints, NOT for driving external authorization decisions (confused deputy/cache concerns).

selfsubjectrulesreview-ui-only-not-for-authz [IN] OBSERVATION

SelfSubjectRulesReview (authorization.k8s.io/v1) is intended for UI display purposes only (show/hide actions); external systems should use SubjectAccessReview or LocalSubjectAccessReview for authorization decisions.

serverless-based-on-knative [IN] OBSERVATION

OpenShift Serverless is based on the open source Knative project and is the Red Hat enterprise distribution of Knative.

serverless-installed-via-operator [IN] OBSERVATION

OpenShift Serverless is installed and managed via the OpenShift Serverless Operator from OperatorHub.

serverless-installed-via-serverless-operator [IN] OBSERVATION

OpenShift Serverless is installed via the Serverless Operator, which manages Knative Serving and Knative Eventing components.

serverless-integrates-with-service-mesh [IN] OBSERVATION

OpenShift Serverless integrates with OpenShift Service Mesh.

serverless-is-knative-distribution [IN] OBSERVATION

OpenShift Serverless is Red Hat's distribution of Knative, providing Serving, Eventing, and Functions capabilities.

serverless-kn-cli [IN] OBSERVATION

The kn CLI is the primary Knative command-line client for managing serverless resources on OpenShift.

serverless-scale-to-zero [IN] OBSERVATION

OpenShift Serverless enables scale-to-zero behavior — pods are removed when there is no traffic and recreated on demand.

serverless-separate-release-cadence [IN] OBSERVATION

OpenShift Serverless releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.

serverless-two-components-serving-eventing [IN] OBSERVATION

OpenShift Serverless has two core components: Knative Serving (request-driven compute with scale-to-zero) and Knative Eventing (declarative event source and routing infrastructure).

service-account-issuer-24h-grace [IN] OBSERVATION

Changing spec.serviceAccountIssuer on the Authentication resource does not immediately invalidate existing tokens — a 24-hour grace period allows internal components to transition.

service-dual-stack-ipfamilypolicy [IN] OBSERVATION

Dual-stack Services use ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack) and ipFamilies (IPv4, IPv6); clusterIPs holds max two entries

service-external-traffic-policy-local [IN] OBSERVATION

externalTrafficPolicy: Local preserves client source IP but drops traffic on nodes with no local endpoints; default is Cluster

service-headless-clusterip-none [IN] OBSERVATION

A headless Service is created by setting clusterIP: "None" — no virtual IP allocated, endpoints published directly; used for StatefulSet peer discovery

service-healthcheck-nodeport-requirements [IN] OBSERVATION

healthCheckNodePort only applies when type=LoadBalancer AND externalTrafficPolicy=Local; lets external LBs probe endpoint availability

service-loadbalancerip-deprecated [IN] OBSERVATION

loadBalancerIP is deprecated; implementation-specific annotations should be used instead

service-mesh-3x-based-on-istio-sail [IN] OBSERVATION

Red Hat OpenShift Service Mesh 3.x is now generally available and is based on Istio Sail rather than Maistra (used by 2.x).

service-mesh-3x-uses-sail-operator [IN] OBSERVATION

OpenShift Service Mesh 3.x is built on upstream Istio with the Sail Operator, replacing the older Maistra-based approach from 2.x.

service-mesh-based-on-istio [IN] OBSERVATION

Red Hat OpenShift Service Mesh 2.x is based on the open source Istio project, with additional components: Envoy Proxy (sidecar), Kiali (observability console), and Jaeger/Tempo (distributed tracing).

service-mesh-control-plane-istio-system [IN] OBSERVATION

The Service Mesh control plane (SMCP) is typically installed in the istio-system namespace.

service-mesh-current-version-3x [IN] OBSERVATION

OpenShift Service Mesh 3.x (up to 3.2) is the current major version line, separate from the older 2.x line.

service-mesh-four-core-capabilities [IN] OBSERVATION

OpenShift Service Mesh provides four core capabilities: traffic management, service identity and security, policy enforcement, and telemetry.

service-mesh-multi-operator-architecture [IN] DERIVED

OpenShift Service Mesh operates as a multi-operator, multi-tenant system: it requires installing multiple operators (Service Mesh, Kiali, tracing), defaults to multi-tenant isolation (unlike upstream Istio), uses Istio Sail (replacing Maistra in 3.x), and integrates with Serverless.

service-mesh-multi-tenant-default [IN] OBSERVATION

OpenShift Service Mesh is multi-tenant by default, unlike upstream Istio which uses a single-tenant cluster-wide model; scope is limited to namespaces listed in the ServiceMeshMemberRoll.

service-mesh-no-code-changes [IN] OBSERVATION

Service Mesh does not require application code changes — it works transparently via sidecar proxies that intercept traffic between services.

service-mesh-provides-traffic-observability-mtls [IN] OBSERVATION

OpenShift Service Mesh provides traffic management, observability, and security (mTLS) between microservices.

service-mesh-requires-multiple-operators [IN] OBSERVATION

Service Mesh requires multiple operators to be installed: the Red Hat OpenShift Service Mesh Operator, Kiali Operator, and a tracing operator (Jaeger or Tempo).

service-network-single-entry [IN] OBSERVATION

serviceNetwork currently supports only a single entry

service-nodeport-range-default-mutable [IN] OBSERVATION

serviceNodePortRange defaults to 30000-32767 and can be changed post-install (unlike most Network spec fields)

service-port-only-required-field [IN] OBSERVATION

port is the only required field in a ServicePort definition; targetPort defaults to the port value if omitted

service-publish-not-ready-addresses [IN] OBSERVATION

publishNotReadyAddresses: true treats all endpoints as ready; critical for StatefulSet peer discovery via SRV DNS records

service-session-affinity-clientip-timeout [IN] OBSERVATION

Service sessionAffinity supports ClientIP or None (default); ClientIP sticky timeout defaults to 10800s (3 hours), max 86400s (1 day)

service-types-hierarchy [IN] OBSERVATION

Service types form a hierarchy: ClusterIP (default) → NodePort (adds node port) → LoadBalancer (adds external LB); ExternalName is separate (CNAME only, no proxying)

serviceca-manages-serving-cert-signer [IN] OBSERVATION

The ServiceCA resource (operator.openshift.io/v1) configures the operator that manages the service serving certificate signer, responsible for automatic TLS cert generation for services

servicemonitor-auth-mutually-exclusive [IN] OBSERVATION

ServiceMonitor endpoint authentication options (authorization, basicAuth, oauth2) are mutually exclusive

servicemonitor-honor-labels-preserves-collisions [IN] OBSERVATION

In ServiceMonitor, honorLabels: true preserves the metric's own labels when they collide with target labels

servicemonitor-joblabel-from-service [IN] OBSERVATION

ServiceMonitor's jobLabel field selects a label from the associated Service to use as the Prometheus job label; defaults to Service name if unset

servicemonitor-only-required-field-selector [IN] OBSERVATION

The only required field under ServiceMonitor .spec is selector — a label selector for Endpoints discovery

servicemonitor-port-vs-targetport [IN] OBSERVATION

In ServiceMonitor endpoints, port refers to the Service port name and targetPort refers to the Pod container port; port takes precedence when both are specified

servicemonitor-sample-limit-fails-scrape [IN] OBSERVATION

ServiceMonitor's sampleLimit controls the per-scrape limit on accepted samples; exceeding it causes the scrape to fail

servicemonitor-vs-podmonitor [IN] OBSERVATION

ServiceMonitor selects monitoring targets by matching services; PodMonitor selects monitoring targets by matching pods directly. Both are monitoring.coreos.com/v1.

shared-resource-csi-driver-deprecated [IN] OBSERVATION

The Shared Resource CSI Driver is deprecated in OCP; it migrated to Builds for Red Hat OpenShift 1.1.

shared-resources-csi-driver-for-builds [IN] OBSERVATION

The Shared Resources CSI Driver is a component that integrates with Builds for Red Hat OpenShift, enabling shared resources (secrets/ConfigMaps) to be mounted into build pods.

shared-templates-openshift-namespace [IN] OBSERVATION

The openshift namespace contains cluster-level shared templates available to all projects

shipwright-builds-from-source-and-dockerfiles [IN] OBSERVATION

Shipwright can build container images from both source code and Dockerfiles.

shipwright-builds-from-source-dockerfiles-local [IN] OBSERVATION

Shipwright can build container images from source code (including local directories), and Dockerfiles.

shipwright-builds-run-on-cluster [IN] OBSERVATION

Shipwright builds execute within the OpenShift cluster itself, not externally.

shipwright-cli-distinct-from-oc [IN] OBSERVATION

The Shipwright CLI is a separate tool from oc used for creating builds, viewing build run logs, and managing builds on the cluster.

shipwright-distinct-from-legacy-buildconfig [IN] OBSERVATION

Shipwright-based Builds is distinct from and replaces the legacy OpenShift Build system based on BuildConfig objects and oc start-build.

shipwright-independent-release-cadence [IN] OBSERVATION

Builds (Shipwright) releases on a different cadence from OpenShift Container Platform itself and has its own separate documentation set at docs.redhat.com.

shipwright-is-extensible-build-framework [IN] OBSERVATION

Shipwright is an extensible, Kubernetes-native build framework for building container images on OpenShift Container Platform clusters, based on the upstream Shipwright project (shipwright.io).

shipwright-runs-on-cluster [IN] OBSERVATION

Shipwright builds run on-cluster within the OpenShift environment, not externally.

shipwright-supports-s2i-and-buildah [IN] OBSERVATION

Shipwright-based Builds supports both Source-to-Image (S2I) and Buildah as build strategies.

shipwright-supports-s2i-buildah-custom-strategies [IN] OBSERVATION

Shipwright-based Builds supports three build strategy types: Source-to-Image (S2I), Buildah, and custom user-defined strategies.

signature-condition-types-complete-or-failed [IN] OBSERVATION

Image signature condition types are exactly two: Complete and Failed, with status values of True, False, or Unknown.

sigstore-fulcio-keyless-signing-via-oidc [IN] OBSERVATION

Sigstore enables key-less container image signing using OIDC identity via the Fulcio certificate authority, eliminating traditional key management.

sigstore-rekor-immutable-transparency-log [IN] OBSERVATION

Rekor is the sigstore component that records signature metadata to an immutable, tamper-resistant transparency log.

sigstore-signatures-colocated-in-registry [IN] OBSERVATION

Sigstore signatures are stored in the same container registry as the build images, requiring no separate signature server.

silence-management-roles [IN] OBSERVATION

Non-admin users need both cluster-monitoring-view and monitoring-alertmanager-edit roles to manage silences; monitoring-rules-edit role is needed to create alerting rules in user projects.

silences-require-persistent-storage [IN] OBSERVATION

Alertmanager silences are replicated across Alertmanager pods but require persistent storage to survive pod restarts.

single-nic-nodes-must-use-br-ex [IN] OBSERVATION

Single-NIC nodes must use br-ex for localnet bridge mappings; multi-NIC nodes can use a dedicated bridge for traffic isolation.

single-node-cannot-mix-gpu-types [IN] OBSERVATION

Worker nodes with GPUs must have all GPUs of the same type — mixing GPU models on a single node is not supported by the NVIDIA Device Plugin.

singleton-resource-naming-convention [IN] DERIVED

Multiple OpenShift operators enforce a singleton naming convention where the CR must be named a specific value (typically cluster or default): OAuth, Console, FlowCollector, ClusterAutoscaler, Storage operator, and PowerMonitor each reject other names.

smm-allows-project-admin-join-mesh [IN] OBSERVATION

A ServiceMeshMember (SMM) resource allows project admins to add their namespace to a mesh without needing cluster-admin to edit the SMMR.

smmr-must-be-named-default [IN] OBSERVATION

The ServiceMeshMemberRoll (SMMR) must be named default and must reside in the same namespace as the ServiceMeshControlPlane (SMCP).

snapshot-pattern-mirrors-pvc-pv-storageclass [IN] OBSERVATION

The VolumeSnapshot/VolumeSnapshotContent/VolumeSnapshotClass pattern mirrors the PVC/PV/StorageClass pattern: VolumeSnapshot is the user request, VolumeSnapshotContent is the backing object, VolumeSnapshotClass defines provider parameters.

sno-composable-required-capabilities [IN] OBSERVATION

Required capabilities for SNO vDU with baselineCapabilitySet: None: NodeTuning (4.13+), OperatorLifecycleManager (4.15+), and Ingress (4.16+).

sno-dns-api-int-required [IN] OBSERVATION

DNS must resolve api-int.<clustername>.<basedomain> for worker node addition to an SNO cluster.

sno-dns-records-api-apiint-apps [IN] OBSERVATION

SNO clusters require three DNS records: api.<cluster>.<domain>, api-int.<cluster>.<domain>, and *.apps.<cluster>.<domain>.

sno-expansion-no-downtime [IN] OBSERVATION

Adding worker nodes to a single-node OpenShift cluster requires no downtime and the original node retains its control plane role.

sno-expansion-tech-preview-417 [IN] OBSERVATION

SNO cluster expansion by adding worker nodes is a Technology Preview feature in OCP 4.17 (not supported under production SLAs).

sno-ingress-routes-to-control-plane [IN] OBSERVATION

All ingress traffic routes to the single control-plane node by default in SNO, even after adding worker nodes.

sno-install-methods [IN] OBSERVATION

SNO can be installed via the Assisted Installer, agent-based installer, or manual UPI.

sno-key-edge-topology [IN] OBSERVATION

Single-Node OpenShift (SNO) is a key topology for edge deployments, running both control plane and workloads on a single node.

sno-max-worker-nodes-2 [IN] OBSERVATION

Single-node OpenShift (SNO) clusters support a tested maximum of 2 worker nodes; exceeding this may cause performance degradation or cluster failure.

sno-no-high-availability [IN] OBSERVATION

SNO does not provide high availability — etcd runs as a single instance.

sno-reduced-capability-profile [IN] DERIVED

Single-node OpenShift has a constrained operational profile: no live migration or HA for VMs, SR-IOV requires disabling drain, and worker node expansion requires OCP 4.11+.

sno-single-node-control-and-worker [IN] OBSERVATION

Single Node OpenShift (SNO) runs both control plane and worker roles on a single node, combining etcd, API server, controllers, and workloads on one host.

sno-static-ip-all-same-address [IN] OBSERVATION

For SNO with static IPs, the node-specific, API, and Ingress IPs should all be the same address.

sno-supported-production-topology [IN] OBSERVATION

Single Node OpenShift (SNO) is a supported production configuration, not limited to development or testing.

sno-update-requires-downtime [IN] OBSERVATION

Single-node OpenShift (SNO) updates require downtime; no MHC pause is needed, node draining is skipped, and there is no automatic rollback on failure

sno-worker-csr-approval-required [IN] OBSERVATION

CSR approval is mandatory to complete worker node installation on SNO clusters.

sno-worker-min-requirements [IN] OBSERVATION

SNO worker node minimum requirements: 2 vCPU, 8 GB RAM, 100 GB storage.

sno-worker-requires-ocp-411 [IN] OBSERVATION

Adding worker nodes to SNO requires OpenShift Container Platform 4.11 or later.

sno-workers-no-ha-no-control-plane-expansion [IN] OBSERVATION

Adding worker nodes to SNO does NOT provide high availability and does NOT expand the control plane.

sno-workload-partitioning-before-worker-install [IN] OBSERVATION

Workload partitioning policies must be deployed and remediated on the hub cluster before installing the worker node; doing it after requires manual drain and pod deletion.

spec-oauth-metadata-takes-precedence [IN] OBSERVATION

spec.oauthMetadata takes precedence over status.integratedOAuthMetadata on the Authentication resource.

sriov-bypasses-kernel-networking-stack [IN] OBSERVATION

SR-IOV provides near-native I/O performance by bypassing the kernel networking stack, exposing virtual functions (VFs) directly to pods while the physical function (PF) remains on the host.

sriov-config-daemon-daemonset [IN] OBSERVATION

The SR-IOV network config daemon runs as a DaemonSet on worker nodes, discovering and initializing SR-IOV devices.

sriov-enables-near-native-network-performance [IN] OBSERVATION

SR-IOV (Single Root I/O Virtualization) enables near-native network performance by allowing pods direct access to virtual functions (VFs) on physical NICs.

sriov-injector-first-container-only [IN] OBSERVATION

The SR-IOV Network resources injector adds the resource field to only the first container in a pod.

sriov-key-for-telco-nfv-workloads [IN] OBSERVATION

SR-IOV is a key technology for telco/NFV and low-latency use cases on OpenShift.

sriov-managed-by-sriov-network-operator [IN] OBSERVATION

SR-IOV functionality in OpenShift is managed by the SR-IOV Network Operator, installed via OperatorHub/OLM.

sriov-multi-network-policy-tech-preview [IN] OBSERVATION

Multi-network policies on SR-IOV networks are Technology Preview, supported for kernel NICs only, and not supported for DPDK applications.

sriov-multicast-net-admin-for-multicast-ip [IN] OBSERVATION

NET_ADMIN capability is required in a pod only when the application needs to assign a multicast IP address to the SR-IOV interface.

sriov-multicast-physical-network-controls-routing [IN] OBSERVATION

The physical network infrastructure (not OpenShift) controls multicast routing and topology for SR-IOV interfaces.

sriov-multicast-routes-224-and-232 [IN] OBSERVATION

SR-IOV multicast IPAM must include routes 224.0.0.0/5 and 232.0.0.0/5 to override the default network provider's static multicast routes.

sriov-network-policy-may-drain-reboot-nodes [IN] OBSERVATION

Applying an SriovNetworkNodePolicy may drain and reboot nodes; sufficient available nodes must exist for evicted workloads

sriov-network-resources-injector-on-control-plane [IN] OBSERVATION

The SR-IOV Network Resources Injector and Operator Webhook both run as DaemonSets on control plane nodes.

sriov-node-drain-before-policy-change [IN] OBSERVATION

The SR-IOV Operator performs node draining before every policy change by default; this must be disabled for single-node clusters.

sriov-node-label [IN] OBSERVATION

The node label to mark SR-IOV-capable nodes is feature.node.kubernetes.io/network-sriov.capable="true".

sriov-node-selector-capability-label [IN] OBSERVATION

SR-IOV network node policies use the node selector label feature.node.kubernetes.io/network-sriov.capable: "true" to target SR-IOV capable nodes.

sriov-operator-config-default-cr [IN] OBSERVATION

The SriovOperatorConfig CR (named default) controls enablement of the SR-IOV webhook and resources injector, both enabled by default.

sriov-operator-config-named-default [IN] OBSERVATION

The SriovOperatorConfig CR must be named default in the openshift-sriov-network-operator namespace — no other name is valid.

sriov-operator-creates-nads [IN] OBSERVATION

The SR-IOV Network Operator automatically creates NetworkAttachmentDefinitions when SriovNetwork CRs are defined

sriov-operator-namespace [IN] OBSERVATION

All SR-IOV Network Operator resources live in the openshift-sriov-network-operator namespace

sriov-operator-required-for-hardware-networks [IN] OBSERVATION

The SR-IOV Network Operator is required to manage SR-IOV resources in OpenShift, discovering SR-IOV-capable devices and configuring virtual functions.

sriov-primary-hw-network-tech [IN] OBSERVATION

SR-IOV (Single Root I/O Virtualization) is the primary hardware networking technology in OpenShift, allowing a single physical NIC to present multiple virtual functions to pods for near-native network performance

sriov-requires-bare-metal-hardware [IN] OBSERVATION

SR-IOV Operator installation requires bare-metal hardware with SR-IOV-capable NICs.

sriov-sno-disable-drain [IN] OBSERVATION

For single-node OpenShift, the SR-IOV Operator requires disableDrain: true and annotation workload.openshift.io/allowed=management on the namespace.

sriov-supported-bare-metal-rhosp-only [IN] OBSERVATION

SR-IOV is supported only on bare metal and Red Hat OpenStack Platform (RHOSP) — not on cloud platforms like AWS/Azure/GCP.

sriov-two-driver-modes [IN] OBSERVATION

SR-IOV has two driver modes: netdevice (exposes VF as kernel network device) and vfio-pci (exposes VF as character device).

starting-csv-requires-manual-approval [IN] OBSERVATION

Setting startingCSV in a Subscription to pin a specific Operator version requires installPlanApproval: Manual.

statefulset-default-pod-management-orderedready [IN] OBSERVATION

StatefulSet default pod management policy is OrderedReady — pods created sequentially (0, 1, 2…) and scaled down in reverse order.

statefulset-default-update-strategy-rollingupdate [IN] OBSERVATION

StatefulSet default update strategy is RollingUpdate; the alternative OnDelete requires manual pod deletion to trigger updates.

statefulset-partition-enables-canary-deployments [IN] OBSERVATION

Setting partition in a StatefulSet RollingUpdate only updates pods with ordinal >= partition value, enabling canary deployments.

statefulset-pod-naming-convention [IN] OBSERVATION

StatefulSet pods are named <statefulsetname>-<podindex> (e.g., web-0, web-1, web-2).

statefulset-pvc-retention-default-retain [IN] OBSERVATION

StatefulSet PVC retention default is Retain — PVCs are NOT deleted when the StatefulSet is deleted or scaled down.

statefulset-replicas-default-one [IN] OBSERVATION

StatefulSet replicas defaults to 1 if unspecified.

statefulset-requires-preexisting-headless-service [IN] OBSERVATION

A StatefulSet's serviceName field is required and must reference a pre-existing headless Service that provides network identity.

statefulset-restart-policy-always-only [IN] OBSERVATION

The only allowed restartPolicy in a StatefulSet pod template is Always.

statefulsets-for-stable-identity-storage [IN] OBSERVATION

StatefulSets are for applications needing stable identity/numbering and independent storage (e.g., databases, ZooKeeper).

static-pod-operator-default-revision-limit-5 [IN] OBSERVATION

Default revision limits (failedRevisionLimit and succeededRevisionLimit) for static pod operators are 5 when set to 0 or unset

static-pods-cannot-use-secrets-or-configmaps [IN] OBSERVATION

Static pods are automatically restarted by the kubelet on node reboot but cannot use Secrets or ConfigMaps.

storage-api-groups-distribution [IN] OBSERVATION

OCP storage APIs span multiple API groups: v1 (core — PV/PVC), storage.k8s.io (StorageClass, CSI objects), and snapshot.storage.k8s.io (VolumeSnapshot resources).

storage-lifecycle-from-provisioning-to-reclaim [IN] DERIVED

OpenShift storage follows a complete lifecycle model: CSI plugin architecture provides the backend, PVCs progress through three phases (Pending→Bound→Lost) with indefinite waiting semantics, StorageClass defaults to Delete reclaim policy, and ClusterCSIDriver enforces platform-specific limits (e.g., vSphere 3-snapshot cap) — creating a governed resource lifecycle from claim through cleanup.

storage-object-in-use-protection-default [IN] OBSERVATION

Storage Object in Use Protection is enabled by default in OCP, preventing deletion of PVCs actively used by pods and PVs bound to PVCs.

storage-operator-singleton-named-cluster [IN] OBSERVATION

The Storage operator CR (operator.openshift.io/v1) singleton instance must be named cluster

storage-scope-nonnamespaced-resources [IN] OBSERVATION

CSIDriver, StorageClass, VolumeAttachment, and VolumeSnapshotClass are non-namespaced (cluster-scoped) resources.

storageclass-allowvolumeexpansion-required-for-resize [IN] OBSERVATION

allowVolumeExpansion: true must be set on the StorageClass to permit PVC resizing.

storageclass-default-reclaimpolicy-delete [IN] OBSERVATION

The default reclaimPolicy for dynamically provisioned PersistentVolumes is Delete.

storageclass-globally-scoped [IN] OBSERVATION

StorageClass objects are globally scoped (not namespaced) and must be created by cluster-admin or storage-admin users.

storageclass-mountoptions-not-validated-at-creation [IN] OBSERVATION

StorageClass mountOptions are not validated at creation time; invalid options only cause failures at mount time.

storageclass-provisioner-only-required-field [IN] OBSERVATION

The provisioner field is the only required field on a StorageClass resource.

storageclass-waitforfirstconsumer-delays-binding [IN] OBSERVATION

volumeBindingMode: WaitForFirstConsumer delays PVC binding and provisioning until a Pod referencing the PVC is scheduled, enabling topology-aware provisioning.

storagestate-api-group-v1alpha1 [IN] OBSERVATION

StorageState is in the migration.k8s.io/v1alpha1 API group (alpha-level API).

storagestate-current-hash-from-discovery [IN] OBSERVATION

The currentStorageVersionHash in StorageState comes from the API server's discovery document, not from the StorageState spec.

storagestate-storageversionmigration-alpha [IN] OBSERVATION

StorageState and StorageVersionMigration are v1alpha1 APIs in the migration.k8s.io API group.

storagestate-unknown-hash-blocks-upgrade [IN] OBSERVATION

If "Unknown" is present in persistedStorageVersionHashes, it is not safe to upgrade or downgrade the API server.

storageversionmigration-resource-target-three-fields [IN] OBSERVATION

StorageVersionMigration targets a resource using three fields: group, resource, and version.

storageversionmigration-spec-resource-immutable [IN] OBSERVATION

The StorageVersionMigration .spec.resource field is immutable after creation.

sts-workload-id-requires-manual-approval [IN] OBSERVATION

Clusters using AWS STS, Microsoft Entra Workload ID, or GCP Workload Identity must use Manual approval strategy for Operator subscriptions.

subjectaccessreview-cluster-scoped [IN] OBSERVATION

SubjectAccessReview is cluster-scoped (not namespaced) — accessed via a single endpoint POST /apis/authorization.k8s.io/v1/subjectaccessreviews

submariner-l3-vs-service-interconnect-l7 [IN] OBSERVATION

Submariner provides layer 3 inter-cluster networking; Red Hat Service Interconnect provides layer 7 inter-cluster networking

subscription-api-group-v1alpha1 [IN] OBSERVATION

The Subscription resource uses API group operators.coreos.com/v1alpha1

subscription-config-env-resources-immutable [IN] OBSERVATION

Subscription spec.config.env and spec.config.resources are immutable after creation

subscription-config-fields [IN] OBSERVATION

The Subscription config section supports: env, envFrom, volumes, volumeMounts, tolerations, resources, and nodeSelector.

subscription-config-scheduling-overrides [IN] OBSERVATION

Subscription spec.config supports nodeSelector, tolerations, and affinity to control operator pod placement (e.g., placing operators on infrastructure nodes)

subscription-installplanapproval-values [IN] OBSERVATION

Subscription installPlanApproval has exactly two valid values: Automatic and Manual

subscription-required-spec-fields [IN] OBSERVATION

Subscription required spec fields are name, source, and sourceNamespace

subscription-specifies-channel-source-approval [IN] OBSERVATION

A Subscription specifies the channel, source, and approval strategy (Automatic vs Manual) for Operator updates.

subscription-startingcsv-pins-version [IN] OBSERVATION

Subscription startingCSV optionally pins the initial ClusterServiceVersion; without it, the latest in the channel is installed

subscription-triggers-installplan-then-csv [IN] OBSERVATION

A Subscription triggers OLM to resolve and create an InstallPlan, which when approved installs the ClusterServiceVersion (CSV).

support-case-filed-via-customer-portal [IN] OBSERVATION

Support cases are filed through the Red Hat Customer Portal at access.redhat.com

support-case-requires-subscription [IN] OBSERVATION

Filing a Red Hat support case requires a Red Hat Standard or Premium subscription

system-authenticated-unauthenticated-virtual-groups [IN] OBSERVATION

system:authenticated and system:unauthenticated are virtual groups automatically assigned to users based on authentication status

system-node-critical-higher-than-system-cluster-critical [IN] OBSERVATION

The system-node-critical priority class has higher priority than system-cluster-critical.

tag-reference-true-prevents-import [IN] OBSERVATION

Setting tag.reference=true on an ImageStreamTag or ImageTag spec means the tag will NOT be imported

talm-applies-policies-wave-order [IN] OBSERVATION

TALM (Topology Aware Lifecycle Manager) applies ZTP policies in wave order using the ran.openshift.io/ztp-deploy-wave annotation and automatically creates a ClusterGroupUpgrade CR.

talm-batch-timeout-action-default-continue [IN] OBSERVATION

TALM's batchTimeoutAction defaults to continue (skip failing clusters); can be set to abort to stop all remediation.

talm-canary-failure-stops-update [IN] OBSERVATION

In TALM, canary clusters are updated first (each in its own batch), and any failure in a canary cluster stops the entire update process.

talm-cgu-cr-primary-resource [IN] OBSERVATION

The ClusterGroupUpgrade (CGU) CR (ran.openshift.io/v1alpha1) is TALM's primary resource, defining clusters, policies, concurrency, canaries, timeouts, and actions.

talm-completed-cgu-cannot-be-reused [IN] OBSERVATION

A completed TALM ClusterGroupUpgrade CR cannot be reused — a new CGU CR must be created for subsequent updates.

talm-controller-deployment-name [IN] OBSERVATION

The TALM controller deployment is named cluster-group-upgrades-controller-manager in the openshift-operators namespace.

talm-policies-must-be-inform [IN] OBSERVATION

Policies used with TALM must have remediationAction: inform — TALM handles the enforce lifecycle itself.

talm-precaching-for-sno-limited-bandwidth [IN] OBSERVATION

TALM's pre-caching feature (preCaching: true) is designed for Single-Node OpenShift clusters with limited bandwidth; TALM checks disk space before caching images.

talm-requires-rhacm-29 [IN] OBSERVATION

The Topology Aware Lifecycle Manager (TALM) requires Red Hat Advanced Cluster Management (RHACM) 2.9 or later.

tang-hide-old-keys-dot-prefix [IN] OBSERVATION

To stop advertising old Tang keys while still allowing decryption, rename .jwk files with a dot prefix (e.g., .key.jwk).

tang-keys-stored-var-db-tang [IN] OBSERVATION

Tang server keys are stored in /var/db/tang as .jwk files; new keys are generated by /usr/libexec/tangd-keygen /var/db/tang.

tang-rekey-order-critical [IN] OBSERVATION

Tang rekeying order: generate new key → rekey all nodes → delete old key. Deleting the old key before all nodes are rekeyed will make those nodes unbootable.

tang-server-stateless-no-tls [IN] OBSERVATION

Tang is a stateless server that requires no TLS, no authentication, and never stores or learns node encryption keys.

tekton-concept-mapping-from-jenkins [IN] OBSERVATION

Jenkins-to-Tekton concept mapping: Jenkins Pipeline maps to Pipeline + PipelineRun, Jenkins Stage maps to Task, Jenkins Step maps to a step within a Task.

tekton-every-step-runs-as-container-in-pod [IN] OBSERVATION

Every step in OpenShift Pipelines runs as a container in a pod.

tekton-hub-replaces-jenkins-plugins [IN] OBSERVATION

Tekton Hub replaces Jenkins plugins as the extensibility mechanism, providing a catalog of reusable community tasks.

tekton-runafter-controls-task-order [IN] OBSERVATION

The runAfter field controls task execution order in a Tekton pipeline.

tekton-uses-openshift-rbac-not-plugin [IN] OBSERVATION

OpenShift Pipelines uses OpenShift's built-in RBAC for authorization instead of a plugin like Jenkins.

tekton-workspace-triple-duty [IN] OBSERVATION

Tekton Workspaces serve triple duty: storage for inputs/outputs/artifacts, shared data among tasks, and mount points for secrets/configmaps.

telemetry-and-insights-enabled-by-default [IN] OBSERVATION

Both Telemetry and the Insights Operator are installed and enabled by default on OpenShift clusters

telemetry-insights-enabled-by-default [IN] OBSERVATION

Telemetry and the Insights Operator are enabled by default in connected OpenShift clusters.

telemetry-interval-4m30s [IN] OBSERVATION

The Telemeter Client sends Prometheus metrics to Red Hat every 4 minutes and 30 seconds

telemetry-upload-interval-4m30s [IN] OBSERVATION

The Telemetry client gathers and uploads metrics to Red Hat every 4 minutes and 30 seconds.

telemetry-view-requires-cluster-admin-or-monitoring-view [IN] OBSERVATION

Viewing telemetry data requires the cluster-admin or cluster-monitoring-view role

telemetry-vs-insights-operator-distinction [IN] OBSERVATION

Telemetry collects metrics and usage data, while the Insights Operator gathers anonymized cluster configuration and provides actionable recommendations via Red Hat Insights analysis.

template-api-objects-three-types [IN] OBSERVATION

The Template API category covers three object types: Template (parameterized resource definition), TemplateInstance (record of processed template), and BrokerTemplateInstance (used by template service broker)

template-builder-tag-annotation [IN] OBSERVATION

Image streams must have the builder tag in annotations to appear as builder images in the web console Developer Catalog.

template-global-openshift-project [IN] OBSERVATION

Cluster-wide templates are stored in the openshift project and can be listed with oc get templates -n openshift.

template-hardcoded-namespace-stripped [IN] OBSERVATION

Hardcoded namespace values in template objects are stripped during instantiation, but parameterized namespaces (containing ${PARAMETER_REFERENCE}) are preserved after substitution

template-labels-apply-to-all-objects [IN] OBSERVATION

Template-level labels are applied to all objects created from the template.

template-list-parameters-command [IN] OBSERVATION

oc process --parameters -f <filename> lists the overridable parameters of a template.

template-param-value-overrides-generator [IN] OBSERVATION

If a value is specified on a template parameter, the generator is ignored

template-parameter-syntax-dollar-brace [IN] OBSERVATION

Template parameter substitution uses ${PARAMETER_NAME} syntax, and the only supported generator type is "expression"

template-parameters-generate-expression [IN] OBSERVATION

Template parameters with generate: expression and from: (e.g., '[A-Z0-9]{8}') produce auto-generated values such as passwords.

template-process-create-pattern [IN] OBSERVATION

oc process -f <file> | oc create -f - is the standard pattern for creating objects from a template file in OpenShift.

template-quickstart-ephemeral-storage [IN] OBSERVATION

Quick start database templates use ephemeral storage by default — data is lost on pod restart.

template-required-parameter-fails [IN] OBSERVATION

A template parameter with required: true causes template processing to fail if no value is supplied and no default or generator exists.

template-service-broker-deprecated [IN] OBSERVATION

The Template Service Broker is a deprecated component in newer OCP versions; BrokerTemplateInstance exists to support the Open Service Broker API integration.

templateinstance-api-group [IN] OBSERVATION

TemplateInstance is a namespaced resource in the template.openshift.io/v1 API group that records the instantiation of a Template

templateinstance-secret-for-params [IN] OBSERVATION

TemplateInstance .spec.secret references a Secret containing template parameter values, keeping sensitive values out of the TemplateInstance spec

templateinstance-status-condition-types [IN] OBSERVATION

TemplateInstance status conditions have two types: Ready and InstantiateFailure

templates-are-openshift-native-parameterized-resources [IN] OBSERVATION

Templates are an OpenShift-native mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.

templates-are-openshift-specific-api [IN] OBSERVATION

Templates are an OpenShift-specific API extension not present in upstream Kubernetes

templates-openshift-namespace-cluster-wide [IN] OBSERVATION

Shared templates are placed in the openshift namespace to make them accessible from all namespaces.

templates-openshift-parameterized-resources [IN] OBSERVATION

Templates are an OpenShift-specific mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.

templates-openshift-specific [IN] OBSERVATION

Templates are an OpenShift-specific concept not found in vanilla Kubernetes

templates-openshift-specific-parameterized-resources [IN] OBSERVATION

Templates are an OpenShift-specific mechanism for deploying parameterized sets of resources, distinct from Helm charts.

templates-supplemented-by-helm-operators [IN] OBSERVATION

Templates are increasingly supplemented by Helm charts and Operators as preferred deployment mechanisms in modern OpenShift versions

tempo-delete-cli-command [IN] OBSERVATION

To delete a TempoStack instance via CLI: oc delete tempo <instance_name> -n <namespace> (uses tempo resource kind, not tempostack)

tempo-removal-order [IN] OBSERVATION

When removing the Distributed Tracing Platform (Tempo), TempoStack instances must be deleted before removing the Tempo Operator

tempo-removal-requires-cluster-admin [IN] OBSERVATION

Removing the Distributed Tracing Platform requires cluster-admin role, or dedicated-admin on Red Hat OpenShift Dedicated

thanosruler-alertmanagers-config-v0100 [IN] OBSERVATION

ThanosRuler's alertmanagersConfig requires Thanos v0.10.0+; queryConfig requires v0.11.0+

thanosruler-api-group-v1 [IN] OBSERVATION

ThanosRuler is a CRD in the monitoring.coreos.com/v1 API group, managed by the Prometheus Operator

thanosruler-default-retention-24h [IN] OBSERVATION

ThanosRuler's default data retention is 24h

thanosruler-deploys-as-statefulset [IN] OBSERVATION

ThanosRuler deploys as a StatefulSet with two containers: thanos-ruler and config-reloader

thanosruler-excluded-from-enforcement-replaces-deprecated [IN] OBSERVATION

ThanosRuler's prometheusRulesExcludedFromEnforce is deprecated in favor of excludedFromEnforcement

thanosruler-replica-label-always-added-dropped [IN] OBSERVATION

ThanosRuler always adds the thanosrulerreplica label and automatically drops it from alerts

thanosruler-rule-namespace-selector-default [IN] OBSERVATION

If ThanosRuler's ruleNamespaceSelector is unspecified, only the ThanosRuler's own namespace is used for rule discovery

third-party-registries-no-notifications [IN] OBSERVATION

Third-party registries do not provide image push notifications to OpenShift; tags are fetched only at image stream creation time and must be manually refreshed with oc import-image.

three-autoscaling-types-hpa-vpa-custom [IN] OBSERVATION

OpenShift provides three autoscaling mechanisms: HPA (horizontal, CPU/memory-based), VPA (vertical, adjusts resource requests), and Custom Metrics Autoscaler (non-CPU/memory metrics).

three-build-strategies-dockerfile-s2i-custom [IN] OBSERVATION

OpenShift BuildConfig supports three build strategies: Dockerfile-based, Source-to-Image (S2I), and Custom builds.

three-control-plane-nodes-production [IN] OBSERVATION

Exactly three control plane nodes are required for production; bare metal clusters can scale up to five.

three-image-mirror-resources [IN] OBSERVATION

OpenShift has three image mirror resources: ImageContentPolicy (general), ImageDigestMirrorSet (digest-based), and ImageTagMirrorSet (tag-based).

three-image-reference-types [IN] OBSERVATION

OpenShift has three image reference types: ImageStreamTag (<stream>:<tag>), ImageStreamImage (<stream>@<sha256:digest>), and DockerImage (<registry>/<namespace>/<image>:<tag>).

three-operator-roles [IN] OBSERVATION

Three distinct roles interact with Operators in OpenShift: cluster admin (install/manage), developer (consume), and Operator author (build).

tier1-apis-must-roundtrip-without-info-loss [IN] OBSERVATION

Tier 1 APIs must round-trip between versions without information loss.

time-slicing-no-memory-fault-isolation [IN] OBSERVATION

GPU time-slicing has no memory or fault isolation between workloads, unlike MIG which provides full isolation.

timeflowrttns-srtt-nanoseconds [IN] OBSERVATION

TCP Round Trip Time (TimeFlowRttNs) is the Smoothed RTT (SRTT) measured in nanoseconds

tkn-cli-for-openshift-pipelines [IN] OBSERVATION

The tkn CLI interacts with OpenShift Pipelines (Tekton-based CI/CD).

tkn-cli-version-ocp417 [IN] OBSERVATION

The tkn CLI version for OpenShift Container Platform 4.17 is 1.18.0.

tkn-keep-flag-preserves-recent-runs [IN] OBSERVATION

The --keep N flag on tkn pipelinerun delete and tkn taskrun delete preserves the N most recently executed runs when bulk deleting.

tkn-package-three-binaries [IN] OBSERVATION

The tkn CLI archive includes three executables: tkn, tkn-pac, and opc.

tkn-pipelinerun-delete-all-skips-running [IN] OBSERVATION

The tkn pipelinerun delete --all command does not delete pipeline run resources that are in a running state (since Pipelines 1.6).

tkn-task-start-requires-service-account [IN] OBSERVATION

The tkn task start command requires specifying a ServiceAccount via the -s flag.

tokenreview-post-only [IN] OBSERVATION

TokenReview is a POST-only API that validates a bearer token and returns user identity information without creating persistent resources

tokenreview-responses-may-be-cached [IN] OBSERVATION

TokenReview responses may be cached by the webhook token authenticator, which affects token revocation behavior.

tokenreview-results-may-be-cached [IN] OBSERVATION

TokenReview results may be cached by the webhook token authenticator in kube-apiserver

tokenreview-two-endpoints-openshift [IN] OBSERVATION

TokenReview has two endpoints in OpenShift: /apis/authentication.k8s.io/v1/tokenreviews (Kubernetes-native) and /apis/oauth.openshift.io/v1/tokenreviews (OpenShift OAuth)

tokenreview-uid-unique-across-time [IN] OBSERVATION

A user's UID uniquely identifies them across time — if a user is deleted and recreated with the same name, the UID will differ

topology-manager-policies [IN] OBSERVATION

Topology Manager has four policies: none, best-effort, restricted, single-numa-node; and two scopes: container (default) and pod.

topology-manager-single-numa-strictest [IN] OBSERVATION

Topology Manager single-numa-node is the strictest policy — it rejects pods that cannot fit on a single NUMA node.

topology-spread-constraints-anded [IN] OBSERVATION

Pod topologySpreadConstraints are ANDed together — all constraints must be satisfied

topology-yellow-border-quota [IN] OBSERVATION

In the Developer perspective Topology view, a yellow border around a resource name indicates resource limits or quota messages; a yellow dot appears when zoomed out

tracking-tags-single-imagestream-only [IN] OBSERVATION

Tracking tags (--alias=true) only work within a single image stream; cross-image-stream aliases produce an error.

trustee-attestation-component [IN] OBSERVATION

Red Hat build of Trustee is the attestation component that validates TEE integrity before releasing secrets or keys to confidential containers.

tuned-cr-api-version [IN] OBSERVATION

The Tuned custom resource uses API version tuned.openshift.io/v1

tuned-cr-namespaced-resource [IN] OBSERVATION

The Tuned CR is a namespaced resource, typically in the openshift-cluster-node-tuning-operator namespace

tuned-machineconfiglabels-auto-mc [IN] OBSERVATION

Setting machineConfigLabels on a Tuned recommend entry triggers automatic MachineConfig creation for host-level changes like kernel boot parameters

tuned-managed-by-node-tuning-operator [IN] OBSERVATION

The Cluster Node Tuning Operator manages Tuned CRs and deploys containerized TuneD daemons on each node

tuned-match-or-nested-and [IN] OBSERVATION

Tuned match rules at the same level are combined with logical OR; nested match rules within a match entry use logical AND

tuned-match-type-defaults-node [IN] OBSERVATION

Tuned match rule type defaults to node when omitted; valid values are node and pod

tuned-operator-manages-profiles [IN] OBSERVATION

The Node Tuning Operator creates and manages Profile resources by watching Tuned CRs and translating them into per-node Profile objects consumed by the TuneD daemon.

tuned-priority-zero-highest [IN] OBSERVATION

In Tuned recommend rules, priority 0 is the highest priority

tuned-profile-namespaced-resource [IN] OBSERVATION

Profile (tuned.openshift.io/v1) is a namespaced resource representing the per-node realization of a TuneD profile, distinct from the Tuned CR which is the cluster-level definition.

tuned-reapply-sysctl-config [IN] OBSERVATION

The .spec.config.tunedConfig.reapply_sysctl field on a Profile resource controls whether the TuneD daemon reapplies sysctl settings.

tuned-required-fields [IN] OBSERVATION

In Tuned CRs, data and name are required in .spec.profile[]; priority and profile are required in .spec.recommend[]; label is required in match rules (value is optional)

two-event-api-versions-exist [IN] OBSERVATION

Two Event API versions exist in OpenShift/Kubernetes: v1 (core) and events.k8s.io/v1.

two-node-cluster-distinct-topology [IN] OBSERVATION

Two-node clusters are a distinct topology from both SNO and standard HA (3+2) clusters.

two-node-clusters-not-supported-gpu [IN] OBSERVATION

Two-node clusters are not supported for GPU workloads — must be 1 node (SNO) or 3+ nodes.

ubi-images-freely-redistributable [IN] OBSERVATION

Red Hat Universal Base Images (UBI) are freely redistributable without a Red Hat subscription; available in standard, init, and minimal variants.

udn-cr-cannot-be-modified-after-creation [IN] OBSERVATION

The ClusterUserDefinedNetwork CR and UserDefinedNetwork CR cannot be modified after creation

udn-default-join-subnet-must-be-avoided [IN] OBSERVATION

OVN-Kubernetes uses 100.64.0.0/16 as default join subnet; UDN joinSubnets must not use this range; default UDN joinSubnets are 100.65.0.0/16 (IPv4) and fd99::/64 (IPv6)

udn-default-mtu-1400 [IN] OBSERVATION

UDN default MTU is 1400; minimum IPv4 MTU is 576; minimum IPv6 MTU is 1280

udn-dns-resolves-to-default-network [IN] OBSERVATION

Pod DNS lookups resolve to the pod's IP on the cluster default network, not the UDN

udn-do-not-use-openshift-namespaces [IN] OBSERVATION

UDNs must not be created in openshift-* namespaces

udn-kubelet-health-checks-use-default-network [IN] OBSERVATION

Kubelet health checks use the default network, not the primary UDN interface — a pod may appear healthy but have broken UDN connectivity

udn-layer2-subnets-optional-layer3-mandatory [IN] OBSERVATION

UDN Layer 2 subnets are optional; Layer 3 subnets are mandatory

udn-layer2-vs-layer3-topology [IN] OBSERVATION

UDN Layer 2 topology creates a distributed virtual switch (single broadcast domain, supports VM live migration); Layer 3 creates unique L2 segments per node with routing between them and requires cidr and hostSubnet parameters

udn-namespace-label-required [IN] OBSERVATION

The label k8s.ovn.org/primary-user-defined-network must be applied to a namespace before creating a primary UDN

udn-preferred-over-nad-for-segmentation [IN] OBSERVATION

UserDefinedNetwork is preferred over NetworkAttachmentDefinition for network segmentation for security reasons

udn-requires-ovn-kubernetes [IN] OBSERVATION

User-Defined Networks (UDNs) are only supported with OVN-Kubernetes and do not work with other CNI plugins.

udn-tech-preview-ocp-417 [IN] OBSERVATION

User-Defined Networks (UDNs) are a Technology Preview feature in OCP 4.17, not supported for production under SLAs

unbound-pvc-waits-indefinitely [IN] OBSERVATION

PVCs remain unbound indefinitely if no matching PV exists — they do not fail, they wait.

unformatted-volumes-auto-formatted [IN] OBSERVATION

OpenShift automatically formats unformatted volumes based on fsType, erasing any existing data.

unidling-only-haproxy-router [IN] OBSERVATION

Automatic unidling (restoring replicas on incoming traffic) is only supported by the default HAProxy router.

unified-security-from-install-through-api-governance [IN] DERIVED

OpenShift enforces security as a continuous chain from install-time locks (FIPS, CPU partitioning) through runtime TLS/IPsec enforcement to API-level immutability and webhook admission control — no single layer can be bypassed without affecting the others.

unsupported-config-overrides-blocks-upgrades [IN] OBSERVATION

Setting unsupportedConfigOverrides on OpenShift operator resources blocks cluster upgrades and is not supported by Red Hat; it must be removed before upgrading.

unsupported-field-prefix-no-guarantees [IN] OBSERVATION

API fields prefixed with unsupported<FieldName> have zero compatibility guarantees across or within releases.

unsupportedconfigoverrides-blocks-upgrades [IN] OBSERVATION

The unsupportedConfigOverrides field on operator.openshift.io/v1 resources is not supported by Red Hat and blocks cluster upgrades — it must be removed before upgrading

update-channel-promotion-order [IN] OBSERVATION

Update channel promotion order is: candidate → fast → stable, with eus promoted simultaneously with stable. fast and stable have identical support levels; the only difference is the time delay.

update-channels-production [IN] OBSERVATION

Production OCP clusters must use stable-*, eus-*, or fast-* update channels; candidate-* is not for production

update-prereqs-checklist [IN] OBSERVATION

Cluster update prerequisites include: etcd backup, CSI snapshots for PVs, OLM Operators updated to compatible versions, MCPs unpaused, Upgradeable=False conditions resolved, MHCs paused, and unsupportedConfigOverrides removed

update-strategy-canary-and-control-plane-model [IN] DERIVED

OpenShift updates support two complementary risk-mitigation strategies: canary rollout updates use custom MachineConfigPools with pause/unpause workflows to stage worker node updates, while Control Plane Only updates between even-numbered minor versions allow decoupling control plane and worker updates — both enabling phased rollouts but at different scopes.

upgradeable-false-blocks-minor-only [IN] OBSERVATION

When a ClusterOperator's Upgradeable condition is False, the CVO prevents minor version updates unless forced; patch/z-stream updates are not blocked.

upgradeable-to-annotation-unblocks-minor-update [IN] OBSERVATION

The upgradeable-to annotation must be set on the CloudCredential resource via oc annotate cloudcredential cluster cloudcredential.openshift.io/upgradeable-to=<version> to unblock minor version updates for manually maintained credential clusters.

upi-no-default-storage-class [IN] OBSERVATION

User-Provisioned Infrastructure (UPI) requires manual provisioning of load balancer, DNS, and storage; default storage classes are NOT defined.

use-exec-in-wrapper-scripts [IN] OBSERVATION

Wrapper scripts in container entrypoints should use exec to replace the script process with the application so signals (e.g., SIGINT) are delivered correctly to PID 1

use-more-secure-service-ca-one-way [IN] OBSERVATION

The useMoreSecureServiceCA field on KubeControllerManager is a one-way toggle — once set to true, it cannot be reverted to false

user-api-group-user-openshift-io [IN] OBSERVATION

OpenShift Users are a separate user.openshift.io/v1 API resource, distinct from Kubernetes ServiceAccounts

user-created-automatically-on-first-login [IN] OBSERVATION

User and Identity resources are created automatically when a user first authenticates via a configured identity provider; administrators do not need to pre-create them.

user-defined-monitoring-not-default [IN] OBSERVATION

Monitoring for user-defined projects is not enabled by default; a cluster administrator must explicitly enable it after installation

user-group-api-resources [IN] OBSERVATION

The user.openshift.io/v1 API group contains User, Identity, Group, and UserIdentityMapping resources.

user-groups-field-deprecated [IN] OBSERVATION

The groups array field on the User object is deprecated; the recommended approach is to create separate Group objects that reference users.

user-identity-mapping-architecture [IN] OBSERVATION

Identity objects link external authentication identities to internal User objects; one user can have multiple identities from different providers

user-workload-monitoring-opt-in [IN] OBSERVATION

User workload monitoring must be explicitly enabled; core platform monitoring is always on by default.

useridentitymapping-maps-user-to-identity [IN] OBSERVATION

The UserIdentityMapping resource is the binding that connects an Identity object to a User object, resolving which user account a login corresponds to after authentication.

useridentitymapping-no-list-operation [IN] OBSERVATION

There is no LIST endpoint for UserIdentityMapping resources, unlike most other API resources.

usernames-unique-with-suffix-on-collision [IN] OBSERVATION

Usernames in OpenShift must be unique and are derived from the identity provider; if a collision occurs, a numeric suffix may be appended.

useroauthaccesstoken-delete-revokes-token [IN] OBSERVATION

Users can delete their own access tokens via the UserOAuthAccessToken API to revoke them.

useroauthaccesstoken-virtual-resource [IN] OBSERVATION

UserOAuthAccessToken is a virtual (non-persisted) resource that mirrors OAuthAccessTokens scoped to the token's owner, allowing users to view/manage their own tokens.

v1alpha1-apis-default-tier4 [IN] OBSERVATION

v1alpha1 APIs default to Tier 4 (no compatibility guarantee), except for monitoring.coreos.com and operators.coreos.com where all versions including alpha are Tier 1.

validating-admission-policy-uses-cel [IN] OBSERVATION

ValidatingAdmissionPolicy uses CEL (Common Expression Language) for in-process validation without requiring an external webhook service.

validating-webhook-cannot-modify-objects [IN] OBSERVATION

ValidatingWebhookConfiguration can only accept or reject requests — it cannot modify objects

validating-webhook-sideeffects-values [IN] OBSERVATION

ValidatingWebhookConfiguration sideEffects accepts values None, NoneOnDryRun, Some, or Unknown; dry-run requests are auto-rejected if sideEffects is Some or Unknown

vdu-chronyd-disabled-ptp-used [IN] OBSERVATION

Chronyd must be stopped and disabled on vDU cluster nodes; PTP provides time synchronization instead.

vdu-crun-oci-runtime [IN] OBSERVATION

crun is enabled as the OCI container runtime for vDU clusters.

vdu-default-operatorhub-sources-disabled [IN] OBSERVATION

Default OperatorHub sources must be disabled (disableAllDefaultSources: true) on vDU clusters.

vdu-firmware-cstates-c0-c1-only [IN] OBSERVATION

For vDU clusters, BIOS C-States must be limited to C0/C1 only, with C1E disabled, Processor C6 disabled, and CPU Power Policy set to Performance.

vdu-firmware-uefi-sriov-vtd-required [IN] OBSERVATION

Firmware for vDU SNO must be set to UEFI boot mode, and SR-IOV and VT-d must be enabled in firmware for bare-metal environments.

vdu-module-blacklist-irdma-required [IN] OBSERVATION

module_blacklist=irdma is a required kernel argument for vDU clusters.

vdu-required-operators [IN] OBSERVATION

Required Operators for vDU workloads on SNO: Node Tuning Operator, PTP Operator, SR-IOV Network Operator, OpenShift Logging Operator, and Local Storage Operator.

vdu-sno-minimum-hardware [IN] OBSERVATION

Minimum hardware for vDU SNO: 4-8 vCPU, 32GB RAM, 120GB storage.

vdu-stalld-service-enabled [IN] OBSERVATION

The stalld service must be enabled in the Tuned CR for real-time vDU workloads.

vdu-tuned-include-references-performanceprofile [IN] OBSERVATION

The Tuned CR include line must reference the associated PerformanceProfile name using the pattern openshift-node-performance-${PerformanceProfile.metadata.name}.

vdu-web-console-disabled [IN] OBSERVATION

The OpenShift web console must be disabled (managementState: Removed) on vDU clusters to reduce resource usage.

vector-default-log-collector [IN] OBSERVATION

Vector has replaced Fluentd as the default log collector in OpenShift.

version-coupling-and-update-governance [IN] DERIVED

OpenShift enforces strict version coupling and update ordering: CNV minor version must match OCP minor version, OCP must update before CNV, HCP follows a three-step update sequence (management OCP → MCE → hosted cluster), and rollback is never supported — creating a unidirectional, order-dependent upgrade graph.

virt-image-provisioning-pipeline [IN] DERIVED

VM disk image provisioning in OpenShift Virtualization follows a defined pipeline: CDI requires scratch space equal to the destination volume during import, three cloning strategies (snapshot/csi-clone/host-assisted) offer different performance profiles, and boot source images are managed through a feature gate that controls automatic updates — creating a multi-strategy provisioning model.

virt-live-migration-storage-and-network-prerequisites [IN] DERIVED

VM live migration requires both RWX storage (RWO blocks migration) and a dedicated Multus network, making it a feature that demands specific infrastructure provisioning.

virt-migration-depends-on-cni-and-storage-stack [IN] DERIVED

VM live migration depends on the full platform networking and storage stack: Multus CNI (from the multi-CNI architecture) provides the dedicated migration network, while RWX-capable storage classes must be provisioned — making live migration a feature that only works when both the CNI layer and storage layer are correctly configured.

virt-migration-excluded-on-constrained-topologies [IN] DERIVED

VM live migration requires both infrastructure prerequisites (RWX storage + dedicated Multus network) and multi-node topology — SNO explicitly lacks live migration/HA, making virtualization feature availability topology-dependent.

virt-migration-requires-full-stack-and-topology [IN] DERIVED

VM live migration is the most infrastructure-demanding feature in OpenShift: it requires the complete CNI+storage stack (Multus for dedicated network, RWX storage) AND a multi-node topology, making it a capability that emerges only when both infrastructure depth and cluster breadth are sufficient.

virt-requires-governed-infrastructure-stack [IN] DERIVED

OpenShift Virtualization's most demanding feature (live migration) validates the full governed infrastructure stack: it requires CNI networking (multi-CNI architecture), storage lifecycle (RWX PVCs from the storage model), topology validation, and singleton operator configuration (HyperConverged CR) — all managed through the operator-driven immutable platform model.

virt-validates-full-governed-platform [IN] DERIVED

OpenShift Virtualization is the most demanding consumer of the governed platform model: live migration requires the full CNI+storage infrastructure stack operating under operator-driven governance (singleton CRs, immutable nodes), and both application images and VM disk images flow through governed supply chains — making virtualization a comprehensive validation that all platform layers are functioning correctly.

virtctl-addvolume-persist-flag [IN] OBSERVATION

The --persist flag on virtctl addvolume permanently mounts the disk; it applies only to VMs, not VMIs.

virtctl-guestfs-virt-sysprep [IN] OBSERVATION

virtctl guestfs deploys a libguestfs container for VM disk manipulation; virt-sysprep seals a VM disk image as a template.

virtctl-installed-separately [IN] OBSERVATION

virtctl is installed separately from the OpenShift CLI — downloaded from the web console or via RPM (kubevirt-virtctl package on RHEL 8).

volume-snapshot-api-objects [IN] OBSERVATION

OCP supports VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass API objects for point-in-time storage copies.

volumeattachment-cluster-scoped [IN] OBSERVATION

VolumeAttachment objects are non-namespaced (cluster-scoped) resources in the storage.k8s.io/v1 API group.

volumeattachment-only-external-attacher-sets-status [IN] OBSERVATION

Only the external-attacher should set status.attached and attachmentMetadata on VolumeAttachment — not users or other controllers.

volumeattachment-spec-three-required-fields [IN] OBSERVATION

VolumeAttachment spec requires three sub-fields: attacher (CSI driver name), source (volume reference), and nodeName.

volumesnapshot-apis-ga-v1 [IN] OBSERVATION

VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent are all GA at snapshot.storage.k8s.io/v1.

volumesnapshotcontent-api-group [IN] OBSERVATION

VolumeSnapshotContent is in the snapshot.storage.k8s.io/v1 API group.

volumesnapshotcontent-bidirectional-binding [IN] OBSERVATION

VolumeSnapshotContent requires bidirectional binding: VolumeSnapshotContent references VolumeSnapshot via volumeSnapshotRef, and VolumeSnapshot references VolumeSnapshotContent via spec.volumeSnapshotContentName.

volumesnapshotcontent-cluster-scoped-snapshot-namespaced [IN] OBSERVATION

VolumeSnapshotContent is cluster-scoped (no namespace), while VolumeSnapshot is namespaced.

volumesnapshotcontent-deletion-policies [IN] OBSERVATION

VolumeSnapshotContent has two deletion policies: Retain (keep physical snapshot) and Delete (remove both object and physical snapshot).

volumesnapshotcontent-restore-size-minimum [IN] OBSERVATION

When restoring a volume from a snapshot, the volume size must not be smaller than restoreSize from the VolumeSnapshotContent status.

volumesnapshotcontent-source-immutable [IN] OBSERVATION

The VolumeSnapshotContent source field is immutable after creation; it uses either volumeHandle (dynamic) or snapshotHandle (pre-existing), which are mutually exclusive.

vpa-adjusts-requests-limits [IN] OBSERVATION

VerticalPodAutoscaler (VPA) adjusts resource requests and limits on pods rather than scaling replica count.

vrf-cni-allows-ip-overlap [IN] OBSERVATION

The CNI VRF plugin allows overlapping IP addresses with the OpenShift cluster's main network CIDR.

vrf-layer3-only [IN] OBSERVATION

VRF (Virtual Routing and Forwarding) operates at OSI Layer 3 only and does not affect Layer 2 protocols such as LLDP.

vrf-only-works-with-netdevice-type [IN] OBSERVATION

VRF functions correctly only when the resource is of type netdevice

vrf-plugin-must-be-second-in-chain [IN] OBSERVATION

The CNI VRF plugin must be the second plugin in a chained CNI configuration, after the base network plugin (e.g., macvlan)

vrf-requires-so-bindtodevice-not-ip-vrf-exec [IN] OBSERVATION

Applications in OpenShift pods must use SOBINDTODEVICE (requires CAPNET_RAW) to bind to VRF interfaces; ip vrf exec is not supported in pods

vrf-table-param-optional-auto-assigned [IN] OBSERVATION

The VRF plugin table parameter is optional; the CNI plugin auto-assigns a free routing table ID if omitted

vsphere-default-snapshot-limit-3 [IN] OBSERVATION

The default vSphere snapshot limit per block volume in ClusterCSIDriver is 3; increasing above 3 impacts performance.

vsphere-failure-domains-tag-categories [IN] OBSERVATION

vSphere failure domains require vCenter tag categories named exactly openshift-region and openshift-zone for region/zone mapping

vsphere-storage-driver-csi-migration-irreversible [IN] OBSERVATION

The vsphereStorageDriver field set to CSIWithMigrationDriver is irreversible and is the current default; the field itself is deprecated

vsphere-supported-install-platform [IN] OBSERVATION

VMware vSphere is a supported installation platform for OpenShift Container Platform.

vsphere-supports-ipi-and-upi [IN] OBSERVATION

OpenShift supports both installer-provisioned infrastructure (IPI) and user-provisioned infrastructure (UPI) installation methods on vSphere.

vsphere-vgpu-limits [IN] OBSERVATION

vSphere 7.0 supports max 4 vGPU per VM; vSphere 8.0 supports max 8 vGPU per VM and adds heterogeneous profile support.

waitforfirstconsumer-delays-binding [IN] OBSERVATION

volumeBindingMode: WaitForFirstConsumer delays PV binding until a pod using the PVC is scheduled, enabling topology-aware provisioning.

watch-endpoints-deprecated [IN] OBSERVATION

Watch-specific API endpoints (e.g., /watch/...) are deprecated — the watch query parameter on list operations should be used instead.

watch-endpoints-deprecated-use-list-param [IN] OBSERVATION

Dedicated watch endpoints (e.g., /watch/apiservices) are deprecated in favor of using the watch query parameter on list operations.

watch-endpoints-deprecated-use-parameter [IN] OBSERVATION

Watch endpoints (/watch/...) are deprecated; the watch parameter on list operations should be used instead

watch-endpoints-deprecated-use-query-param [IN] OBSERVATION

Dedicated /watch/ API endpoints are deprecated across Kubernetes APIs; the watch query parameter on list operations should be used instead.

watch-endpoints-deprecated-use-watch-param [IN] OBSERVATION

The dedicated /watch/ endpoints for User and Identity resources are deprecated; the correct approach is to use the watch query parameter on list operations.

wavelength-zone-iam-permissions [IN] OBSERVATION

AWS Wavelength Zones require three IAM permissions: ec2:ModifyAvailabilityZoneGroup, ec2:CreateCarrierGateway, and ec2:DeleteCarrierGateway.

wavelength-zone-requires-carrier-gateway [IN] OBSERVATION

AWS Wavelength Zones require a carrier gateway for connectivity between the Wavelength Zone and the carrier network; Local Zones do not.

web-console-admin-developer-perspectives [IN] OBSERVATION

The OpenShift web console supports both an Administrator perspective and a Developer perspective

web-terminal-admin-project-openshift-terminal [IN] OBSERVATION

Cluster admins' DevWorkspace CRs are always created in the openshift-terminal project and cannot choose another

web-terminal-devworkspace-dependency [IN] OBSERVATION

The DevWorkspace Operator is automatically installed as a dependency of the Web Terminal Operator and should not be installed separately

web-terminal-network-policy-namespaces [IN] OBSERVATION

Web terminal requires NetworkPolicy allowing ingress from both openshift-console and openshift-operators namespaces when restrictive network policies exist, or the terminal fails with "context deadline exceeded"

web-terminal-operator-namespace [IN] OBSERVATION

The Web Terminal Operator is installed in the openshift-operators namespace with All namespaces scope

web-terminal-operator-ocp47 [IN] OBSERVATION

The embedded web terminal in the console requires the Web Terminal Operator and is available from OCP 4.7+

web-terminal-preinstalled-cli-tools [IN] OBSERVATION

The Web Terminal includes pre-installed CLI tools: oc, kubectl, odo, kn, tkn, helm, subctl

web-terminal-uninstall-requires-manual-cleanup [IN] OBSERVATION

Uninstalling the Web Terminal Operator does NOT automatically remove CRDs or managed resources — manual cleanup of DevWorkspace CRDs and webhooks is required

web-terminal-webhook-removal-breaks-oc-exec [IN] OBSERVATION

Removing the devworkspace-webhook-server deployment without removing the associated mutating/validating webhooks causes oc exec commands to fail cluster-wide

webhook-admission-enforcement-model [IN] DERIVED

Webhook admission in OpenShift follows a constrained enforcement model: all webhook communication requires TLS, timeouts are hard-capped at 13 seconds (non-configurable), webhooks are never invoked on their own kind (preventing infinite loops), and each webhook must declare four required fields — creating a bounded, self-protecting admission pipeline.

webhook-auth-requires-type-none [IN] OBSERVATION

The spec.webhookTokenAuthenticator field on the Authentication resource can only be set when spec.type is None.

webhook-communication-requires-tls [IN] OBSERVATION

Communication between the webhook admission plugin and the webhook server must use TLS.

webhook-config-resource-kinds [IN] OBSERVATION

The two webhook configuration resource kinds are MutatingWebhookConfiguration and ValidatingWebhookConfiguration in API group admissionregistration.k8s.io/v1beta1.

webhook-failure-policy-default-fail [IN] OBSERVATION

The failurePolicy for admission webhooks defaults to Fail, meaning an unreachable webhook rejects the request

webhook-failure-policy-options [IN] OBSERVATION

Webhook failurePolicy can be set to Fail (deny on error) or Ignore (accept on error); Ignore unconditionally accepts requests when the webhook is unavailable.

webhook-match-conditions-cel-max-64 [IN] OBSERVATION

Webhook matchConditions use CEL expressions to filter requests, with a maximum of 64 conditions per webhook

webhook-match-policy-default-equivalent [IN] OBSERVATION

Webhook matchPolicy defaults to Equivalent, converting requests across API group versions to match rules

webhook-max-timeout-13-seconds [IN] OBSERVATION

The maximum webhook admission plugin timeout is 13 seconds and cannot be changed.

webhook-never-invoked-on-own-kind [IN] OBSERVATION

Mutating and Validating webhook configurations are never called on admission requests for their own kind to prevent unrecoverable cluster states

webhook-reinvocation-policy-ifneeded-idempotent [IN] OBSERVATION

Webhook reinvocationPolicy: IfNeeded re-calls the webhook if other admission plugins mutate the object afterward, and requires the webhook logic to be idempotent

webhook-required-fields [IN] OBSERVATION

Each admission webhook entry requires four fields: name, clientConfig, sideEffects, and admissionReviewVersions

webhook-service-port-default-443 [IN] OBSERVATION

The port field in a webhook clientConfig.service reference defaults to 443

webhook-timeout-default-10-range-1-30 [IN] OBSERVATION

Admission webhook timeoutSeconds defaults to 10 and must be between 1–30 seconds

webhook-token-authenticators-plural-deprecated [IN] OBSERVATION

The spec.webhookTokenAuthenticators (plural) field on the Authentication resource is deprecated and setting it has no effect.

webhook-url-must-use-https [IN] OBSERVATION

The url field in webhook clientConfig must use HTTPS; in-cluster webhooks should use the service field instead

webhooks-called-in-parallel [IN] OBSERVATION

Webhooks within each admission phase (mutating or validating) are called in parallel, not sequentially; all must approve or the request is denied.

whereabouts-ipam-cluster-wide [IN] OBSERVATION

Whereabouts IPAM provides cluster-wide IP address management with overlap detection, unlike host-local which is node-scoped only.

whereabouts-ipam-secondary-networks [IN] OBSERVATION

The Whereabouts CNI plugin provides cluster-wide IPAM for secondary/additional pod networks, typically used with Multus CNI, preventing IP conflicts across nodes

whereabouts-overlapping-range-ip-reservation [IN] OBSERVATION

OverlappingRangeIPReservation (whereabouts.cni.cncf.io/v1alpha1) tracks IP reservations across overlapping IP ranges used by multiple NetworkAttachmentDefinitions, with a required podref field

windows-containers-ovn-hybrid-networking [IN] OBSERVATION

OVN-Kubernetes with hybrid networking is required for Windows container support in OpenShift

windows-containers-wmco-managed [IN] OBSERVATION

Windows container support in OpenShift is managed by the Windows Machine Config Operator (WMCO)

windows-node-architectural-divergence [IN] DERIVED

Windows nodes diverge from the standard OpenShift node model: they use Windows container runtime instead of CRI-O and require OVN-Kubernetes hybrid networking, making them a specialized compute tier.

windows-nodes-not-crio [IN] OBSERVATION

Windows nodes use the Windows container runtime rather than CRI-O

windows-nodes-worker-only [IN] OBSERVATION

Windows nodes in OpenShift function as worker nodes only — control plane nodes must be Linux

worker-ignition-port-22623 [IN] OBSERVATION

Worker Ignition configs reference the bootstrap/control plane via https://api.<cluster>:22623/config/worker.

worker-latency-profile-three-values [IN] OBSERVATION

workerLatencyProfile has three values: Default, MediumUpdateAverageReaction, and LowUpdateSlowReaction, progressively tolerating higher network latency between workers and control plane

worker-node-csr-approval-required [IN] OBSERVATION

Pending CSRs must be approved for worker nodes to join the cluster, using oc get csr followed by oc adm certificate approve <csr_name>.

workload-availability-separate-product [IN] OBSERVATION

Workload Availability for Red Hat OpenShift is a separate product from OCP with its own version numbers (e.g., 26.1), providing remediation, fencing, and maintenance capabilities.

workload-availability-three-pillars [IN] OBSERVATION

The three pillars of Workload Availability are remediation (automated recovery), fencing (isolating failed nodes), and maintenance (controlled node drain/downtime).

workload-partitioning-cpupartitioningmode-allnodes [IN] OBSERVATION

Workload partitioning is enabled by setting cpuPartitioningMode: AllNodes in the SiteConfig CR.

workload-partitioning-install-time-only [IN] OBSERVATION

Workload partitioning can only be enabled at install time — it cannot be enabled or disabled post-installation. CPU assignments can be changed later via PerformanceProfile CR.

workload-placement-requires-storage-and-scheduling [IN] DERIVED

Pod placement in OpenShift must satisfy two independent constraint systems simultaneously: the scheduling system (node selectors, taints, affinity rules, topology manager NUMA policies) determines WHERE a pod runs, while the storage lifecycle (CSI provisioning, PVC binding phases, access mode requirements) determines WHETHER the pod's data dependencies can be met at that location.

workload-type-mapping [IN] OBSERVATION

Run-to-completion workloads use Job/CronJob; long-running use Deployment/DeploymentConfig; every-node use DaemonSet; identity requirements use StatefulSet; lifecycle management uses Operators with OLM.

xpaas-images-openshift-suffix [IN] OBSERVATION

xPaaS middleware images are suffixed with -openshift (e.g., registry.redhat.io/jboss-eap-6/eap64-openshift).

z-stream-no-breaking-changes [IN] OBSERVATION

Z-stream releases never break API or AOE compatibility except for critical security issues.

zero-trust-cluster-ca-created-at-install [IN] OBSERVATION

OpenShift creates a cluster CA at installation time as the root of trust for service certificates.

zero-trust-ipsec-ovn-kubernetes-pod-to-pod [IN] OBSERVATION

OVN-Kubernetes supports transparent pod-to-pod IPsec encryption and north-south egress IPsec encryption.

zero-trust-no-app-code-changes-required [IN] OBSERVATION

Zero trust capabilities (IPsec, mTLS via mesh, NetworkPolicy) can be added without changing application code.

zero-trust-service-cert-26mo-ttl-13mo-rotate [IN] OBSERVATION

OpenShift service certificates have a 26-month TTL and are automatically rotated at 13 months.

zero-trust-service-mesh-provides-mtls-jwt-spiffe [IN] OBSERVATION

OpenShift Service Mesh provides transparent mTLS, L4/L7 authorization, JWT request authentication, and SPIFFE attestation.

ztp-cluster-labels-policy-binding [IN] OBSERVATION

Cluster labels common: true, group-du-sno: "", and sites: "example-sno" control which PolicyGenerator policies bind to which clusters in the ZTP hierarchy.

ztp-clustergroupupgrade-auto-created-ztp-install-namespace [IN] OBSERVATION

ClusterGroupUpgrade CR is automatically created by TALM in the ztp-install namespace for any ManagedCluster without a ztp-done label, with a 240-minute (4-hour) timeout and pre-caching disabled.

ztp-clusters-app-noncascaded-policies-cascaded-delete [IN] OBSERVATION

During ZTP upgrade, the clusters app uses non-cascaded delete (preserves resources) while the policies app uses cascaded delete (removes old policies).

ztp-cpu-partitioning-mode-install-time-only [IN] OBSERVATION

cpuPartitioningMode: AllNodes must be set at install time for workload partitioning — it cannot be changed post-install.

ztp-crsuppression-triggers-deprovisioning [IN] OBSERVATION

The crSuppression field in SiteConfig prevents generation of specific CRs (e.g., BareMetalHost) to trigger node deprovisioning; removing the suppression and pushing triggers reprovisioning.

ztp-done-label-protects-clusters-during-upgrade [IN] OBSERVATION

The ztp-done label must be applied to all existing managed clusters before upgrading GitOps ZTP to prevent them from being affected; TALM-provisioned clusters get this label automatically.

ztp-done-label-signals-completion [IN] OBSERVATION

The ztp-done label is applied to a managed cluster when all ZTP policies become Compliant, signaling ZTP completion.

ztp-extra-manifests-at-install-more-efficient [IN] OBSERVATION

Including MachineConfig CRs at install time via extra manifests is more efficient than applying them post-install.

ztp-node-deletion-annotation [IN] OBSERVATION

The annotation bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true on a BareMetalHost ensures both the Agent CR and node are cleaned up on deletion.

ztp-pattern-edge-fleet-management [IN] OBSERVATION

Zero Touch Provisioning (ZTP) with GitOps is a common pattern for managing fleets of edge clusters at scale.

ztp-phase-labels-running-done [IN] OBSERVATION

ZTP applies ztp-running label when post-install configuration starts, replaced by ztp-done when all policies are compliant; the ztp-done label prevents TALM from recreating ClusterGroupUpgrade.

ztp-plugin-v411-daemon-selector-master-only [IN] OBSERVATION

ZTP plugin v4.11 or earlier sets PTP and SR-IOV daemon selectors to master only, which prevents daemons from running on workers and must be changed to worker for expanded clusters.

ztp-policies-default-inform-remediation [IN] OBSERVATION

ZTP creates all policies with remediation action: inform by default — RHACM reports compliance but TALM enforces the changes, not RHACM directly.

ztp-primary-mechanism-edge-provisioning [IN] OBSERVATION

GitOps Zero Touch Provisioning (ZTP) is OpenShift's designated approach for provisioning and managing far-edge sites at scale.

ztp-registries-conf-scoped-by-repository [IN] OBSERVATION

Registries in the mirror registries.conf must be scoped by repository, not by registry.

ztp-secrets-namespace-must-match-cluster-name [IN] OBSERVATION

BMC credentials secret and pull secret must be in a namespace matching the cluster name from SiteConfig.

ztp-site-generate-e-flag-machineconfig-only [IN] OBSERVATION

The -E flag with generator install generates only MachineConfig CRs from the SiteConfig.

ztp-site-generate-two-modes [IN] OBSERVATION

The ztp-site-generate container has two generator modes: generator install (Day 0 installation CRs) and generator config (Day 2 configuration CRs).

ztp-siteconfig-inclusiondefault-values [IN] OBSERVATION

SiteConfig extraManifests.filter.inclusionDefault has two values: include (default, apply all then selectively exclude) and exclude (apply none then selectively include).

ztp-siteconfig-searchpaths-supersedes-extramanifestpath [IN] OBSERVATION

extraManifests.searchPaths supersedes the deprecated extraManifestPath in SiteConfig (since OCP 4.14); when searchPaths is defined, the pipeline stops fetching manifests from the ztp-site-generate container.

ztp-upgraded-policies-inform-mode-not-auto-pushed [IN] OBSERVATION

After a ZTP upgrade, changed policies appear as Non-Compliant in inform mode and are not automatically pushed to managed clusters — they require ClusterGroupUpgrade CRs via TALM.

ztp-wave-annotations-same-policy [IN] OBSERVATION

All CRs in the same ZTP policy must share the same ztp-deploy-wave annotation value; fewer policies means faster deployment.

bare-metal-edge-fully-autonomous [OUT] DERIVED

Bare metal edge deployments achieve full autonomy — provisioned via ZTP, updated via TALM canary gates, and operating with reduced capability profiles — only when SR-IOV drain issues on single-node topology are resolved and the node configuration pipeline validates all inputs.

build-system-fully-functional [OUT] DERIVED

OpenShift build system is fully functional with S2I/Docker/Custom strategies and proper proxy configuration.

complete-governed-software-delivery-operational [OUT] DERIVED

The governed software delivery pipeline (build→image→operator→console with identity-gated access and image supply chain governance) is fully operational end-to-end only when legacy DeploymentConfig deprecation is resolved and OLM v1 reaches GA.

complete-software-delivery-operational [OUT] DERIVED

The complete software delivery pipeline (build→image→operator→console) is fully operational end-to-end only when legacy deprecations are resolved and the OLM lifecycle is fully GA.

console-plugin-deployable [OUT] DERIVED

A ConsolePlugin is deployable when it has HTTPS backend and OLM registration.

disconnected-delivery-pipeline-fully-operational [OUT] DERIVED

The disconnected cluster delivery pipeline (oc-mirror → IDMS → MCO for images; FBC catalogs for operators) is fully operational end-to-end only when OLM v1 can authenticate to private registries.

dual-stack-networking-operational-on-platform [OUT] DERIVED

Dual-stack IPv4/IPv6 networking is fully operational on the target platform when no platform-specific IPv4-only restrictions apply.

edge-disconnected-fleet-fully-operational [OUT] DERIVED

Edge fleet deployments with disconnected content delivery are fully operational end-to-end — ZTP provisions clusters while mirror pipelines deliver all content — only when OLM v1 reaches GA and supports private registry authentication for operator catalogs.

edge-fleet-with-full-observability [OUT] DERIVED

Edge fleet deployments with disconnected content delivery achieve full operational visibility — ZTP provisions clusters, mirror pipelines deliver content, and the complete observability stack (monitoring + network observability + power monitoring) provides feedback — only when observability tech preview components reach GA.

governed-supply-chains-operational-across-topologies [OUT] DERIVED

The governed image and operator supply chains (build→ImageStream→registry for apps, FBC→OLM→CSV for operators) are fully operational across all topology variants (standalone, HCP, SNO) only when the next-generation operator delivery mechanism reaches GA and supports disconnected registries

legacy-dc-build-workflow-functional [OUT] DERIVED

The OpenShift build system supports legacy DeploymentConfig-based workflows where BuildConfigs trigger rolling deployments through the DC mechanism.

multi-network-policy-enforcement-complete [OUT] DERIVED

Network policy enforcement covers both primary networks (via AdminNetworkPolicy cluster-scoped rules with Allow/Deny/Pass actions) and secondary networks (via MultiNetworkPolicy with identical spec to NetworkPolicy), providing comprehensive traffic control across all network interfaces.

network-observability-end-to-end [OUT] DERIVED

Network observability pipeline is end-to-end operational: eBPF agent collects flows, FlowCollector (singleton named cluster) processes them, Loki stores them, and the console plugin provides visualization.

networking-fully-operational-with-observability [OUT] DERIVED

The complete networking stack with integrated observability (DNS discovery + multi-CNI data plane + dual-stack addressing + eBPF flow collection) is fully operational only when eBPF Manager reaches GA and platform-specific dual-stack restrictions are resolved.

node-config-delivery-fully-validated [OUT] DERIVED

Node configuration changes are both delivered and validated end-to-end through the immutable pipeline, with API-level validation catching invalid values before they reach nodes.

node-config-delivery-fully-validated-and-drift-protected [OUT] DERIVED

Node configuration is both delivered through the immutable pipeline and protected against drift, with the MCO marking drifted nodes as Degraded — but only when API-level validation catches all invalid values before they reach nodes.

observability-stack-production-complete [OUT] DERIVED

The full OpenShift observability stack (platform monitoring + user workload monitoring + network observability + power monitoring + distributed tracing) is production-complete only when all component-level tech preview restrictions are resolved.

olm-generational-transition-complete-in-disconnected [OUT] DERIVED

OLM's generational transition (v1 GA → v1 extension API) is fully functional in disconnected environments only when both the v1 extension API reaches GA and private registry authentication is resolved.

olm-lifecycle-fully-ga [OUT] DERIVED

The complete OLM operator lifecycle (CatalogSource → Subscription → InstallPlan → CSV) is fully GA and production-supported.

olm-v1-extension-installable [OUT] DERIVED

An OLM v1 extension is installable when it meets format and ownership requirements.

power-monitoring-production-ready [OUT] DERIVED

Power monitoring with Kepler provides container-level granularity power consumption tracking that is production-ready.

rhcos-custom-layering-verified [OUT] DERIVED

RHCOS custom image layering is verified and operational when rpm-ostree status confirms deployment.

rhcos-image-layering-production-ready [OUT] DERIVED

RHCOS custom image layering via rpm-ostree is production-ready on the immutable node model.

runtime-operations-fully-observable-within-governance [OUT] DERIVED

The complete runtime operations stack (networking + observability + autoscaling + resource management) is fully observable within governance only when all observability components reach GA — currently power monitoring and eBPF flow management remain tech preview, creating blind spots in the otherwise governed runtime model

sriov-fully-operational-on-cluster [OUT] DERIVED

SR-IOV networking is fully operational with VF driver modes, config daemon, and hardware offloading support.

sriov-operational-with-live-migration [OUT] DERIVED

SR-IOV networking and VM live migration can coexist when SR-IOV is fully operational and migration prerequisites are met, but only on multi-node clusters where SR-IOV drain is not disabled.

sriov-with-nmstate-operational [OUT] DERIVED

SR-IOV high-performance networking with declarative NMState node network configuration provides a complete hardware-accelerated networking stack — SR-IOV creates VFs and NetworkAttachmentDefinitions while NMState manages the underlying node interfaces — only when SR-IOV drain limitations on SNO are resolved.

virt-live-migration-fully-operational [OUT] DERIVED

VM live migration is fully operational when RWX storage and dedicated migration network are provisioned.

virt-live-migration-operational [OUT] DERIVED

VM live migration is fully operational with RWX storage, dedicated Multus network, and no blocking constraints from GPU passthrough or single-node topology.

virt-migration-end-to-end-operational [OUT] DERIVED

VM live migration is end-to-end operational across the full infrastructure stack — from CNI networking through storage to topology validation — only when no GPU passthrough, IPv6-only, or vTPM constraints apply and the cluster is multi-node.

Topics