# 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::`, and `unix:`. ### 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 -n --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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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/=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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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/ -n ` ### 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= --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] OBSERVATION 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] OBSERVATION 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 `cmdline_crash` nohz_full 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: `.` (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` ### 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] OBSERVATION 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] OBSERVATION 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.` ### 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] OBSERVATION 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///`. ### 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., pids_limit, log_size_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 `.` (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::` 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/:` or `oc tag -d :`. ### 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 `) 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 `.` — 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: `IPC_LOCK`, `SYS_RESOURCE`, 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] OBSERVATION 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 charts/openshift-console-plugin -n --create-namespace --set plugin.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///` ### 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] OBSERVATION 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] OBSERVATION 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 --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] OBSERVATION 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_.db` (the etcd snapshot) and `static_kuberesources_.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/` 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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=`. ### 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] OBSERVATION 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 `SrcK8S_OwnerName`/`DstK8S_OwnerName` over `SrcK8S_Name`/`DstK8S_Name` 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 `-`; 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 `${HOSTED_CLUSTER_NAMESPACE}-${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 `-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] OBSERVATION 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] OBSERVATION 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..apps.` ### 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--`, 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`, 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] OBSERVATION 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] OBSERVATION 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 "" "" ""`. ### 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 `IC_API_KEY` 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 (`:`, 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 `@` (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] OBSERVATION 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] OBSERVATION 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 -- gather_ingress_node_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] OBSERVATION 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 `:` (colon-separated); image stream images are formatted as `@` (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 USE_JAVA_VERSION 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 JAVA_MAX_HEAP_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 (CONTAINER_HEAP_PERCENT=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] OBSERVATION 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 `fail_over_mac=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 `/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 `container_network_*` 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 (KUBELET_LOG_LEVEL=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] OBSERVATION 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 --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] OBSERVATION 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: mcd_drain_err, mcd_pivot_err, mcd_kubelet_state, and mcd_reboot_err. ### mcd-kubelet-health-threshold-2 [IN] OBSERVATION The MCD kubelet health failure threshold is 2 — exceeding it signals a problem via the mcd_kubelet_state 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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/gather_audit_logs` ### 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 `-- gather_network_logs`; 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 (`--enable_pkt_drop`, `--enable_rtt`, `--enable_dns`) 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 `namespace_flows_total`, `node_ingress_bytes_total`, and `workload_ingress_bytes_total` ### 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: `DstK8S_Namespace`, `DstK8S_OwnerName`, `DstK8S_Type`, `DstK8S_Zone`, `FlowDirection`, `K8S_ClusterName`, `K8S_FlowLayer`, `SrcK8S_Namespace`, `SrcK8S_OwnerName`, `SrcK8S_Type`, `SrcK8S_Zone`, `_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 `SKB_DROP`) and OVS drops (prefixed `OVS_DROP`) ### 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/tcp_rcv_established` 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] OBSERVATION 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 `pod_network_name_info` to supplement kubelet's built-in container network metrics. ### network-name-label-format-namespace-nad [IN] OBSERVATION The `network_name` label in `pod_network_name_info` uses the format `/`, 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] OBSERVATION 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 `.`. ### 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] OBSERVATION 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] OBSERVATION 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 (kube_node_status_capacity - kube_node_status_allocatable). ### 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..` and `*.apps..`, 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] OBSERVATION 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] OBSERVATION 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~`, 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] OBSERVATION 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] OBSERVATION 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 -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 ` 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 -n ` 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=` targets a specific version ### oc-adm-upgrade-status-tech-preview [IN] OBSERVATION `oc adm upgrade status` is a Technology Preview command requiring `OC_ENABLE_CMD_UPGRADE_STATUS=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 ` 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 ` ### 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 ` 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=` 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 ` creates a TokenRequest for a service account (bound token with audience/expiry). ### oc-debug-node-chroot-host [IN] OBSERVATION `oc debug 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 .config.openshift.io` shows the schema/documentation for a cluster config resource ### oc-explain-from-cluster-api [IN] OBSERVATION `oc explain ` retrieves documentation directly from the cluster's API schema, useful for exploring resource fields. ### oc-explain-inspects-api-schema [IN] OBSERVATION The `oc explain ` command inspects API object schemas directly from the cluster, with `oc explain .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 ` 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 ` 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=` can instantiate applications from templates ### oc-new-app-tilde-syntax-creates-s2i [IN] OBSERVATION The `oc new-app ~` 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 -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 `HTTP_PROXY`, `HTTPS_PROXY`, 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 ` enables image lookup on an image stream; `oc set image-lookup deploy/` 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/ --liveness|--readiness --get-url=http://:port/path --initial-delay-seconds=N`. ### oc-set-triggers-deploy-syntax [IN] OBSERVATION The command `oc set triggers deploy/ --from-image=: -c ` 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..` and `api-int..` pointing to apiVIP, and `*.apps..` 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 `Standard_D8s_v3` (8 vCPUs each), 3 workers at `Standard_D4s_v3` (4 vCPUs each), and 1 bootstrap at `Standard_D8s_v3` (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 `.`. ### 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 --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 `.`. ### 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":[""]}}}'`. ### 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 `@`. ### 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/red_hat_openshift_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 ` 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/` 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/.` 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..` (public+private), `api-int..` (private only), `*.apps..` (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/` or `vm/` 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] OBSERVATION 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] OBSERVATION 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 container_runtime_crio_containers_oom_count_total. ### 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 ``: Secret `-ca`, ConfigMap `-ca`, and Secret `-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] OBSERVATION 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 ` 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 ` checks catalog validity including duplicate detection and schema violations ### opm-validate-command [IN] OBSERVATION The `opm validate ` 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 `-` (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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 `pod_network_name_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 `container_network_*` metrics with network names, use `+ on(namespace,pod,interface) group_left(network_name) ( pod_network_name_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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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; `keep_firing_for` 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] OBSERVATION 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 ` for cluster-wide and `oc adm policy add-role-to-user -n ` 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 `/` 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 `REGISTRY_STORAGE_S3_ACCESSKEY`/`REGISTRY_STORAGE_S3_SECRETKEY`, GCS uses `REGISTRY_STORAGE_GCS_KEYFILE`, Swift uses `REGISTRY_STORAGE_SWIFT_USERNAME`/`REGISTRY_STORAGE_SWIFT_PASSWORD`, Azure uses `REGISTRY_STORAGE_AZURE_ACCOUNTKEY`. ### 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] OBSERVATION 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] OBSERVATION 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@`. ### 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-x86_64-baseos-rpms`, `rhel-8-for-x86_64-appstream-rpms`, `rhocp-4.17-for-rhel-8-x86_64-rpms`, `fast-datapath-for-rhel-8-x86_64-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] OBSERVATION 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/` reverts to the last successful revision and disables image change triggers; they must be re-enabled with `oc set triggers dc/ --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 `container_use_devices=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 `..` 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] OBSERVATION 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= machinesets.machine.openshift.io -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 -z `. ### 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 : --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] OBSERVATION 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 --from-literal=KEY=VALUE` and attached to deployments with `oc set env --from=secret/ deploy/`. ### security-and-governance-unified-across-all-topologies [IN] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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..` for worker node addition to an SNO cluster. ### sno-dns-records-api-apiint-apps [IN] OBSERVATION SNO clusters require three DNS records: `api..`, `api-int..`, and `*.apps..`. ### 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] OBSERVATION 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 `-` (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] OBSERVATION 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 ` 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 | 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 -n ` (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 `thanos_ruler_replica` 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` (`:`), `ImageStreamImage` (`@`), and `DockerImage` (`//:`). ### 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] OBSERVATION 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` 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] OBSERVATION 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=` 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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] OBSERVATION 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 SO_BINDTODEVICE (requires CAP_NET_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] OBSERVATION 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] OBSERVATION 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.: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 `. ### 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] OBSERVATION 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.