{"nodes":[{"id":"accelerator-device-plugins-daemonsets","text":"Device plugins register GPUs in the cluster and can be deployed manually or as DaemonSets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/accelerator-device-plugins-daemonsets.json"},{"id":"access-modes-rwo-rwx-rox-rwop","text":"PV access modes are ReadWriteOnce (RWO), ReadWriteOncePod (RWOP), ReadOnlyMany (ROX), and ReadWriteMany (RWX); these describe capabilities, not enforced constraints.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/access-modes-rwo-rwx-rox-rwop.json"},{"id":"acl-audit-log-annotation-key","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/acl-audit-log-annotation-key.json"},{"id":"acl-audit-log-default-rate-limit-20","text":"The default audit log rate limit is 20 messages per second per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/acl-audit-log-default-rate-limit-20.json"},{"id":"acl-audit-log-destinations","text":"Valid audit log destination values are: `null` (default), `libc`, `udp:<host>:<port>`, and `unix:<file>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/acl-audit-log-destinations.json"},{"id":"acl-audit-log-file-path","text":"Audit logs are always written to `/var/log/ovn/acl-audit-log.log` on each OVN-Kubernetes pod, regardless of additional destination configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/acl-audit-log-file-path.json"},{"id":"acl-audit-logging-ovn-kubernetes-only","text":"Network policy audit logging is only available with the OVN-Kubernetes network plugin.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/acl-audit-logging-ovn-kubernetes-only.json"},{"id":"additional-trusted-ca-in-openshift-config","text":"The `additionalTrustedCA` ConfigMap referenced by image.config.openshift.io/cluster must be in the `openshift-config` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/additional-trusted-ca-in-openshift-config.json"},{"id":"admin-networkpolicy-cluster-scoped-alpha","text":"AdminNetworkPolicy and BaselineAdminNetworkPolicy (`policy.networking.k8s.io/v1alpha1`) are cluster-scoped network policy resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-networkpolicy-cluster-scoped-alpha.json"},{"id":"admin-policy-external-route-api-group","text":"AdminPolicyBasedExternalRoute is a cluster-scoped CRD in the `k8s.ovn.org/v1` API group, specific to OVN-Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-policy-external-route-api-group.json"},{"id":"admin-policy-external-route-bfd-default-false","text":"BFD (Bidirectional Forwarding Detection) defaults to false on both static and dynamic hops in AdminPolicyBasedExternalRoute","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-policy-external-route-bfd-default-false.json"},{"id":"admin-policy-external-route-dynamic-hop-empty-attachment","text":"When `networkAttachmentName` is empty on a dynamic hop, the system assumes the pod uses HostNetwork and the node IP is used as the gateway","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-policy-external-route-dynamic-hop-empty-attachment.json"},{"id":"admin-policy-external-route-dynamic-hop-requires-both-selectors","text":"Dynamic hops in AdminPolicyBasedExternalRoute require both `podSelector` and `namespaceSelector`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-policy-external-route-dynamic-hop-requires-both-selectors.json"},{"id":"admin-policy-external-route-static-dynamic-hops","text":"AdminPolicyBasedExternalRoute supports two next-hop types: static (fixed IP) and dynamic (IP derived from gateway pods selected by podSelector and namespaceSelector)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admin-policy-external-route-static-dynamic-hops.json"},{"id":"admission-plugins-run-sequentially-in-chain","text":"Admission plugins run sequentially in an admission chain; if any plugin rejects a request, the entire chain aborts and returns an error.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/admission-plugins-run-sequentially-in-chain.json"},{"id":"affinity-ignored-during-execution","text":"\"IgnoredDuringExecution\" in affinity rules means pods are not evicted if labels change after scheduling — the pod continues running on its current node","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/affinity-ignored-during-execution.json"},{"id":"affinity-label-selector-operators","text":"Pod affinity/anti-affinity label selector operators are: `In`, `NotIn`, `Exists`, `DoesNotExist`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/affinity-label-selector-operators.json"},{"id":"affinity-topologykey-mandatory","text":"The `topologyKey` field is mandatory for pod affinity and anti-affinity rules","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/affinity-topologykey-mandatory.json"},{"id":"affinity-weight-range-1-100","text":"Preferred affinity/anti-affinity rules use a `weight` value ranging from 1 to 100","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/affinity-weight-range-1-100.json"},{"id":"agent-and-assisted-installer-support-bare-metal","text":"The Agent-based Installer and Assisted Installer also support bare metal as an installation target, in addition to the standard IPI and UPI methods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/agent-and-assisted-installer-support-bare-metal.json"},{"id":"agent-based-installer-fully-disconnected","text":"The agent-based installer shares the Assisted Installer's discovery ISO approach but runs fully disconnected without needing a service endpoint.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/agent-based-installer-fully-disconnected.json"},{"id":"agent-installer-disconnected","text":"The Agent-based Installer is the disconnected-environment equivalent of the Assisted Installer","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/agent-installer-disconnected.json"},{"id":"alerting-pipeline-rules-to-routing","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alerting-pipeline-rules-to-routing.json"},{"id":"alertingrule-must-be-in-openshift-monitoring-ns","text":"AlertingRule and AlertRelabelConfig resources must be created in the openshift-monitoring namespace; they use apiVersion monitoring.openshift.io/v1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alertingrule-must-be-in-openshift-monitoring-ns.json"},{"id":"alertingrule-namespace-openshift-monitoring","text":"AlertingRule resources for Network Observability alerts must be created in the `openshift-monitoring` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alertingrule-namespace-openshift-monitoring.json"},{"id":"alertingrule-openshift-specific","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alertingrule-openshift-specific.json"},{"id":"alertmanagerconfig-v1beta1","text":"AlertmanagerConfig is at API version `monitoring.coreos.com/v1beta1` (still beta), unlike most other monitoring CRDs which are v1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alertmanagerconfig-v1beta1.json"},{"id":"alertrelabelconfig-modifies-before-alertmanager","text":"AlertRelabelConfig modifies alerts before Alertmanager routes them, not after.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alertrelabelconfig-modifies-before-alertmanager.json"},{"id":"alibaba-cloud-supported-platform","text":"Alibaba Cloud is a supported installation target for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alibaba-cloud-supported-platform.json"},{"id":"allnamespaces-mode-global-operators-group","text":"For AllNamespaces install mode, the `openshift-operators` namespace has a default OperatorGroup called `global-operators`; no additional OperatorGroup is needed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allnamespaces-mode-global-operators-group.json"},{"id":"allnamespaces-mode-uses-openshift-operators","text":"AllNamespaces install mode uses namespace `openshift-operators`; SingleNamespace mode requires creating an OperatorGroup in the target namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allnamespaces-mode-uses-openshift-operators.json"},{"id":"allnamespaces-mode-uses-openshift-operators-namespace","text":"For AllNamespaces install mode, the Subscription goes in the `openshift-operators` namespace which already has the `global-operators` OperatorGroup — no manual OperatorGroup creation needed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allnamespaces-mode-uses-openshift-operators-namespace.json"},{"id":"allowed-blocked-registries-mutually-exclusive","text":"`allowedRegistries` and `blockedRegistries` in image.config.openshift.io/cluster are mutually exclusive — you cannot set both","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allowed-blocked-registries-mutually-exclusive.json"},{"id":"allowed-registries-must-include-system","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allowed-registries-must-include-system.json"},{"id":"allowvolumeexpansion-prerequisite","text":"The `allowVolumeExpansion: true` field on a StorageClass is a prerequisite for all PVC expansion and defaults to false.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/allowvolumeexpansion-prerequisite.json"},{"id":"alternative-topologies-diverge-from-standard-operations","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/alternative-topologies-diverge-from-standard-operations.json"},{"id":"amd-gpu-operator-community-release","text":"The AMD GPU Operator is a community release, not a Red Hat-certified/supported Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/amd-gpu-operator-community-release.json"},{"id":"amd-gpu-operator-install-sequence","text":"AMD GPU Operator installation requires three Operators in sequence: Node Feature Discovery (NFD) Operator, then Kernel Module Management (KMM) Operator, then AMD GPU Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/amd-gpu-operator-install-sequence.json"},{"id":"amd-gpu-resource-identifier","text":"The AMD GPU resource identifier for Kubernetes resource requests and limits is `amd.com/gpu`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/amd-gpu-resource-identifier.json"},{"id":"amd-instinct-mi210-gfx90a","text":"The `gfx90a` architecture identifier corresponds to AMD Instinct MI210 GPUs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/amd-instinct-mi210-gfx90a.json"},{"id":"anp-banp-api-group","text":"AdminNetworkPolicy and BaselineAdminNetworkPolicy use API group `policy.networking.k8s.io/v1alpha1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-banp-api-group.json"},{"id":"anp-cluster-scoped-networkpolicy-namespace-scoped","text":"AdminNetworkPolicy is cluster-scoped while NetworkPolicy is namespace-scoped","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-cluster-scoped-networkpolicy-namespace-scoped.json"},{"id":"anp-cluster-scoped-v1alpha1","text":"AdminNetworkPolicy (ANP) is a cluster-scoped resource using API version `policy.networking.k8s.io/v1alpha1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-cluster-scoped-v1alpha1.json"},{"id":"anp-evaluation-order-anp-np-banp","text":"Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-evaluation-order-anp-np-banp.json"},{"id":"anp-host-networked-pods-excluded","text":"Host-networked pods are excluded from ANP subject and peer selection","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-host-networked-pods-excluded.json"},{"id":"anp-ingress-peers-namespaces-pods-only","text":"ANP ingress peers support only namespaces and pods; egress additionally supports nodes and networks (CIDR)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-ingress-peers-namespaces-pods-only.json"},{"id":"anp-max-100-rules-per-direction","text":"ANP allows a maximum of 100 ingress rules and 100 egress rules per instance","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-max-100-rules-per-direction.json"},{"id":"anp-nodes-networks-egress-only","text":"AdminNetworkPolicy `nodes` and `networks` peer types are valid for egress rules only","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-nodes-networks-egress-only.json"},{"id":"anp-pass-delegates-to-networkpolicy","text":"ANP Pass action delegates the traffic decision to namespace-scoped NetworkPolicy, then to BANP if no NetworkPolicy matches","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-pass-delegates-to-networkpolicy.json"},{"id":"anp-port-default-protocol-tcp","text":"In ANP rules, when no port protocol is specified, the default is TCP; when no ports are specified, the rule matches all ports","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-port-default-protocol-tcp.json"},{"id":"anp-priority-range-0-1000-lower-higher","text":"ANP priority is an integer 0–1000 where lower values mean higher precedence, and two ANPs must not share the same priority","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-priority-range-0-1000-lower-higher.json"},{"id":"anp-priority-range-0-99","text":"AdminNetworkPolicy priority range is 0–99 (maximum 100 ANP policies); lower value = higher precedence","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-priority-range-0-99.json"},{"id":"anp-supports-pass-action","text":"AdminNetworkPolicy (ANP) supports three actions in audit logging: allow, deny, and pass; the `pass` action delegates evaluation to NetworkPolicy or BANP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-supports-pass-action.json"},{"id":"anp-three-actions-allow-deny-pass","text":"ANP rules support three actions: Allow (overrides NetworkPolicy denials), Deny (blocks traffic), and Pass (delegates to NetworkPolicy then BaselineAdminNetworkPolicy)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/anp-three-actions-allow-deny-pass.json"},{"id":"ansible-helm-base-images-not-deprecated","text":"Ansible-based and Helm-based Operator base images are NOT deprecated in OCP 4.17 — only the SDK CLI tooling is deprecated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ansible-helm-base-images-not-deprecated.json"},{"id":"any-platform-upi-installation","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/any-platform-upi-installation.json"},{"id":"api-governance-enforces-stability-and-immutability","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-governance-enforces-stability-and-immutability.json"},{"id":"api-governance-spans-stability-and-admission","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-governance-spans-stability-and-admission.json"},{"id":"api-stability-tiered-guarantee-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-stability-tiered-guarantee-model.json"},{"id":"api-tier1-stable-within-major-release","text":"API Tier 1 is stable within a major release and cannot be removed until a subsequent major release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-tier1-stable-within-major-release.json"},{"id":"api-tier2-stable-9-months-or-3-releases","text":"API Tier 2 is stable for at least 9 months or 3 minor releases from deprecation announcement, whichever is longer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-tier2-stable-9-months-or-3-releases.json"},{"id":"api-tier3-default-for-unassigned-groups","text":"API Tier 3 is the default tier for API groups without an explicit tier assignment; OperatorHub operators fall into this tier.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/api-tier3-default-for-unassigned-groups.json"},{"id":"apirequestcount-default-users-to-report","text":"The default value for `numberOfUsersToReport` in APIRequestCount spec is 10.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-default-users-to-report.json"},{"id":"apirequestcount-instance-naming-pattern","text":"APIRequestCount (`apiserver.openshift.io/v1`) instance names must follow the pattern `resource.version.group` (e.g., `pods.v1`). This is an OpenShift-specific resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-instance-naming-pattern.json"},{"id":"apirequestcount-last24h-indexed-by-hour","text":"APIRequestCount `last24h` is indexed by hour of day (0–23), where index 0 = 12:00AM–12:59AM, not a rolling window.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-last24h-indexed-by-hour.json"},{"id":"apirequestcount-naming-format","text":"APIRequestCount instances are named using the format `resource.version.group` (e.g., `deployments.v1.apps`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-naming-format.json"},{"id":"apirequestcount-openshift-specific-resource","text":"APIRequestCount is an OpenShift-specific resource (`apiserver.openshift.io/v1`), not part of upstream Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-openshift-specific-resource.json"},{"id":"apirequestcount-removedinrelease-field","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apirequestcount-removedinrelease-field.json"},{"id":"apiserver-clientca-openshift-config","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-clientca-openshift-config.json"},{"id":"apiserver-etcd-encryption-resources","text":"Etcd encryption covers: secrets, configmaps, routes, oauthaccesstokens, and oauthauthorizetokens.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-etcd-encryption-resources.json"},{"id":"apiserver-four-audit-profiles","text":"The APIServer supports four audit profiles: `Default`, `WriteRequestBodies`, `AllRequestBodies`, and `None`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-four-audit-profiles.json"},{"id":"apiserver-resource-singleton-cluster","text":"The APIServer resource (`config.openshift.io/v1`) is cluster-scoped and the canonical instance is always named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-resource-singleton-cluster.json"},{"id":"apiserver-shared-by-three-servers","text":"The APIServer config object holds shared settings consumed by `kube-apiserver`, `openshift-apiserver`, and `oauth-apiserver`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-shared-by-three-servers.json"},{"id":"apiserver-tls-modern-not-supported","text":"The `Modern` TLS security profile (TLS 1.3) is not currently supported on the APIServer; maximum available minTLSVersion is `VersionTLS12`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-tls-modern-not-supported.json"},{"id":"apiserver-tls-profiles-mozilla","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiserver-tls-profiles-mozilla.json"},{"id":"apiservice-name-format-version-dot-group","text":"The APIService resource name must follow the format \"version.group\" (e.g., `v1.apps`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiservice-name-format-version-dot-group.json"},{"id":"apiservice-only-https-supported","text":"APIService only supports HTTPS for communication with backing API servers; `insecureSkipTLSVerify` exists but `caBundle` is strongly preferred.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiservice-only-https-supported.json"},{"id":"apiservice-priority-values-convention","text":"Recommended APIService priority values: core `*.k8s.io` groups at 18000, PaaS platforms like OpenShift at 2000s.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiservice-priority-values-convention.json"},{"id":"apiservice-required-fields-priority","text":"APIService has two required spec fields: `groupPriorityMinimum` and `versionPriority`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiservice-required-fields-priority.json"},{"id":"apiservice-service-port-default-443","text":"The APIService `.spec.service.port` defaults to 443 if not specified.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/apiservice-service-port-default-443.json"},{"id":"application-delivery-operates-within-governed-immutable-platform","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/application-delivery-operates-within-governed-immutable-platform.json"},{"id":"application-packaging-and-delivery-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/application-packaging-and-delivery-model.json"},{"id":"appliedclusterresourcequota-api-group","text":"AppliedClusterResourceQuota belongs to the OpenShift-specific API group `quota.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/appliedclusterresourcequota-api-group.json"},{"id":"appliedclusterresourcequota-openshift-specific","text":"AppliedClusterResourceQuota is an OpenShift-specific extension beyond upstream Kubernetes that enforces resource quotas across multiple namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/appliedclusterresourcequota-openshift-specific.json"},{"id":"appliedclusterresourcequota-project-admin-visibility","text":"Project administrators can view AppliedClusterResourceQuota objects in their project without cluster-admin privileges, providing project-scoped visibility of cluster-wide quotas.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/appliedclusterresourcequota-project-admin-visibility.json"},{"id":"appliedclusterresourcequota-read-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/appliedclusterresourcequota-read-only.json"},{"id":"appliedclusterresourcequota-readonly-projection","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/appliedclusterresourcequota-readonly-projection.json"},{"id":"approve-installplan-command","text":"Approve a pending InstallPlan: `oc patch installplan <name> -n <namespace> --type merge --patch '{\"spec\":{\"approved\":true}}'`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/approve-installplan-command.json"},{"id":"argocd-cli-docs-separate-from-ocp","text":"The `argocd` CLI installation docs live under the OpenShift GitOps documentation, not the core OCP documentation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/argocd-cli-docs-separate-from-ocp.json"},{"id":"argocd-max-300-siteconfig-per-application","text":"Each ArgoCD application can manage a maximum of 300 SiteConfig CRs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/argocd-max-300-siteconfig-per-application.json"},{"id":"assisted-installer-jwt-15min","text":"JWT tokens for the Assisted Installer REST API are valid for 15 minutes only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/assisted-installer-jwt-15min.json"},{"id":"assisted-installer-preflight-validation","text":"The Assisted Installer performs pre-flight host validation (CPU, memory, disk, networking) before allowing installation to proceed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/assisted-installer-preflight-validation.json"},{"id":"assisted-installer-saas-or-self-hosted","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/assisted-installer-saas-or-self-hosted.json"},{"id":"assisted-installer-uses-discovery-iso","text":"The Assisted Installer uses a discovery ISO that is booted on target hosts to register them with the installer service.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/assisted-installer-uses-discovery-iso.json"},{"id":"assisted-vs-agent-based-installer","text":"Assisted Installer and Agent-based Installer are two distinct on-premise installation methods for OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/assisted-vs-agent-based-installer.json"},{"id":"auth-dir-contains-kubeconfig-and-password","text":"The `auth/` directory under the install assets directory contains both `kubeconfig` and `kubeadmin-password` files","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/auth-dir-contains-kubeconfig-and-password.json"},{"id":"authentication-canonical-name-cluster","text":"The Authentication resource (`config.openshift.io/v1`) has a canonical instance name of `cluster` and is a cluster-scoped singleton.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/authentication-canonical-name-cluster.json"},{"id":"authentication-default-type-integrated-oauth","text":"The default authentication type (`spec.type`) for the Authentication resource is `IntegratedOAuth`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/authentication-default-type-integrated-oauth.json"},{"id":"authorization-and-resource-governance-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/authorization-and-resource-governance-model.json"},{"id":"authorization-review-apis-post-only","text":"All authorization review APIs (LocalResourceAccessReview, LocalSubjectAccessReview, ResourceAccessReview, SelfSubjectRulesReview) only support POST — they are create-only resources with no GET/LIST/DELETE operations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/authorization-review-apis-post-only.json"},{"id":"automated-etcd-backup-requires-techpreview","text":"Automated etcd backups are a Technology Preview feature requiring the TechPreviewNoUpgrade feature gate, which is irreversible and blocks minor version updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/automated-etcd-backup-requires-techpreview.json"},{"id":"autoscaler-default-expander-random","text":"The default cluster autoscaler expander strategy is `Random`; other options are `LeastWaste` and `Priority`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-default-expander-random.json"},{"id":"autoscaler-default-utilization-threshold","text":"The default autoscaler utilization threshold for scale-down is `\"0.5\"` (50%), expressed as a string value.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-default-utilization-threshold.json"},{"id":"autoscaler-max-nodes-total-includes-control-plane","text":"The `maxNodesTotal` setting in ClusterAutoscaler must account for all machines including control plane nodes, not just autoscaled compute nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-max-nodes-total-includes-control-plane.json"},{"id":"autoscaler-min-replicas-zero-cloud-only","text":"MachineAutoscaler `minReplicas` can be set to `0` on AWS, GCP, Azure, RHOSP, and vSphere only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-min-replicas-zero-cloud-only.json"},{"id":"autoscaler-priority-expander-configmap-name","text":"The priority expander ConfigMap must be named `cluster-autoscaler-priority-expander` in the `openshift-machine-api` namespace; higher integer means higher priority.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-priority-expander-configmap-name.json"},{"id":"autoscaler-requires-machine-autoscaler","text":"The ClusterAutoscaler requires at least one MachineAutoscaler to be deployed; without it, the cluster autoscaler will never scale.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-requires-machine-autoscaler.json"},{"id":"autoscaler-types-pod-vs-node","text":"HorizontalPodAutoscaler scales pod replicas, ClusterAutoscaler sets cluster-wide node scaling policy, and MachineAutoscaler scales specific MachineSets","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaler-types-pod-vs-node.json"},{"id":"autoscaling-and-placement-resource-management","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaling-and-placement-resource-management.json"},{"id":"autoscaling-placement-within-governance","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/autoscaling-placement-within-governance.json"},{"id":"aws-alb-operator-ip-mode-disabled-on-ocp","text":"IP traffic mode is disabled on OCP for the AWS Load Balancer Controller (only works on EKS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-ip-mode-disabled-on-ocp.json"},{"id":"aws-alb-operator-namespace","text":"The AWS Load Balancer Operator runs in the `aws-load-balancer-operator` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-namespace.json"},{"id":"aws-alb-operator-outposts-alb-yes-nlb-no","text":"AWS Outposts supports ALB but not NLB with the AWS Load Balancer Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-outposts-alb-yes-nlb-no.json"},{"id":"aws-alb-operator-requires-nodeport","text":"The AWS Load Balancer Operator requires service type NodePort — not LoadBalancer or ClusterIP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-requires-nodeport.json"},{"id":"aws-alb-operator-rolearn-in-subscription","text":"The `ROLEARN` environment variable is set in the Subscription spec to configure STS for the AWS Load Balancer Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-rolearn-in-subscription.json"},{"id":"aws-alb-operator-two-iam-roles-for-sts","text":"STS clusters require two separate IAM roles for the AWS Load Balancer Operator: one for the Operator and one for the Controller.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-two-iam-roles-for-sts.json"},{"id":"aws-alb-operator-x86-only-no-govcloud","text":"The AWS Load Balancer Operator only supports x86_64 architecture and does not support AWS GovCloud.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-alb-operator-x86-only-no-govcloud.json"},{"id":"aws-cluster-tag-owned-vs-shared","text":"AWS tag `kubernetes.io/cluster/<clusterid>=owned` means the resource is destroyed with the cluster; `shared` means it persists after cluster deletion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-cluster-tag-owned-vs-shared.json"},{"id":"aws-default-lb-type-classic","text":"Default AWS load balancer type for OpenShift is Classic; NLB must be explicitly set via lbType: NLB in install-config.yaml.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-default-lb-type-classic.json"},{"id":"aws-efs-gcp-filestore-not-default-installed","text":"AWS EFS and GCP Filestore CSI drivers are NOT installed by default in OCP 4.17 — they must be installed manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-efs-gcp-filestore-not-default-installed.json"},{"id":"aws-efs-volume-metrics-disabled-by-default","text":"AWS EFS volume metrics in ClusterCSIDriver are disabled by default; the RecursiveWalk option can cause high CPU/memory usage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-efs-volume-metrics-disabled-by-default.json"},{"id":"aws-lb-default-classic","text":"On AWS, the Ingress load balancer type defaults to `Classic`; can be set to `NLB` for network load balancing","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-lb-default-classic.json"},{"id":"aws-local-zone-delete-order","text":"For AWS Local Zone deployments, deletion order is: cluster first, then Local Zone CloudFormation stack, then VPC stack","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-local-zone-delete-order.json"},{"id":"aws-local-zone-mtu-1300","text":"MTU between AWS Local Zone / Wavelength Zone EC2 instances and Region instances is typically 1300.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-local-zone-mtu-1300.json"},{"id":"aws-ocp-user-tags-limit-25","text":"OpenShift on AWS allows up to 25 user-defined tags; 25 additional tags are reserved for OpenShift (50 total).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-ocp-user-tags-limit-25.json"},{"id":"aws-rhel-ami-owner-account-id","text":"Red Hat's AWS account ID for RHEL AMI images is 309956199498.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-rhel-ami-owner-account-id.json"},{"id":"aws-sts-entra-require-manual-operator-approval","text":"AWS STS and Microsoft Entra Workload ID clusters must use Manual approval strategy for Operator subscriptions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/aws-sts-entra-require-manual-operator-approval.json"},{"id":"azure-disk-encryption-set-three-fields","text":"Azure disk encryption set configuration in ClusterCSIDriver requires three fields: name, resourceGroup, and subscriptionID.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-disk-encryption-set-three-fields.json"},{"id":"azure-disk-only-managed-supported","text":"Azure Disk only supports `kind: Managed` in OpenShift; `Shared` and `Dedicated` create unmanaged disks that cannot attach to OCP nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-disk-only-managed-supported.json"},{"id":"azure-file-no-symlinks-default","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-file-no-symlinks-default.json"},{"id":"azure-file-smb-rwx","text":"Azure File uses the SMB (Server Message Block) protocol and supports ReadWriteMany (RWX) access mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-file-smb-rwx.json"},{"id":"azure-stack-hub-separate-from-azure","text":"Azure Stack Hub is a distinct installation target from standard Azure, with different API endpoints, available VM sizes, and networking constraints.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-stack-hub-separate-from-azure.json"},{"id":"azure-supports-ipi-and-upi","text":"OpenShift on Azure supports both Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI) installation methods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/azure-supports-ipi-and-upi.json"},{"id":"balance-slb-no-pod-traffic-load-balancing","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/balance-slb-no-pod-traffic-load-balancing.json"},{"id":"banp-allow-deny-only-no-pass","text":"BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass action, which is ANP-only)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-allow-deny-only-no-pass.json"},{"id":"banp-lowest-precedence-fallback","text":"BaselineAdminNetworkPolicy applies only when no AdminNetworkPolicy or NetworkPolicy matches the traffic — it is the lowest-priority policy layer","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-lowest-precedence-fallback.json"},{"id":"banp-max-100-rules-host-network-excluded","text":"BANP allows maximum 100 rules per direction (ingress/egress), and host-networked pods are excluded from subject and peer selection","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-max-100-rules-host-network-excluded.json"},{"id":"banp-networks-cidr-max-25-affects-internal","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-networks-cidr-max-25-affects-internal.json"},{"id":"banp-only-allow-deny","text":"BaselineAdminNetworkPolicy supports only Allow and Deny actions (no Pass)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-only-allow-deny.json"},{"id":"banp-singleton-named-default","text":"BaselineAdminNetworkPolicy is a singleton resource that must be named `default`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/banp-singleton-named-default.json"},{"id":"bare-metal-edge-fully-autonomous","text":"Bare metal edge deployments achieve full autonomy — provisioned via ZTP, updated via TALM canary gates, and operating with reduced capability profiles — only when SR-IOV drain issues on single-node topology are resolved and the node configuration pipeline validates all inputs.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-edge-fully-autonomous.json"},{"id":"bare-metal-edge-maximum-divergence-from-platform-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-edge-maximum-divergence-from-platform-model.json"},{"id":"bare-metal-edge-requires-full-stack-specialization","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-edge-requires-full-stack-specialization.json"},{"id":"bare-metal-hosts-metal3-only","text":"Bare metal hosts in the Cluster Inventory dashboard card are only visible in metal3 environments","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-hosts-metal3-only.json"},{"id":"bare-metal-ipi-requires-redfish-or-ipmi","text":"Bare metal IPI installation requires Redfish or IPMI-capable hardware for automated provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-ipi-requires-redfish-or-ipmi.json"},{"id":"bare-metal-ipi-uses-bmc","text":"Bare metal IPI (Installer-Provisioned Infrastructure) automates hardware provisioning via baseboard management controllers (BMC) using Redfish or IPMI protocols.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-ipi-uses-bmc.json"},{"id":"bare-metal-ipi-uses-bmc-protocols","text":"Bare metal IPI installations use Baseboard Management Controller (BMC) protocols such as IPMI and Redfish to manage host provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-ipi-uses-bmc-protocols.json"},{"id":"bare-metal-no-hypervisor-layer","text":"Bare metal installations run directly on physical hardware without a virtualization/hypervisor layer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-no-hypervisor-layer.json"},{"id":"bare-metal-provisioning-architecture","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-provisioning-architecture.json"},{"id":"bare-metal-remediation-two-strategies","text":"Bare metal MachineHealthCheck has two mutually exclusive remediation strategies: annotation-based (`external-baremetal`) and metal3-based (`Metal3RemediationTemplate`), both using power-cycle rather than reprovisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-remediation-two-strategies.json"},{"id":"bare-metal-requires-specialized-infra-at-every-layer","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-requires-specialized-infra-at-every-layer.json"},{"id":"bare-metal-supported-install-target","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-supported-install-target.json"},{"id":"bare-metal-upi-manual-provisioning","text":"Bare metal UPI (User-Provisioned Infrastructure) requires the administrator to manually prepare machines, networking, DNS, and load balancers before running the OpenShift installer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-upi-manual-provisioning.json"},{"id":"bare-metal-vsphere-registry-starts-removed","text":"On bare metal, Nutanix, and vSphere, the Image Registry Operator bootstraps as `Removed`; admin must manually switch to `Managed` and configure storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-metal-vsphere-registry-starts-removed.json"},{"id":"bare-pods-not-rescheduled","text":"Bare pods (not managed by a replication controller) are NOT rescheduled upon node failure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bare-pods-not-rescheduled.json"},{"id":"baremetalhost-lives-in-openshift-machine-api","text":"BareMetalHost resources live in the `openshift-machine-api` namespace by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/baremetalhost-lives-in-openshift-machine-api.json"},{"id":"batch-workload-retry-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/batch-workload-retry-model.json"},{"id":"batch-workloads-constrained-by-scheduling-and-retry-semantics","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/batch-workloads-constrained-by-scheduling-and-retry-semantics.json"},{"id":"binding-deprecated-since-v1-7","text":"The Binding (`v1`) resource is deprecated since Kubernetes v1.7; pod-to-node binding should use the `bindings` subresource of pods instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/binding-deprecated-since-v1-7.json"},{"id":"binding-namespace-scoped","text":"Bindings are namespace-scoped resources; the namespace appears in all endpoint paths.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/binding-namespace-scoped.json"},{"id":"binding-post-only-write-once","text":"Bindings support only POST operations — they are write-once and not updatable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/binding-post-only-write-once.json"},{"id":"binding-target-only-required-field","text":"The only required field on a Binding object is `target` (an ObjectReference).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/binding-target-only-required-field.json"},{"id":"binding-v1-deprecated-since-k8s-1.7","text":"The Binding v1 API object has been deprecated since Kubernetes 1.7; the recommended replacement is the bindings subresource of pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/binding-v1-deprecated-since-k8s-1.7.json"},{"id":"block-volumes-require-volumedevices","text":"Block volumes use `volumeMode: Block` on PV and PVC, and pods use `volumeDevices`/`devicePath` instead of `volumeMounts`/`mountPath`, requiring privileged containers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/block-volumes-require-volumedevices.json"},{"id":"bluefield2-dpu-to-nic-one-way-only","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bluefield2-dpu-to-nic-one-way-only.json"},{"id":"bluefield2-multi-device-pci-address-required","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bluefield2-multi-device-pci-address-required.json"},{"id":"bluefield2-switch-requires-sriov-operator","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bluefield2-switch-requires-sriov-operator.json"},{"id":"bmceventsubscription-namespaced","text":"BMCEventSubscription is a namespaced resource (not cluster-scoped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmceventsubscription-namespaced.json"},{"id":"bmceventsubscription-webhook-mechanism","text":"BMCEventSubscription (`metal3.io/v1alpha1`) forwards BMC hardware events to a user-specified webhook URL, with optional custom HTTP headers stored in a Secret.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmceventsubscription-webhook-mechanism.json"},{"id":"bmh-api-group-metal3","text":"BareMetalHost is a Custom Resource with API group `metal3.io/v1alpha1`, used to manage physical bare-metal servers in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-api-group-metal3.json"},{"id":"bmh-bmc-secret-keys-username-password","text":"BMC credentials Secret for BareMetalHost must contain keys named exactly `username` and `password`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-bmc-secret-keys-username-password.json"},{"id":"bmh-default-boot-mode-uefi","text":"The default boot mode for BareMetalHost is UEFI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-default-boot-mode-uefi.json"},{"id":"bmh-hardware-profile-deprecated","text":"The `hardwareProfile` field on BareMetalHost is deprecated; use `architecture` and `rootDeviceHints` instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-hardware-profile-deprecated.json"},{"id":"bmh-live-iso-checksum-ignored","text":"For BareMetalHost image format `live-iso`, checksum fields are ignored; the ISO is live-booted, not written to disk.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-live-iso-checksum-ignored.json"},{"id":"bmh-only-required-field-online","text":"The only required spec field on a BareMetalHost resource is `online` (boolean), which controls whether the server should be powered on.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-only-required-field-online.json"},{"id":"bmh-rootdevicehints-model-vendor-substring","text":"In BareMetalHost `rootDeviceHints`, the `model` and `vendor` fields support substring matching; all other fields require exact match.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-rootdevicehints-model-vendor-substring.json"},{"id":"bmh-software-raid-rules","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bmh-software-raid-rules.json"},{"id":"bond-cni-failovermac-required-active-backup","text":"failOverMac must be set to 1 (mandatory) when using active-backup mode with Bond-CNI in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-failovermac-required-active-backup.json"},{"id":"bond-cni-links-in-container-required","text":"linksInContainer must be set to true in the Bond-CNI NetworkAttachmentDefinition to find interfaces inside the container rather than on the host.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-links-in-container-required.json"},{"id":"bond-cni-only-supports-sriov-vfs","text":"OpenShift Bond-CNI is only supported with SR-IOV virtual functions — other CNI types or interface types are not supported for pod-level bonding.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-only-supports-sriov-vfs.json"},{"id":"bond-cni-sriov-only","text":"The Bond CNI plugin only supports SR-IOV Virtual Functions (VFs) for bonding; it cannot bond arbitrary interfaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-sriov-only.json"},{"id":"bond-cni-supported-modes","text":"OpenShift Bond-CNI supports only three bonding modes: balance-rr (0), active-backup (1), and balance-xor (2).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-supported-modes.json"},{"id":"bond-cni-trust-mode-for-rr-xor","text":"SR-IOV VF trust mode must be set to on when using balance-rr or balance-xor bonding modes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-cni-trust-mode-for-rr-xor.json"},{"id":"bond-pod-annotation-requires-three-networks","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bond-pod-annotation-requires-three-networks.json"},{"id":"bootkube-etcd-connection-refused-normal","text":"During bootstrap, `bootkube.service` etcd \"connection refused\" errors are normal and expected — they resolve once control plane nodes join.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bootkube-etcd-connection-refused-normal.json"},{"id":"bridge-cni-same-host-only","text":"The bridge CNI plugin only enables communication between pods on the same host and with the host itself.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bridge-cni-same-host-only.json"},{"id":"brokertemplateinstance-experimental-cluster-scoped","text":"BrokerTemplateInstance is an experimental, cluster-scoped resource in the `template.openshift.io/v1` API group that links the Template Service Broker to TemplateInstance objects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/brokertemplateinstance-experimental-cluster-scoped.json"},{"id":"build-additional-trusted-ca-deprecated","text":"`spec.additionalTrustedCA` on the Build config resource is deprecated — the correct approach is to use `image.config.openshift.io/cluster` instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-additional-trusted-ca-deprecated.json"},{"id":"build-and-image-delivery-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-and-image-delivery-pipeline.json"},{"id":"build-completion-deadline-from-scheduling","text":"`completionDeadlineSeconds` is counted from when the build pod is scheduled, not from when it is created","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-completion-deadline-from-scheduling.json"},{"id":"build-defaults-vs-overrides","text":"`spec.buildDefaults` values can be overridden by individual BuildConfig objects; `spec.buildOverrides` values cannot be overridden and are forced on all builds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-defaults-vs-overrides.json"},{"id":"build-git-proxy-overrides-default-proxy","text":"`gitProxy` overrides `defaultProxy` for git operations in the Build config; unset `gitProxy` fields inherit from `defaultProxy`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-git-proxy-overrides-default-proxy.json"},{"id":"build-mount-trusted-ca-not-persisted","text":"When `mountTrustedCA` is enabled, changes to `/etc/pki/ca-trust` inside the build are NOT persisted in the output image","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-mount-trusted-ca-not-persisted.json"},{"id":"build-nodeselector-nil-vs-empty","text":"Build nodeSelector: nil inherits cluster defaults; empty map `{}` overrides/ignores cluster defaults; map with values uses those values and ignores defaults","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-nodeselector-nil-vs-empty.json"},{"id":"build-output-kind-imagestream-or-docker","text":"Build output `to` kind must be either `ImageStreamTag` or `DockerImage` — no other kinds are valid","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-output-kind-imagestream-or-docker.json"},{"id":"build-overrides-imagelabels-overwrite","text":"`buildOverrides.imageLabels` overwrites user-provided labels with the same name; `buildDefaults.imageLabels` are overridden by user-provided labels.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-overrides-imagelabels-overwrite.json"},{"id":"build-postcommit-failure-fails-build","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-postcommit-failure-fails-build.json"},{"id":"build-postcommit-no-script-and-command","text":"Post-commit hooks cannot specify both `script` and `command` simultaneously — this is invalid","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-postcommit-no-script-and-command.json"},{"id":"build-secrets-truncated-after-s2i-assemble","text":"Build-injected secrets are truncated to zero length after the Source-to-Image (S2I) assemble script completes as a security measure","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-secrets-truncated-after-s2i-assemble.json"},{"id":"build-strategies-docker-s2i-custom","text":"OpenShift BuildConfig supports three active build strategies: Docker (Dockerfile), Source-to-Image (S2I), and Custom","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-strategies-docker-s2i-custom.json"},{"id":"build-strategy-only-required-field","text":"`spec.strategy` is the only required field in a Build or BuildConfig `.spec`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-strategy-only-required-field.json"},{"id":"build-system-fully-functional","text":"OpenShift build system is fully functional with S2I/Docker/Custom strategies and proper proxy configuration.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-system-fully-functional.json"},{"id":"build-system-openshift-native-duality","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-system-openshift-native-duality.json"},{"id":"build-triggers-webhook-imagechange-manual","text":"BuildConfig can be triggered by webhooks, base image changes, or manual requests.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-triggers-webhook-imagechange-manual.json"},{"id":"build-trusted-ca-key-ca-bundle-crt","text":"Trusted CA ConfigMaps for builds must use the key `ca-bundle.crt` and reside in the `openshift-config` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/build-trusted-ca-key-ca-bundle-crt.json"},{"id":"buildah-podman-skopeo-daemonless-rootless","text":"buildah, podman, and skopeo are daemonless, rootless container tools preferred over Docker in the OCP ecosystem; they produce OCI-standard images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildah-podman-skopeo-daemonless-rootless.json"},{"id":"buildconfig-api-group","text":"BuildConfig uses the API group build.openshift.io/v1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-api-group.json"},{"id":"buildconfig-default-history-limit-5","text":"BuildConfig `failedBuildsHistoryLimit` and `successfulBuildsHistoryLimit` default to retaining the 5 most recent builds; removing the field retains all","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-default-history-limit-5.json"},{"id":"buildconfig-default-runpolicy-serial","text":"BuildConfig default RunPolicy is `Serial` — builds execute one at a time unless changed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-default-runpolicy-serial.json"},{"id":"buildconfig-four-build-strategies","text":"OpenShift BuildConfig supports four build strategies: Source-to-Image (S2I), Docker, Custom, and Pipeline (deprecated, replaced by Tekton).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-four-build-strategies.json"},{"id":"buildconfig-openshift-native-not-upstream-k8s","text":"BuildConfig is a first-class OpenShift API resource for defining builds; it is not present in upstream Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-openshift-native-not-upstream-k8s.json"},{"id":"buildconfig-three-strategies","text":"BuildConfig objects support three build strategies: Docker, Source-to-Image (S2I), and custom.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-three-strategies.json"},{"id":"buildconfig-three-trigger-types","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildconfig-three-trigger-types.json"},{"id":"builder-service-account-runs-builds","text":"The builder service account runs builds and needs appropriate permissions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builder-service-account-runs-builds.json"},{"id":"buildlog-cli-command","text":"Build logs are retrieved via CLI using `oc logs build/<build-name> -n <namespace>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildlog-cli-command.json"},{"id":"buildlog-compatibility-level-1","text":"BuildLog (`build.openshift.io/v1`) is Compatibility Level 1, guaranteed stable within a major release for at least 12 months or 3 minor releases","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildlog-compatibility-level-1.json"},{"id":"buildlog-is-build-subresource","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildlog-is-build-subresource.json"},{"id":"buildrequest-clone-and-instantiate-endpoints","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildrequest-clone-and-instantiate-endpoints.json"},{"id":"buildrequest-docker-strategy-build-args","text":"`dockerStrategyOptions.buildArgs` passes Docker ARG values at build request time; `sourceStrategyOptions.incremental` overrides incremental build setting per-request","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildrequest-docker-strategy-build-args.json"},{"id":"buildrequest-four-webhook-types","text":"BuildRequest supports four webhook trigger types: GitHub, GitLab, Bitbucket, and Generic","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildrequest-four-webhook-types.json"},{"id":"buildrequest-lastversion-optimistic-locking","text":"BuildRequest `lastVersion` field provides optimistic concurrency — if the BuildConfig's version doesn't match, the build won't be generated","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildrequest-lastversion-optimistic-locking.json"},{"id":"buildrequest-triggers-builds","text":"BuildRequest is the mechanism behind `oc start-build` — it is a transient request object (not persistent) used to pass parameters to the build generator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/buildrequest-triggers-builds.json"},{"id":"builds-deployments-resolve-to-sha","text":"When a build/deployment references an image stream tag, OpenShift resolves it to an exact image SHA at build/deploy time, providing deterministic deployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builds-deployments-resolve-to-sha.json"},{"id":"builds-distinct-from-legacy-buildconfig","text":"Builds for Red Hat OpenShift is distinct from the legacy OpenShift Build/BuildConfig API (S2I, Docker, Custom strategies) and is a modern replacement/alternative.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builds-distinct-from-legacy-buildconfig.json"},{"id":"builds-operator-is-shipwright","text":"Builds for Red Hat OpenShift is the Red Hat productized version of the upstream Shipwright project, installed as a separate operator via OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builds-operator-is-shipwright.json"},{"id":"builds-run-as-pods-subject-to-quotas","text":"Builds run as pods in the namespace — they consume cluster resources and are subject to quotas.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builds-run-as-pods-subject-to-quotas.json"},{"id":"builds-uses-tekton-taskruns","text":"Builds for Red Hat OpenShift uses Tekton TaskRuns under the hood to execute builds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/builds-uses-tekton-taskruns.json"},{"id":"bundle-exactly-one-csv","text":"An Operator bundle must contain exactly one ClusterServiceVersion (CSV) and at least one channel.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/bundle-exactly-one-csv.json"},{"id":"cannot-add-health-checks-to-existing-pod-via-cli","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cannot-add-health-checks-to-existing-pod-via-cli.json"},{"id":"cannot-modify-br-ex-via-nncp-post-install","text":"The `br-ex` bridge and its interfaces cannot be modified via NodeNetworkConfigurationPolicy after cluster installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cannot-modify-br-ex-via-nncp-post-install.json"},{"id":"capacity-aware-scheduling-requires-csidriverspec-opt-in","text":"Capacity-aware scheduling must be explicitly enabled via `CSIDriverSpec.StorageCapacity` on the CSI driver.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/capacity-aware-scheduling-requires-csidriverspec-opt-in.json"},{"id":"catalog-priority-higher-wins","text":"When the same package exists in multiple CatalogSources, higher `spec.priority` value wins (default is 0)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalog-priority-higher-wins.json"},{"id":"catalogsource-default-namespace-marketplace","text":"CatalogSources are typically created in the `openshift-marketplace` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-default-namespace-marketplace.json"},{"id":"catalogsource-grpc-image-overrides-address","text":"For grpc CatalogSources, the `image` field takes precedence over `address` — if both are set, `address` is ignored","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-grpc-image-overrides-address.json"},{"id":"catalogsource-grpc-image-standard","text":"CatalogSource `spec.sourceType: grpc` with `spec.image` is the standard way to add custom operator catalogs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-grpc-image-standard.json"},{"id":"catalogsource-priority-higher-wins","text":"CatalogSource `priority` field (int32, default 0) controls dependency resolution preference — higher value wins; ties broken lexicographically by name","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-priority-higher-wins.json"},{"id":"catalogsource-securitycontextconfig-values","text":"CatalogSource `grpcPodConfig.securityContextConfig` accepts `legacy` or `restricted` values; use `legacy` for older catalog images that cannot run non-root","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-securitycontextconfig-values.json"},{"id":"catalogsource-sourcetype-required-field","text":"`sourceType` is the only required spec field for CatalogSource (`operators.coreos.com/v1alpha1`); valid types are `grpc` and `configmap`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-sourcetype-required-field.json"},{"id":"catalogsource-types-grpc-configmap","text":"CatalogSources can be of type `grpc` (index image) or `configmap`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsource-types-grpc-configmap.json"},{"id":"catalogsources-live-in-openshift-marketplace","text":"Default CatalogSources are located in the openshift-marketplace namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/catalogsources-live-in-openshift-marketplace.json"},{"id":"cco-credentials-mode-four-values","text":"The Cloud Credential Operator (CCO) `credentialsMode` field supports four values: `\"\"` (Default), `\"Mint\"`, `\"Passthrough\"`, and `\"Manual\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-credentials-mode-four-values.json"},{"id":"cco-credentials-mode-install-config","text":"The Cloud Credential Operator mode is set via `credentialsMode` in `install-config.yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-credentials-mode-install-config.json"},{"id":"cco-default-mode-probes-credentials","text":"CCO Default mode (`\"\"`) dynamically probes the root credential's capabilities and is only supported on AWS, Azure, and GCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-default-mode-probes-credentials.json"},{"id":"cco-manual-mode-for-sts-workload-identity","text":"CCO Manual mode is required for short-lived token approaches such as AWS STS, GCP Workload Identity, and Azure Managed Identity.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-manual-mode-for-sts-workload-identity.json"},{"id":"cco-manual-mode-upgrade-reconciliation","text":"When CCO is in Manual mode, cloud credentials must be manually reconciled with every cluster upgrade.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-manual-mode-upgrade-reconciliation.json"},{"id":"cco-non-aws-azure-gcp-passthrough-only","text":"Non-AWS/Azure/GCP platforms only support `\"Passthrough\"` credential mode in the Cloud Credential Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-non-aws-azure-gcp-passthrough-only.json"},{"id":"cco-upgradable-false-manual-credentials","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cco-upgradable-false-manual-credentials.json"},{"id":"ccoctl-aws-delete-separate-from-destroy","text":"`ccoctl aws delete --name=<name> --region=<region>` is a separate cleanup step from `openshift-install destroy cluster`, removing IAM roles, policies, OIDC provider, and S3 bucket created for STS","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ccoctl-aws-delete-separate-from-destroy.json"},{"id":"ccoctl-linux-only-binary","text":"The `ccoctl` utility is a Linux-only binary that must match the release image architecture of the target cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ccoctl-linux-only-binary.json"},{"id":"ccoctl-supported-clouds","text":"The `ccoctl` utility supports cloud subcommands for `aws`, `azure`, `gcp`, `ibmcloud`, and `nutanix`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ccoctl-supported-clouds.json"},{"id":"certmanager-cluster-wide-single-install","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/certmanager-cluster-wide-single-install.json"},{"id":"certmanager-metrics-port-9402","text":"cert-manager webhook and cainjector expose Prometheus metrics on port 9402 at the `/metrics` endpoint.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/certmanager-metrics-port-9402.json"},{"id":"certmanager-networkpolicy-disabled-by-default","text":"cert-manager NetworkPolicy hardening is disabled by default and must be explicitly enabled in the CertManager CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/certmanager-networkpolicy-disabled-by-default.json"},{"id":"certmanager-seven-issuer-types","text":"cert-manager Operator supports seven issuer types: ACME, CA, Self-signed, Vault (fully tested), and Venafi, NCM, Google CAS (partially tested).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/certmanager-seven-issuer-types.json"},{"id":"certmanager-two-certificate-request-methods","text":"cert-manager has two certificate request methods: CertificateRequest (requires admin approval) and Certificate (automatic issuance from a referenced Secret via issuerRef).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/certmanager-two-certificate-request-methods.json"},{"id":"check-cco-mode-command","text":"The command `oc get cloudcredentials cluster -o=jsonpath={.spec.credentialsMode}` determines the CCO credential mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/check-cco-mode-command.json"},{"id":"check-cluster-mtu-command","text":"The command to check current cluster network MTU is `oc describe network.config cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/check-cluster-mtu-command.json"},{"id":"check-platform-type-command","text":"The command to check cluster platform type is `oc get infrastructure cluster -o jsonpath='{.status.platform}'`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/check-platform-type-command.json"},{"id":"cicd-strategic-transition-from-jenkins-to-tekton","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cicd-strategic-transition-from-jenkins-to-tekton.json"},{"id":"cli-ga-tier1-tp-tier3-dp-tier4","text":"GA CLI flags/commands are Tier 1; Tech Preview CLI elements are Tier 3; Developer Preview CLI elements are Tier 4.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cli-ga-tier1-tp-tier3-dp-tier4.json"},{"id":"cli-manager-custom-index-url-pattern","text":"The CLI Manager custom Krew index URL pattern is `https://$ROUTE/cli-manager`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cli-manager-custom-index-url-pattern.json"},{"id":"cli-manager-namespace","text":"The CLI Manager Operator requires the namespace `openshift-cli-manager-operator`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cli-manager-namespace.json"},{"id":"cli-manager-operator-tech-preview","text":"The CLI Manager Operator is a Technology Preview feature, not supported for production use.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cli-manager-operator-tech-preview.json"},{"id":"cli-manager-plugin-api","text":"CLI Manager plugins are defined as custom resources with API group `config.openshift.io/v1alpha1`, kind `Plugin`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cli-manager-plugin-api.json"},{"id":"cloud-private-ip-config-admin-changes-overwritten","text":"CloudPrivateIPConfig is internally managed by the network plugin; manual changes by cluster-admins are overwritten on the next reconciliation cycle","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cloud-private-ip-config-admin-changes-overwritten.json"},{"id":"cloud-private-ip-config-egressip-mechanism","text":"CloudPrivateIPConfig (`cloud.network.openshift.io/v1`) is the underlying implementation mechanism for EgressIP on cloud platforms","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cloud-private-ip-config-egressip-mechanism.json"},{"id":"cloud-private-ip-config-name-is-ip","text":"CloudPrivateIPConfig CR name must be the requested private IP address itself, and it supports both IPv4 and IPv6","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cloud-private-ip-config-name-is-ip.json"},{"id":"cloudcredential-resource-cluster-scoped-named-cluster","text":"The CloudCredential resource is cluster-scoped (not namespaced) and is typically named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cloudcredential-resource-cluster-scoped-named-cluster.json"},{"id":"cluster-admin-required-operatorhub-install","text":"`cluster-admin` role is required to install Operators from OperatorHub","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-admin-required-operatorhub-install.json"},{"id":"cluster-api-cannot-manage-control-plane","text":"The Cluster API cannot manage control plane machines — only compute machines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-cannot-manage-control-plane.json"},{"id":"cluster-api-ipam-api-group","text":"The Cluster API IPAM resources (IPAddress and IPAddressClaim) use the API group `ipam.cluster.x-k8s.io/v1beta1` in OpenShift 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-ipam-api-group.json"},{"id":"cluster-api-namespace-openshift-cluster-api","text":"Cluster API resources live in the `openshift-cluster-api` namespace, managed by the Cluster CAPI Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-namespace-openshift-cluster-api.json"},{"id":"cluster-api-requires-techpreviewnoupgrade","text":"Enabling Cluster API requires the `TechPreviewNoUpgrade` feature set, which is irreversible and blocks minor version updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-requires-techpreviewnoupgrade.json"},{"id":"cluster-api-supported-providers","text":"Cluster API in OCP 4.17 supports AWS, Google Cloud, RHOSP, and VMware vSphere.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-supported-providers.json"},{"id":"cluster-api-tech-preview-417","text":"The Cluster API is a Technology Preview feature in OCP 4.17, providing an alternative to the Machine API for compute machine management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-tech-preview-417.json"},{"id":"cluster-api-transition","text":"OpenShift is transitioning toward upstream Cluster API (CAPI), which may coexist with or replace the traditional Machine API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-api-transition.json"},{"id":"cluster-autoscaler-api-version","text":"ClusterAutoscaler uses API version `autoscaling.openshift.io/v1`; MachineAutoscaler uses `autoscaling.openshift.io/v1beta1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-autoscaler-api-version.json"},{"id":"cluster-autoscaler-name-must-be-default","text":"The ClusterAutoscaler resource name must be `\"default\"` and only one can exist per cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-autoscaler-name-must-be-default.json"},{"id":"cluster-certs-expire-one-year","text":"Cluster certificates expire one year after installation; expired control plane certs are auto-retrieved but CSRs must still be manually approved.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-certs-expire-one-year.json"},{"id":"cluster-config-api-group","text":"OpenShift cluster configuration resources (APIServer, Infrastructure, Network, OAuth, Proxy, Scheduler, DNS, Authentication, Ingress) are managed via the `config.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-config-api-group.json"},{"id":"cluster-id-command","text":"Cluster ID is retrieved via `oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{\"\\n\"}'`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-id-command.json"},{"id":"cluster-id-web-console-location","text":"Cluster ID is visible in the web console at Home → Overview → Details → Cluster ID","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-id-web-console-location.json"},{"id":"cluster-level-vs-app-level-backup","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-level-vs-app-level-backup.json"},{"id":"cluster-network-service-network-immutable","text":"`clusterNetwork`, `serviceNetwork`, and `networkType` on the Network config are immutable after installation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-network-service-network-immutable.json"},{"id":"cluster-networking-spans-discovery-and-data-plane","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-networking-spans-discovery-and-data-plane.json"},{"id":"cluster-node-tuning-operator-runs-daemonset","text":"The cluster-node-tuning-operator distributes Tuned rules to containerized TuneD daemons running as a DaemonSet on every node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-node-tuning-operator-runs-daemonset.json"},{"id":"cluster-observability-operator-separate-from-monitoring-stack","text":"The Cluster Observability Operator (COO) is a separate, independently installable operator distinct from the built-in OpenShift monitoring stack (Prometheus, Alertmanager).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-observability-operator-separate-from-monitoring-stack.json"},{"id":"cluster-operators-managed-by-cvo","text":"Cluster Operators are managed by the Cluster Version Operator (CVO), not by OLM. OLM handles optional add-on Operators only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-operators-managed-by-cvo.json"},{"id":"cluster-resource-override-operator-uses-deployment","text":"The Cluster Resource Override Operator now uses a Deployment instead of a DaemonSet, and its pods can be moved to infrastructure nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-resource-override-operator-uses-deployment.json"},{"id":"cluster-resource-quota-selects-by-annotation-or-label","text":"ClusterResourceQuota applies quotas across multiple projects selected by annotation (`openshift.io/requester`) or label selector.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-resource-quota-selects-by-annotation-or-label.json"},{"id":"cluster-samples-operator-deprecated-417","text":"The Cluster Samples Operator is deprecated as of OCP 4.17; only existing S2I builder image streams and templates continue receiving updates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-samples-operator-deprecated-417.json"},{"id":"cluster-samples-operator-openshift-namespace","text":"The Cluster Samples Operator manages sample image streams and templates in the `openshift` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-samples-operator-openshift-namespace.json"},{"id":"cluster-storage-operator-default-sc","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-storage-operator-default-sc.json"},{"id":"cluster-vs-app-backup-distinction","text":"Cluster backup (etcd/control plane) and application backup (OADP/Velero) are distinct procedures in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cluster-vs-app-backup-distinction.json"},{"id":"clusterautoscaler-cluster-scoped","text":"ClusterAutoscaler is a cluster-scoped resource (one per cluster) that controls node-level autoscaling.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-cluster-scoped.json"},{"id":"clusterautoscaler-default-expander-random","text":"ClusterAutoscaler default expander is Random; available options are LeastWaste, Priority, and Random","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-default-expander-random.json"},{"id":"clusterautoscaler-gpu-limit-uses-accelerator-label","text":"ClusterAutoscaler GPU limits match GPU type via the `cluster-api/accelerator` node label","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-gpu-limit-uses-accelerator-label.json"},{"id":"clusterautoscaler-ignore-daemonsets-default-false","text":"ClusterAutoscaler `ignoreDaemonsetsUtilization` defaults to false — DaemonSet pod resources are included in scale-down calculations by default","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-ignore-daemonsets-default-false.json"},{"id":"clusterautoscaler-is-cluster-scoped-singleton","text":"ClusterAutoscaler is a cluster-scoped singleton resource that controls cluster-level autoscaling decisions (adding/removing nodes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-is-cluster-scoped-singleton.json"},{"id":"clusterautoscaler-limits-cores-nodes-memory-gpu","text":"ClusterAutoscaler can set scaling limits on cores, nodes, memory, and GPU, and can be configured to scale up only (not down).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-limits-cores-nodes-memory-gpu.json"},{"id":"clusterautoscaler-prerequisite-for-machineautoscaler","text":"ClusterAutoscaler must exist before MachineAutoscalers can function","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-prerequisite-for-machineautoscaler.json"},{"id":"clusterautoscaler-scaledown-enabled-required","text":"`scaleDown.enabled` is the only required field under `.spec.scaleDown` in ClusterAutoscaler","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-scaledown-enabled-required.json"},{"id":"clusterautoscaler-singleton-cluster-scoped","text":"ClusterAutoscaler is a cluster-scoped singleton resource — only one instance per cluster, not namespaced","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-singleton-cluster-scoped.json"},{"id":"clusterautoscaler-singleton-named-default","text":"The ClusterAutoscaler is a singleton resource — it only responds to a resource named `default`. MachineAutoscaler targets MachineSets.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-singleton-named-default.json"},{"id":"clusterautoscaler-skip-local-storage-default-true","text":"ClusterAutoscaler `skipNodesWithLocalStorage` defaults to true — nodes with EmptyDir/HostPath pods are protected from scale-down by default","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterautoscaler-skip-local-storage-default-true.json"},{"id":"clustercsidriver-name-must-match-csi-driver","text":"The ClusterCSIDriver object name must equal the CSI driver name it manages — this is a hard constraint.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clustercsidriver-name-must-match-csi-driver.json"},{"id":"clustercsidriver-storageclassstate-values","text":"ClusterCSIDriver `storageClassState` has three values: `Managed` (default, continuously reconciles), `Unmanaged` (stops reconciling), and `Removed` (deletes previously created storage classes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clustercsidriver-storageclassstate-values.json"},{"id":"clusterextension-replaces-subscription-operatorgroup","text":"ClusterExtension (`olm.operatorframework.io/v1alpha1`) is a single cluster-scoped API object that replaces the previous Subscription + OperatorGroup multi-object approach from classic OLM","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterextension-replaces-subscription-operatorgroup.json"},{"id":"clusterextension-version-strategies","text":"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\"`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterextension-version-strategies.json"},{"id":"clustergroupupgrade-cr-remediates-policies","text":"`ClusterGroupUpgrade` CRs (via TALM) are used to remediate and roll out policy changes to managed spoke clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clustergroupupgrade-cr-remediates-policies.json"},{"id":"clusterlogforwarder-controls-log-destination","text":"The ClusterLogForwarder custom resource controls where logs are forwarded/sent.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterlogforwarder-controls-log-destination.json"},{"id":"clusteroperator-shortname-co","text":"The `oc get clusteroperators` command (short name `co`) lists all cluster operators and their status.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusteroperator-shortname-co.json"},{"id":"clusteroperator-three-standard-conditions","text":"The three standard ClusterOperator condition types are `Available`, `Progressing`, and `Degraded`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusteroperator-three-standard-conditions.json"},{"id":"clusteroperator-version-after-rollout","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusteroperator-version-after-rollout.json"},{"id":"clusterresourcequota-openshift-specific","text":"ClusterResourceQuota is an OpenShift-specific resource (`quota.openshift.io/v1`), not available in vanilla Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterresourcequota-openshift-specific.json"},{"id":"clusterresourcequota-required-fields","text":"ClusterResourceQuota spec requires two fields: `quota` (resource limits) and `selector` (which projects are affected).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterresourcequota-required-fields.json"},{"id":"clusterresourcequota-scale-dozens","text":"ClusterResourceQuota selectors should target active projects on the scale of dozens — performance degrades with too many actively-creating projects contending on the resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterresourcequota-scale-dozens.json"},{"id":"clusterresourcequota-selector-both-must-match","text":"When a ClusterResourceQuota selector specifies both label and annotation selectors, a project must match both to be subject to the quota.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterresourcequota-selector-both-must-match.json"},{"id":"clusterresourcequota-spans-namespaces","text":"ClusterResourceQuota is an OpenShift object that defines resource quotas across multiple namespaces via label or annotation selectors.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterresourcequota-spans-namespaces.json"},{"id":"clusterrole-aggregation-via-label-selectors","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-aggregation-via-label-selectors.json"},{"id":"clusterrole-aggregationrule-overwrites-rules","text":"When a ClusterRole has an AggregationRule set, direct edits to the `rules` field are overwritten by the controller — rules become controller-managed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-aggregationrule-overwrites-rules.json"},{"id":"clusterrole-cluster-scoped-not-namespaced","text":"ClusterRole (`rbac.authorization.k8s.io/v1`) is a cluster-scoped resource — it is not created within a namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-cluster-scoped-not-namespaced.json"},{"id":"clusterrole-empty-apigroups-means-both","text":"In an OpenShift PolicyRule, an empty `apiGroups` field means both Kubernetes and OpenShift API groups are assumed (permits actions in either).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-empty-apigroups-means-both.json"},{"id":"clusterrole-nonresourceurls-only-with-clusterrolebinding","text":"The `nonResourceURLs` field in a ClusterRole PolicyRule only takes effect when the ClusterRole is referenced from a ClusterRoleBinding, not from a namespaced RoleBinding.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-nonresourceurls-only-with-clusterrolebinding.json"},{"id":"clusterrole-openshift-api-group","text":"OpenShift has its own ClusterRole API at `authorization.openshift.io/v1`, distinct from the Kubernetes `rbac.authorization.k8s.io/v1` ClusterRole API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-openshift-api-group.json"},{"id":"clusterrole-policyrule-verbs-only-required","text":"In a ClusterRole PolicyRule, `verbs` is the only required field.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrole-policyrule-verbs-only-required.json"},{"id":"clusterrolebinding-namespace-on-user-group-is-error","text":"Setting the `namespace` field on a User or Group subject in a ClusterRoleBinding is an error; `namespace` is only valid for ServiceAccount subjects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrolebinding-namespace-on-user-group-is-error.json"},{"id":"clusterrolebinding-requires-subjects-roleref","text":"A ClusterRoleBinding requires both `subjects` and `roleRef` fields; `userNames` and `groupNames` are legacy backward-compatibility fields that newer clients should not use.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrolebinding-requires-subjects-roleref.json"},{"id":"clusterrolebinding-roleref-immutable","text":"The `roleRef` field on a ClusterRoleBinding is required and immutable — to change the referenced role, you must delete and recreate the binding.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrolebinding-roleref-immutable.json"},{"id":"clusterrolebinding-subject-serviceaccount-core-apigroup","text":"In a ClusterRoleBinding subject, ServiceAccount uses apiGroup `\"\"` (core API group), while User and Group use `rbac.authorization.k8s.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterrolebinding-subject-serviceaccount-core-apigroup.json"},{"id":"clustertask-deprecated-pipelines-110","text":"ClusterTask functionality is deprecated as of OpenShift Pipelines 1.10 and planned for removal.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clustertask-deprecated-pipelines-110.json"},{"id":"clusterversion-architecture-single-to-multi-only","text":"The `architecture` field in ClusterVersion `desiredUpdate` only supports transitioning from single architecture to `Multi`; it cannot be reversed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-architecture-single-to-multi-only.json"},{"id":"clusterversion-baseline-capability-default-vcurrent","text":"The `baselineCapabilitySet` in ClusterVersion defaults to `vCurrent`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-baseline-capability-default-vcurrent.json"},{"id":"clusterversion-channel-controls-updates","text":"The `channel` field on ClusterVersion controls which update stream the cluster subscribes to (e.g., `stable-4.17`, `fast-4.17`, `candidate-4.17`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-channel-controls-updates.json"},{"id":"clusterversion-conditional-vs-available-updates","text":"`availableUpdates` are unconditionally recommended; `conditionalUpdates` are recommended only if the cluster meets specific conditions (evaluated via PromQL).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-conditional-vs-available-updates.json"},{"id":"clusterversion-config-openshift-api","text":"ClusterVersion (`config.openshift.io/v1`) tracks the cluster's current and desired version — key for upgrades.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-config-openshift-api.json"},{"id":"clusterversion-force-bypasses-verification","text":"The `force` flag on `desiredUpdate` in ClusterVersion bypasses image verification and upgradeable checks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-force-bypasses-verification.json"},{"id":"clusterversion-history-command","text":"ClusterVersion history is viewed with `oc describe clusterversions/version` or via the web console at Administration → Cluster Settings → Details tab.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-history-command.json"},{"id":"clusterversion-history-has-size-limit","text":"ClusterVersion history has a size limit — oldest z-stream updates in previous minor versions are pruned first.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-history-has-size-limit.json"},{"id":"clusterversion-history-states","text":"ClusterVersion update history entries have state `Completed` (fully applied) or `Partial` (not fully applied or failed).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-history-states.json"},{"id":"clusterversion-image-overrides-version","text":"When `image` is specified in `desiredUpdate` on ClusterVersion, the `version` field is silently ignored.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-image-overrides-version.json"},{"id":"clusterversion-requires-cluster-admin","text":"Querying the ClusterVersion resource requires `cluster-admin` privileges.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-requires-cluster-admin.json"},{"id":"clusterversion-resource-api-group","text":"The ClusterVersion resource is in the `config.openshift.io/v1` API group with Kind `ClusterVersion` and is cluster-scoped (no namespace).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-resource-api-group.json"},{"id":"clusterversion-single-object-named-version","text":"There is only one ClusterVersion object per cluster and its resource name is `version`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/clusterversion-single-object-named-version.json"},{"id":"cmdline-crash-nohz-full-must-match-cpu-isolated","text":"The `cmdline_crash` nohz_full CPU set must match `cpu.isolated` in the PerformanceProfile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cmdline-crash-nohz-full-must-match-cpu-isolated.json"},{"id":"cmo-config-via-configmaps","text":"The Cluster Monitoring Operator (CMO) is configured via ConfigMaps, not CRDs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cmo-config-via-configmaps.json"},{"id":"cno-default-cluster-network-cidr","text":"Default cluster network CIDR is `10.128.0.0/14` with hostPrefix `23`; default service network is `172.30.0.0/16`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-default-cluster-network-cidr.json"},{"id":"cno-gatewayconfig-changeable-post-install","text":"The `gatewayConfig` field is the exception to post-install immutability — it can be changed at runtime.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-gatewayconfig-changeable-post-install.json"},{"id":"cno-ip-forwarding-restricted-default-new-installs","text":"IP forwarding defaults to `Restricted` for new OCP 4.14+ installs and `Global` for upgrades to 4.14+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-ip-forwarding-restricted-default-new-installs.json"},{"id":"cno-ipsec-modes-disabled-external-full","text":"IPsec configuration supports three modes: `Disabled`, `External` (external traffic only), and `Full` (pod traffic and external traffic).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-ipsec-modes-disabled-external-full.json"},{"id":"cno-namespace-openshift-network-operator","text":"The Cluster Network Operator runs in the `openshift-network-operator` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-namespace-openshift-network-operator.json"},{"id":"cno-object-name-always-cluster","text":"The Cluster Network Operator configuration object is always named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-object-name-always-cluster.json"},{"id":"cno-ovn-kubernetes-only-supported-cni","text":"OVN-Kubernetes is the only supported network plugin for new OpenShift Container Platform installations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-ovn-kubernetes-only-supported-cni.json"},{"id":"cno-ovn-kubernetes-uses-geneve-port-6081","text":"OVN-Kubernetes uses Geneve (Generic Network Virtualization Encapsulation) as the overlay network on default port 6081.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-ovn-kubernetes-uses-geneve-port-6081.json"},{"id":"cno-post-install-only-clusternetwork-modifiable","text":"After installation, only the `clusterNetwork` IP address range can be modified; `serviceNetwork` and `networkType` are read-only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cno-post-install-only-clusternetwork-modifiable.json"},{"id":"cnv-based-on-kubevirt","text":"OpenShift Virtualization is based on the KubeVirt upstream open-source project","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-based-on-kubevirt.json"},{"id":"cnv-do-not-create-vms-in-openshift-namespaces","text":"VMs should not be created in `openshift-*` namespaces; use custom namespaces without the `openshift` prefix","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-do-not-create-vms-in-openshift-namespaces.json"},{"id":"cnv-eus-update-procedure-8-steps","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-eus-update-procedure-8-steps.json"},{"id":"cnv-golden-images-namespace","text":"Golden images are stored in the `openshift-virtualization-os-images` namespace by default, customizable via `spec.commonBootImageNamespace` in the HyperConverged CR","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-golden-images-namespace.json"},{"id":"cnv-guest-serial-console-log-disabled-by-default","text":"Guest system serial console log access is disabled by default in OpenShift Virtualization, controlled via `spec.virtualMachineOptions.disableSerialConsoleLog` in the HyperConverged CR","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-guest-serial-console-log-disabled-by-default.json"},{"id":"cnv-hostpath-provisioner-no-live-migrate","text":"VMs using hostpath provisioner storage cannot be live migrated; workaround is setting `evictionStrategy: None` and `runStrategy: Always`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-hostpath-provisioner-no-live-migrate.json"},{"id":"cnv-installed-via-operatorhub","text":"OpenShift Virtualization is installed as an Operator via OperatorHub, not built into the base platform","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-installed-via-operatorhub.json"},{"id":"cnv-instancetype-cpu-memory-required-no-override","text":"Instance type `cpu` and `memory` are required attributes and cannot be overridden when creating a VM from an instance type","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-instancetype-cpu-memory-required-no-override.json"},{"id":"cnv-instancetype-namespaced-vs-cluster","text":"`VirtualMachineInstancetype` is namespaced and `VirtualMachineClusterInstancetype` is cluster-wide; same pattern for preferences (`VirtualMachinePreference` vs `VirtualMachineClusterPreference`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-instancetype-namespaced-vs-cluster.json"},{"id":"cnv-instancetype-naming-convention","text":"Pre-defined instance type naming convention: `<series><version>.<size>` (e.g., `u1.medium`, `cx1.2xlarge`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-instancetype-naming-convention.json"},{"id":"cnv-instancetype-series-definitions","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-instancetype-series-definitions.json"},{"id":"cnv-live-migration-requires-rwx","text":"OpenShift Virtualization live migration requires shared storage with RWX (ReadWriteMany) access mode","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-live-migration-requires-rwx.json"},{"id":"cnv-livemigrate-default-workload-update-method","text":"`LiveMigrate` is the default and only enabled workload update method for OpenShift Virtualization; `Evict` must be explicitly added","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-livemigrate-default-workload-update-method.json"},{"id":"cnv-log-verbosity-hyperconverged-cr","text":"OpenShift Virtualization log verbosity is configured per-component in the HyperConverged CR at `spec.logVerbosityConfig.kubevirt` with values 1–9","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-log-verbosity-hyperconverged-cr.json"},{"id":"cnv-machine-type-not-auto-changed-on-update","text":"VM `machineType` is not automatically changed during OpenShift Virtualization updates; the VM must be shut down before changing it","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-machine-type-not-auto-changed-on-update.json"},{"id":"cnv-migration-timeout-5min-unschedulable","text":"During workload updates, VMI migration times out after 5 minutes if `Unschedulable` and 15 minutes for any other pending reason","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-migration-timeout-5min-unschedulable.json"},{"id":"cnv-must-gather-default-parallel-5","text":"The default number of parallel processes for OpenShift Virtualization must-gather is 5, controlled by the `PROS` environment variable","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-must-gather-default-parallel-5.json"},{"id":"cnv-must-gather-image","text":"The must-gather image for OpenShift Virtualization is `registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v<version>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-must-gather-image.json"},{"id":"cnv-must-gather-instancetypes-not-default","text":"Instance types information is not collected by default with must-gather; it requires the explicit `--instancetypes` flag","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-must-gather-instancetypes-not-default.json"},{"id":"cnv-must-gather-ns-mandatory-with-vm","text":"The `NS` environment variable is mandatory when using the `VM` variable with must-gather for OpenShift Virtualization","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-must-gather-ns-mandatory-with-vm.json"},{"id":"cnv-per-vm-log-overrides-cluster","text":"Per-VM guest log settings take precedence over cluster-wide defaults in OpenShift Virtualization","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-per-vm-log-overrides-cluster.json"},{"id":"cnv-pods-namespace-openshift-cnv","text":"OpenShift Virtualization pods (virt-api, virt-controller, virt-handler, virt-launcher, virt-operator) run in the `openshift-cnv` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-pods-namespace-openshift-cnv.json"},{"id":"cnv-prometheus-retention-7-days-minimum","text":"Prometheus retention should be set to a minimum of 7 days before collecting OpenShift Virtualization support data","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-prometheus-retention-7-days-minimum.json"},{"id":"cnv-requires-bare-metal-or-nested-virt","text":"OpenShift Virtualization requires bare-metal or supported nested-virtualization infrastructure; not supported on all cloud providers without specific enablement","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-requires-bare-metal-or-nested-virt.json"},{"id":"cnv-runstrategy-and-running-mutually-exclusive","text":"`runStrategy` and `spec.running` are mutually exclusive on a VirtualMachine resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-runstrategy-and-running-mutually-exclusive.json"},{"id":"cnv-runstrategy-values","text":"VirtualMachine `runStrategy` values: `Always` (restarts if stopped), `Halted` (VM stopped), `RerunOnFailure` (restarts only on failure), `Manual` (manual start/stop via virtctl)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-runstrategy-values.json"},{"id":"cnv-stable-channel-automatic-approval-recommended","text":"The recommended update settings for OpenShift Virtualization are the `stable` channel with `Automatic` approval strategy","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-stable-channel-automatic-approval-recommended.json"},{"id":"cnv-update-ocp-first-then-cnv","text":"OpenShift Virtualization cannot be updated to the next minor version without first updating OCP to that minor version","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-update-ocp-first-then-cnv.json"},{"id":"cnv-version-must-match-ocp-version","text":"OpenShift Virtualization minor version must match the OpenShift Container Platform minor version (e.g., 4.17 on 4.17)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cnv-version-must-match-ocp-version.json"},{"id":"compatibility-level-1-means-12-months-or-3-releases","text":"Compatibility Level 1 means an API is stable for at least 12 months or 3 minor releases, whichever is longer","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-means-12-months-or-3-releases.json"},{"id":"compatibility-level-1-stability","text":"Compatibility Level 1 APIs in OpenShift are stable for a minimum of 12 months or 3 minor releases within a major release","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stability.json"},{"id":"compatibility-level-1-stability-guarantee","text":"OpenShift Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stability-guarantee.json"},{"id":"compatibility-level-1-stable","text":"Compatibility Level 1 on OpenShift-specific APIs means stable for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stable.json"},{"id":"compatibility-level-1-stable-12-months","text":"Compatibility Level 1 APIs in OpenShift are stable within a major release for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stable-12-months.json"},{"id":"compatibility-level-1-stable-12-months-3-releases","text":"Compatibility Level 1 OpenShift APIs are stable within a major release for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stable-12-months-3-releases.json"},{"id":"compatibility-level-1-stable-12mo-3minor","text":"Compatibility Level 1 APIs are stable within a major release for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-1-stable-12mo-3minor.json"},{"id":"compatibility-level-definitions","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/compatibility-level-definitions.json"},{"id":"complete-governed-software-delivery-operational","text":"The governed software delivery pipeline (build→image→operator→console with identity-gated access and image supply chain governance) is fully operational end-to-end only when legacy DeploymentConfig deprecation is resolved and OLM v1 reaches GA.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/complete-governed-software-delivery-operational.json"},{"id":"complete-networking-discovery-data-and-addressing","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/complete-networking-discovery-data-and-addressing.json"},{"id":"complete-software-delivery-from-build-to-console","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/complete-software-delivery-from-build-to-console.json"},{"id":"complete-software-delivery-operational","text":"The complete software delivery pipeline (build→image→operator→console) is fully operational end-to-end only when legacy deprecations are resolved and the OLM lifecycle is fully GA.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/complete-software-delivery-operational.json"},{"id":"component-route-certs-openshift-config","text":"Serving certificate secrets for component routes must be type `kubernetes.io/tls` in the `openshift-config` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/component-route-certs-openshift-config.json"},{"id":"componentstatus-deprecated-since-k8s-1.19","text":"ComponentStatus is deprecated since Kubernetes v1.19 and remains only for backward compatibility.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/componentstatus-deprecated-since-k8s-1.19.json"},{"id":"componentstatus-deprecated-since-v1-19","text":"ComponentStatus (`v1`) is deprecated since Kubernetes v1.19.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/componentstatus-deprecated-since-v1-19.json"},{"id":"componentstatus-only-healthy-condition-type","text":"The only valid condition type for ComponentStatus is `\"Healthy\"`, with status values `\"True\"`, `\"False\"`, or `\"Unknown\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/componentstatus-only-healthy-condition-type.json"},{"id":"componentstatus-read-only-cluster-scoped","text":"ComponentStatus is a read-only, cluster-scoped resource with only GET endpoints (no create, update, or delete).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/componentstatus-read-only-cluster-scoped.json"},{"id":"conditional-updates-not-recommended-flag","text":"Conditional (not-recommended) updates can be viewed with `oc adm upgrade --include-not-recommended` and applied with `--allow-not-recommended`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/conditional-updates-not-recommended-flag.json"},{"id":"confidential-containers-use-tee","text":"Confidential containers extend sandboxed containers with hardware-level trusted execution environments (TEEs) such as AMD SEV and Intel TDX for data protection.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/confidential-containers-use-tee.json"},{"id":"config-api-23-resources","text":"The Config APIs in OpenShift 4.17 contain approximately 23 cluster-wide configuration resources under `config.openshift.io/v1` (and `helm.openshift.io/v1beta1`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-api-23-resources.json"},{"id":"config-api-changes-trigger-operator-reconciliation","text":"Changes to Config API resources trigger reconciliation by Cluster Operators","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-api-changes-trigger-operator-reconciliation.json"},{"id":"config-api-group-name","text":"The primary API group for OpenShift cluster configuration resources is `config.openshift.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-api-group-name.json"},{"id":"config-api-objects-cluster-scoped","text":"Config API objects under `config.openshift.io` are cluster-scoped (not namespaced) and apply platform-wide.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-api-objects-cluster-scoped.json"},{"id":"config-api-objects-examples","text":"Config API objects include Infrastructure, Ingress, DNS, Proxy, Network, OAuth, Scheduler, APIServer, and FeatureGate","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-api-objects-examples.json"},{"id":"config-apis-group-config-openshift-io","text":"Config API objects in OpenShift live under the `config.openshift.io` API group and are typically cluster-scoped singletons named `cluster`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-apis-group-config-openshift-io.json"},{"id":"config-drift-marks-node-degraded","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-drift-marks-node-degraded.json"},{"id":"config-openshift-io-api-group","text":"Cluster-wide configuration resources live under the `config.openshift.io` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-openshift-io-api-group.json"},{"id":"config-operator-bootstrap-initial-config","text":"The Config Operator (`operator.openshift.io/v1`) is a bootstrap-level operator that creates the initial configuration of other cluster components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-operator-bootstrap-initial-config.json"},{"id":"config-operator-cloud-sync-aws-azure-only","text":"The Config Operator handles cloud configuration migration and synchronization specifically for AWS and Azure (not all cloud providers).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/config-operator-cloud-sync-aws-azure-only.json"},{"id":"configmap-binarydata-base64","text":"ConfigMaps use the `binaryData` field for non-UTF8 content, stored as Base64-encoded values.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-binarydata-base64.json"},{"id":"configmap-binarydata-requires-v1.10","text":"ConfigMap `binaryData` field requires apiserver and kubelet v1.10 or later.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-binarydata-requires-v1.10.json"},{"id":"configmap-data-binarydata-keys-must-not-overlap","text":"Keys in a ConfigMap's `data` and `binaryData` fields must not overlap; this is enforced at validation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-data-binarydata-keys-must-not-overlap.json"},{"id":"configmap-envfrom-injects-all-keys","text":"Using `envFrom` with `configMapRef` injects all keys from a ConfigMap as environment variables, while `env` with `configMapKeyRef` injects individual keys.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-envfrom-injects-all-keys.json"},{"id":"configmap-immutable-prevents-data-updates","text":"Setting `immutable: true` on a ConfigMap prevents updates to `data` and `binaryData`; the ConfigMap must be deleted and recreated to change data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-immutable-prevents-data-updates.json"},{"id":"configmap-key-naming-rules","text":"ConfigMap keys must contain only alphanumeric characters, `-`, `_`, or `.`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-key-naming-rules.json"},{"id":"configmap-must-exist-before-pod","text":"ConfigMaps must be created before pods that reference them, unless the reference is marked `optional: true`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-must-exist-before-pod.json"},{"id":"configmap-namespace-scoped","text":"ConfigMaps in OpenShift/Kubernetes are namespace-scoped and can only be referenced by pods in the same project.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-namespace-scoped.json"},{"id":"configmap-no-encryption","text":"ConfigMaps do not provide encryption; Secrets should be used for sensitive data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-no-encryption.json"},{"id":"configmap-only-api-created-pods","text":"Only pods created via the API server (CLI, replication controllers) can use ConfigMaps — not pods from `--manifest-url`, `--config` flag, or node REST API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-only-api-created-pods.json"},{"id":"configmap-volume-mount-keys-as-files","text":"When a ConfigMap is mounted as a volume, each key becomes a filename and each value becomes the file content.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/configmap-volume-mount-keys-as-files.json"},{"id":"connected-cluster-definition","text":"A \"connected cluster\" is one that reports data to Red Hat via Telemetry and the Insights Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/connected-cluster-definition.json"},{"id":"console-api-changes-dynamic-no-restart","text":"Console API CRD changes are picked up dynamically — no console restart is needed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-changes-dynamic-no-restart.json"},{"id":"console-api-compatibility-level-1-resources","text":"ConsolePlugin and ConsoleSample have Compatibility Level 1 (stable 12 months or 3 minor releases)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-compatibility-level-1-resources.json"},{"id":"console-api-compatibility-level-2-duration","text":"Console API resources at Compatibility Level 2 are stable for a minimum of 9 months or 3 minor releases within a major release","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-compatibility-level-2-duration.json"},{"id":"console-api-eight-crds","text":"Eight Console API CRDs exist: ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-eight-crds.json"},{"id":"console-api-group-config-openshift-io","text":"The Console config API group is `config.openshift.io/v1`, not `console.openshift.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-group-config-openshift-io.json"},{"id":"console-api-group-resources","text":"The `console.openshift.io/v1` API group includes ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, ConsoleYAMLSample, ConsoleLink, ConsoleExternalLogLink, and ConsoleCLIDownload resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-group-resources.json"},{"id":"console-api-href-requires-https","text":"All Console API resources that accept URLs (ConsoleLink, ConsoleCLIDownload, ConsoleExternalLogLink) require HTTPS — HTTP URLs are not allowed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-href-requires-https.json"},{"id":"console-api-resource-types","text":"Console API resource types include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, ConsoleSample, and ConsoleYAMLSample","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-resource-types.json"},{"id":"console-api-resources-list","text":"Key Console API resources include ConsoleCLIDownload, ConsoleExternalLogLink, ConsoleLink, ConsoleNotification, ConsolePlugin, ConsoleQuickStart, and ConsoleYAMLSample","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-api-resources-list.json"},{"id":"console-apis-api-group","text":"All Console API custom resources belong to the `console.openshift.io/v1` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-apis-api-group.json"},{"id":"console-apis-group-console-openshift-io","text":"Console API resources belong to the console.openshift.io/v1 API group and are OpenShift-specific (not in upstream Kubernetes)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-apis-group-console-openshift-io.json"},{"id":"console-apis-openshift-specific","text":"Console APIs are OpenShift-specific and do not exist in upstream Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-apis-openshift-specific.json"},{"id":"console-config-singleton-named-cluster","text":"The Console resource (`config.openshift.io/v1`) is a cluster-scoped singleton always named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-config-singleton-named-cluster.json"},{"id":"console-custom-logo-configmap-openshift-config","text":"Custom console logos are stored in a ConfigMap in the `openshift-config` namespace, not in the operator spec directly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-custom-logo-configmap-openshift-config.json"},{"id":"console-custom-route-secret-keys","text":"Custom console route TLS secrets must contain keys `tls.crt` and `tls.key` and be stored in the `openshift-config` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-custom-route-secret-keys.json"},{"id":"console-customization-resources","text":"Console customization uses resources `ConsoleLink`, `ConsoleNotification`, and `ConsoleCLIDownload` along with the Console operator config (`operator.openshift.io/v1`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-customization-resources.json"},{"id":"console-default-kubeadmin-user","text":"The default administrative user after installation is `kubeadmin` with a generated password stored in `auth/kubeadmin-password`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-default-kubeadmin-user.json"},{"id":"console-default-url-pattern","text":"The default console route follows the pattern `https://console-openshift-console.apps.<cluster_domain>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-default-url-pattern.json"},{"id":"console-deployment-namespace","text":"The web console is served by the `console-openshift-console` deployment in the `openshift-console` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-deployment-namespace.json"},{"id":"console-logout-redirect-required-for-sso","text":"The `spec.authentication.logoutRedirect` field on the Console config is required when using SSO identity providers (OpenID, RequestHeader, OAuth) to enable single logout (SLO).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-logout-redirect-required-for-sso.json"},{"id":"console-openshift-io-v1-tier2","text":"console.openshift.io/v1 is Tier 2, not Tier 1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-openshift-io-v1-tier2.json"},{"id":"console-operator-optional","text":"The Console Operator can be disabled without affecting cluster supportability or upgradeability.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-operator-optional.json"},{"id":"console-operator-singleton-named-cluster","text":"The Console operator resource is a singleton cluster-scoped resource named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-operator-singleton-named-cluster.json"},{"id":"console-perspective-visibility-states","text":"Console perspective visibility can be set to `Enabled`, `Disabled`, or `AccessReview` (gated on RBAC access review checks).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-perspective-visibility-states.json"},{"id":"console-plugin-deployable","text":"A ConsolePlugin is deployable when it has HTTPS backend and OLM registration.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-plugin-deployable.json"},{"id":"console-plugin-integration-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-plugin-integration-model.json"},{"id":"console-plugins-enabled-via-spec-plugins-array","text":"Console plugins are enabled by adding their name to the `spec.plugins` array on the Console operator resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-plugins-enabled-via-spec-plugins-array.json"},{"id":"console-plugins-registered-via-olm","text":"Operator bundles can declare ConsolePlugin resources to register UI extensions through OLM integration","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-plugins-registered-via-olm.json"},{"id":"console-runs-on-control-plane","text":"The web console runs as pods on control plane nodes in the `openshift-console` project, managed by the `console-operator` pod","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-runs-on-control-plane.json"},{"id":"console-spec-route-deprecated-use-ingress","text":"The Console operator `spec.route` field is deprecated; `spec.ingress` is the modern alternative for custom console URLs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-spec-route-deprecated-use-ingress.json"},{"id":"console-two-perspectives","text":"The web console has two main perspectives: Administrator and Developer, each tailored to different user roles","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-two-perspectives.json"},{"id":"console-url-from-status-not-configurable","text":"The console URL is found in `status.consoleURL` and is derived from the console route — it is not user-configurable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-url-from-status-not-configurable.json"},{"id":"console-url-retrieve-command","text":"The web console URL can be retrieved with `oc whoami --show-console`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/console-url-retrieve-command.json"},{"id":"consoleclidownload-cluster-scoped","text":"ConsoleCLIDownload is a cluster-scoped resource (no namespace) used to register CLI tool download links in the web console","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleclidownload-cluster-scoped.json"},{"id":"consoleclidownload-links-require-https","text":"ConsoleCLIDownload link `href` values must use HTTPS (absolute secure URLs)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleclidownload-links-require-https.json"},{"id":"consoleclidownload-required-fields","text":"ConsoleCLIDownload requires three spec fields: `description`, `displayName`, and `links`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleclidownload-required-fields.json"},{"id":"consoleexternalloglink-namespace-filter-js-regex","text":"ConsoleExternalLogLink `namespaceFilter` uses JavaScript RegExp syntax (not Go or POSIX regex)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleexternalloglink-namespace-filter-js-regex.json"},{"id":"consoleexternalloglink-pod-logs-tab","text":"ConsoleExternalLogLink links appear on the Logs tab of the pod details page in the web console","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleexternalloglink-pod-logs-tab.json"},{"id":"consoleexternalloglink-template-variables","text":"ConsoleExternalLogLink hrefTemplate supports variables: `${resourceName}`, `${resourceUID}`, `${containerName}`, `${resourceNamespace}`, `${resourceNamespaceUID}`, and `${podLabels}` (JSON-encoded)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleexternalloglink-template-variables.json"},{"id":"consolelink-applicationmenu-section-required","text":"When ConsoleLink location is `ApplicationMenu`, the `applicationMenu.section` field is required to determine the menu grouping","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolelink-applicationmenu-section-required.json"},{"id":"consolelink-cluster-scoped","text":"ConsoleLink is a cluster-scoped resource, even when targeting specific namespace dashboards","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolelink-cluster-scoped.json"},{"id":"consolelink-four-locations","text":"ConsoleLink supports four valid location values: `ApplicationMenu`, `HelpMenu`, `UserMenu`, `NamespaceDashboard`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolelink-four-locations.json"},{"id":"consolelink-namespacedashboard-default-all","text":"When ConsoleLink location is `NamespaceDashboard` and no `namespaceDashboard` filter is specified, the link appears in all namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolelink-namespacedashboard-default-all.json"},{"id":"consolelink-scopes-cluster-namespace-appmenu","text":"ConsoleLink can add links at three scopes: cluster-level, namespace-level, or application menu","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolelink-scopes-cluster-namespace-appmenu.json"},{"id":"consolenotification-cluster-scoped","text":"ConsoleNotification is a cluster-scoped custom resource (no namespace required) in the `console.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolenotification-cluster-scoped.json"},{"id":"consolenotification-compat-level-2","text":"ConsoleNotification has Compatibility Level 2: stable within a major release for at least 9 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolenotification-compat-level-2.json"},{"id":"consolenotification-link-href-https","text":"ConsoleNotification link `href` must be an absolute secure URL (HTTPS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolenotification-link-href-https.json"},{"id":"consolenotification-location-values","text":"ConsoleNotification valid location values are exactly three: `BannerTop`, `BannerBottom`, `BannerTopBottom`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolenotification-location-values.json"},{"id":"consolenotification-text-only-required-field","text":"The only required field in the ConsoleNotification spec is `text`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolenotification-text-only-required-field.json"},{"id":"consoleplugin-backend-must-use-https","text":"ConsolePlugin backend services must use HTTPS with service serving certificates.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-backend-must-use-https.json"},{"id":"consoleplugin-compat-level-1","text":"ConsolePlugin has Compatibility Level 1: stable for at least 12 months or 3 minor releases within a major release.","truth_value":"IN","justification_count":0,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-compat-level-1.json"},{"id":"consoleplugin-cr-api-group","text":"The `ConsolePlugin` custom resource uses API group `console.openshift.io/v1` to register dynamic plugins with the web console","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-cr-api-group.json"},{"id":"consoleplugin-displayname-required-1-128-chars","text":"ConsolePlugin `displayName` is required and must be 1-128 characters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-displayname-required-1-128-chars.json"},{"id":"consoleplugin-dynamic-plugins-ga","text":"ConsolePlugin is the primary mechanism for extending the web console with dynamic plugins, introduced in OCP 4.10+ and GA in 4.12+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-dynamic-plugins-ga.json"},{"id":"consoleplugin-extends-console-dynamically","text":"ConsolePlugin dynamically loads code from an in-cluster service to extend the OpenShift web console","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-extends-console-dynamically.json"},{"id":"consoleplugin-i18n-loadtype-values","text":"ConsolePlugin localization `loadType` values are `Preload`, `Lazy`, or empty string (defaults to `Lazy`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-i18n-loadtype-values.json"},{"id":"consoleplugin-only-service-backend-type","text":"ConsolePlugin only supports `Service` as a backend type.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-only-service-backend-type.json"},{"id":"consoleplugin-primary-web-console-extension","text":"The ConsolePlugin resource is the primary mechanism for extending the OpenShift web console with dynamic plugins (OCP 4.12+)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-primary-web-console-extension.json"},{"id":"consoleplugin-proxy-url-pattern","text":"ConsolePlugin proxy URL pattern is `/api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleplugin-proxy-url-pattern.json"},{"id":"consolequickstart-access-review-hides","text":"ConsoleQuickStart quick starts are hidden (not just disabled) when `accessReviewResources` checks fail.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolequickstart-access-review-hides.json"},{"id":"consolequickstart-cluster-scoped","text":"ConsoleQuickStart is a cluster-scoped resource in the `console.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolequickstart-cluster-scoped.json"},{"id":"consolequickstart-compat-level-2","text":"ConsoleQuickStart has Compatibility Level 2: stable for 9 months or 3 minor releases within a major release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolequickstart-compat-level-2.json"},{"id":"consolequickstart-required-spec-fields","text":"ConsoleQuickStart required spec fields are `description`, `displayName`, `durationMinutes`, `introduction`, and `tasks`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolequickstart-required-spec-fields.json"},{"id":"consolesample-compat-level-1","text":"ConsoleSample has Compatibility Level 1: stable for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolesample-compat-level-1.json"},{"id":"consolesample-default-port-8080","text":"ConsoleSample default HTTP service port is 8080 unless overridden via `targetPort`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolesample-default-port-8080.json"},{"id":"consolesample-git-public-repos-only","text":"ConsoleSample Git imports are limited to public repositories on GitHub, GitLab, and Bitbucket only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolesample-git-public-repos-only.json"},{"id":"consolesample-required-spec-fields","text":"ConsoleSample required spec fields are `abstract`, `description`, `source`, and `title`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolesample-required-spec-fields.json"},{"id":"consolesample-two-source-types","text":"ConsoleSample supports two source types: `GitImport` (from a Git repo) and `ContainerImport` (from a container image).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consolesample-two-source-types.json"},{"id":"consoleyamlsample-cluster-scoped","text":"ConsoleYAMLSample is a cluster-scoped resource in the `console.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleyamlsample-cluster-scoped.json"},{"id":"consoleyamlsample-required-spec-fields","text":"ConsoleYAMLSample required spec fields are `description`, `targetResource`, `title`, and `yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleyamlsample-required-spec-fields.json"},{"id":"consoleyamlsample-snippet-boolean","text":"ConsoleYAMLSample `snippet` boolean field distinguishes between complete resource definitions (false) and insertable fragments (true) in the web console editor.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/consoleyamlsample-snippet-boolean.json"},{"id":"container-image-version-must-match-ocp","text":"Container image versions must match the OCP version — newer container images are not backward compatible with earlier OCP versions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-image-version-must-match-ocp.json"},{"id":"container-logging-stdout","text":"All container logging in OpenShift should go to stdout for collection by the centralized logging system","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-logging-stdout.json"},{"id":"container-runtime-required-on-nodes","text":"A container runtime must be installed on each node for pods to run.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-runtime-required-on-nodes.json"},{"id":"container-runtime-search-registries-pod-specs-only","text":"`containerRuntimeSearchRegistries` works only with Podman and CRI-O, and only in pod specs (not builds or image streams)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-runtime-search-registries-pod-specs-only.json"},{"id":"container-security-operator-namespace","text":"The Container Security Operator is installed in the `openshift-operators` namespace by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-security-operator-namespace.json"},{"id":"container-security-operator-queries-registry","text":"The Container Security Operator does not scan images itself — it queries the source container registry (which must run Clair scanning) for vulnerability information.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/container-security-operator-queries-registry.json"},{"id":"containerruntimeconfig-api-group","text":"ContainerRuntimeConfig belongs to API group machineconfiguration.openshift.io/v1 and is a cluster-scoped resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-api-group.json"},{"id":"containerruntimeconfig-configures-crio","text":"ContainerRuntimeConfig is the declarative, supported approach to customize CRI-O settings on cluster nodes without writing raw MachineConfig resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-configures-crio.json"},{"id":"containerruntimeconfig-default-overlaysize-10gb","text":"ContainerRuntimeConfig default overlaySize (max container image size) is 10GB.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-default-overlaysize-10gb.json"},{"id":"containerruntimeconfig-for-crio","text":"ContainerRuntimeConfig is the dedicated CR for managing CRI-O container runtime settings (e.g., pids_limit, log_size_max), separate from MachineConfig.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-for-crio.json"},{"id":"containerruntimeconfig-loglevel-values","text":"ContainerRuntimeConfig valid logLevel values are: fatal, panic, error, warn, info, debug.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-loglevel-values.json"},{"id":"containerruntimeconfig-logsizemax-min-8192","text":"ContainerRuntimeConfig logSizeMax must be >= 8192 if set to a positive value (to match conmon's read buffer); negative values mean no limit.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-logsizemax-min-8192.json"},{"id":"containerruntimeconfig-nil-selector-selects-no-pools","text":"A nil machineConfigPoolSelector in ContainerRuntimeConfig selects no pools — you must explicitly label-match to apply the config.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-nil-selector-selects-no-pools.json"},{"id":"containerruntimeconfig-pidslimit","text":"ContainerRuntimeConfig pidsLimit parameter controls per-container process limits for workload isolation and security.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/containerruntimeconfig-pidslimit.json"},{"id":"control-plane-machine-delete-requires-cpms","text":"Control plane machines must not be deleted unless the cluster uses a control plane machine set (CPMS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/control-plane-machine-delete-requires-cpms.json"},{"id":"control-plane-not-managed-by-compute-machinesets","text":"Control plane machines cannot be managed by compute machine sets; they require control plane machine sets instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/control-plane-not-managed-by-compute-machinesets.json"},{"id":"control-plane-not-scaled-via-machinesets","text":"Control plane machines are not scaled via MachineSets; they are managed by the ControlPlaneMachineSet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/control-plane-not-scaled-via-machinesets.json"},{"id":"control-plane-static-pod-operators","text":"KubeAPIServer, KubeControllerManager, and KubeScheduler operators all use the same revision-based static pod deployment model on control plane nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/control-plane-static-pod-operators.json"},{"id":"control-plane-vs-worker-nodes","text":"Control plane nodes run the API server, etcd, and controllers; worker nodes run application workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/control-plane-vs-worker-nodes.json"},{"id":"controllerconfig-additional-trust-bundle","text":"The `additionalTrustBundle` field in ControllerConfig propagates custom CA certificates to all node trust stores (e.g., for proxied environments or private registries).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerconfig-additional-trust-bundle.json"},{"id":"controllerconfig-api-group","text":"The ControllerConfig resource belongs to the `machineconfiguration.openshift.io/v1` API group and is cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerconfig-api-group.json"},{"id":"controllerconfig-base-os-container-image-replaces-osimageurl","text":"The `baseOSContainerImage` field is the required new-format OS update image in ControllerConfig; `osImageURL` is deprecated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerconfig-base-os-container-image-replaces-osimageurl.json"},{"id":"controllerconfig-deprecated-fields","text":"ControllerConfig deprecated fields: `etcdDiscoveryDomain` (use `Infra.Status.EtcdDiscoveryDomain`), `platform` (use `Infra.Status.PlatformStatus.Type`), `osImageURL` (use `baseOSContainerImage`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerconfig-deprecated-fields.json"},{"id":"controllerconfig-required-spec-fields","text":"ControllerConfig required spec fields are: `baseOSContainerImage`, `cloudProviderConfig`, `clusterDNSIP`, `images`, `ipFamilies`, `kubeAPIServerServingCAData`, `releaseImage`, `rootCAData`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerconfig-required-spec-fields.json"},{"id":"controllerrevision-apps-v1-namespaced","text":"ControllerRevision is in the `apps/v1` API group and is a namespaced resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerrevision-apps-v1-namespaced.json"},{"id":"controllerrevision-data-immutable-after-creation","text":"ControllerRevision's `data` field is immutable after creation; the API server rejects mutation attempts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerrevision-data-immutable-after-creation.json"},{"id":"controllerrevision-immutable-after-creation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerrevision-immutable-after-creation.json"},{"id":"controllerrevision-revision-required-field","text":"The `revision` field (integer) is the only required field on a ControllerRevision.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerrevision-revision-required-field.json"},{"id":"controllerrevision-used-by-daemonset-statefulset","text":"ControllerRevisions are used by DaemonSet and StatefulSet controllers for update/rollback; Deployments use ReplicaSets for revision tracking instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/controllerrevision-used-by-daemonset-statefulset.json"},{"id":"coo-has-custom-crds","text":"The Cluster Observability Operator introduces its own custom resources (CRDs) and API surface for managing observability configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-has-custom-crds.json"},{"id":"coo-independent-versioning","text":"The Cluster Observability Operator has its own independent versioning separate from the OpenShift platform version.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-independent-versioning.json"},{"id":"coo-installed-via-olm","text":"The Cluster Observability Operator is installed via OLM (Operator Lifecycle Manager) through OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-installed-via-olm.json"},{"id":"coo-manages-observability","text":"The Cluster Observability Operator (COO) is the central operator for configuring and managing observability features on OCP 4.20+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-manages-observability.json"},{"id":"coo-provides-ui-plugins","text":"The Cluster Observability Operator provides UI plugins that extend the OpenShift web console with observability dashboards and views.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-provides-ui-plugins.json"},{"id":"coo-separate-from-cmo","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-separate-from-cmo.json"},{"id":"coo-separate-operator-from-monitoring-stack","text":"The Cluster Observability Operator (COO) is a separate operator that must be explicitly installed; it is not part of the default OpenShift monitoring stack.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-separate-operator-from-monitoring-stack.json"},{"id":"coo-separately-installed-operator","text":"The Cluster Observability Operator (COO) is a separately installable operator, not part of the default OpenShift cluster monitoring stack.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-separately-installed-operator.json"},{"id":"coo-supports-ui-plugins","text":"The Cluster Observability Operator supports UI plugins that extend the OpenShift web console with observability views and dashboards.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/coo-supports-ui-plugins.json"},{"id":"core-v1-resources-no-group-prefix","text":"Core v1 resources (Pod, Service, ConfigMap, Secret, Namespace, Node, PV, PVC) have no API group prefix.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/core-v1-resources-no-group-prefix.json"},{"id":"cors-apiserver-config-resource","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cors-apiserver-config-resource.json"},{"id":"cors-applies-api-and-oauth","text":"The `additionalCORSAllowedOrigins` setting applies to both the API server and the OAuth server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cors-applies-api-and-oauth.json"},{"id":"cors-default-only-web-console","text":"By default, only the OpenShift web console hostname is allowed to make cross-origin JavaScript requests to the API server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cors-default-only-web-console.json"},{"id":"cpms-active-cannot-be-made-inactive","text":"Once a ControlPlaneMachineSet state is set to Active, it cannot be made Inactive — the resource must be deleted instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-active-cannot-be-made-inactive.json"},{"id":"cpms-api-version-v1","text":"The ControlPlaneMachineSet API is `machine.openshift.io/v1`, while the Machines it manages are `machine.openshift.io/v1beta1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-api-version-v1.json"},{"id":"cpms-failure-domain-platforms","text":"ControlPlaneMachineSet failure domains are supported on AWS, Azure, GCP, OpenStack, vSphere, and Nutanix.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-failure-domain-platforms.json"},{"id":"cpms-lifecycle-hooks","text":"ControlPlaneMachineSet lifecycle hooks: `preDrain` blocks draining and all subsequent events; `preTerminate` blocks termination only (actioned after drain completes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-lifecycle-hooks.json"},{"id":"cpms-replicas-immutable-3-or-5","text":"ControlPlaneMachineSet replicas field is immutable after cluster installation and only supports values of 3 or 5.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-replicas-immutable-3-or-5.json"},{"id":"cpms-selector-immutable","text":"The ControlPlaneMachineSet selector is immutable after creation and must match template labels.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-selector-immutable.json"},{"id":"cpms-strategy-types","text":"ControlPlaneMachineSet supports two update strategy types: `RollingUpdate` (default) and `OnDelete`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpms-strategy-types.json"},{"id":"cpu-limits-throttle-memory-limits-oom","text":"CPU limits are enforced via throttling (pods are NOT terminated for exceeding CPU); memory limits are enforced via kernel OOM kill.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpu-limits-throttle-memory-limits-oom.json"},{"id":"cpu-manager-default-policy-none","text":"CPU Manager default policy is `none`, which uses shared CFS quota scheduling.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpu-manager-default-policy-none.json"},{"id":"cpu-manager-static-requires-guaranteed-integer","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpu-manager-static-requires-guaranteed-integer.json"},{"id":"cpu-partitioning-install-time-only","text":"Workload partitioning (cpuPartitioningMode: AllNodes) can only be enabled at OpenShift install time and cannot be enabled later.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cpu-partitioning-install-time-only.json"},{"id":"crd-additional-printer-columns-requires-name-type-jsonpath","text":"CRD `additionalPrinterColumns` requires `name`, `type`, and `jsonPath` fields to customize `kubectl get` table output.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-additional-printer-columns-requires-name-type-jsonpath.json"},{"id":"crd-conversion-strategies-none-or-webhook","text":"CRD conversion strategies are `None` (only changes apiVersion) or `Webhook` (calls external webhook); webhook requires `preserveUnknownFields: false`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-conversion-strategies-none-or-webhook.json"},{"id":"crd-exactly-one-storage-version","text":"Exactly one CRD version must have `storage: true`; this is the version used when persisting to etcd.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-exactly-one-storage-version.json"},{"id":"crd-max-8-selectable-fields","text":"CRDs allow a maximum of 8 selectable fields per version, which must be string, boolean, or integer types.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-max-8-selectable-fields.json"},{"id":"crd-name-format-plural-dot-group","text":"CRD name must follow the format `<plural>.<group>` (e.g., `crontabs.stable.example.com`); this is enforced.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-name-format-plural-dot-group.json"},{"id":"crd-scope-cluster-or-namespaced","text":"CRD scope can only be `Cluster` or `Namespaced`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-scope-cluster-or-namespaced.json"},{"id":"crd-status-subresource-separates-spec-status","text":"The CRD status subresource ensures PUT/POST/PATCH to the main resource ignores `.status` changes, and PUT to `/status` ignores everything except `.status`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crd-status-subresource-separates-spec-status.json"},{"id":"credentials-mode-required-with-scps","text":"When AWS account has SCPs (Service Control Policies) enabled, credentialsMode must be explicitly set to Mint, Passthrough, or Manual in install-config.yaml.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/credentials-mode-required-with-scps.json"},{"id":"credentialsrequest-openshift-cloud-credentials","text":"CredentialsRequest (`cloudcredential.openshift.io/v1`) is an OpenShift-specific CRD for managing cloud provider credentials, connected to the Cloud Credential Operator (CCO)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/credentialsrequest-openshift-cloud-credentials.json"},{"id":"cri-o-only-container-engine","text":"CRI-O is the only container engine in OpenShift clusters (not Docker); it can use `runC` or `crun` as the container runtime.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cri-o-only-container-engine.json"},{"id":"cri-o-runs-on-every-ocp-node","text":"CRI-O is the container engine running on every worker and control plane node in OpenShift Container Platform clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cri-o-runs-on-every-ocp-node.json"},{"id":"crio-container-runtime-on-ocp","text":"CRI-O (not Docker) is the container runtime engine on all OpenShift Container Platform cluster nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crio-container-runtime-on-ocp.json"},{"id":"crio-supports-multiple-runtimes","text":"CRI-O supports multiple OCI runtimes including runc (default) and kata, allowing per-workload runtime selection.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/crio-supports-multiple-runtimes.json"},{"id":"cronjob-backoff-limit-default-6","text":"Job `backoffLimit` defaults to 6 retries before marking a Job as failed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-backoff-limit-default-6.json"},{"id":"cronjob-batch-v1-api-group","text":"CronJob is `batch/v1` (fully GA since Kubernetes 1.21 / OCP 4.8+), not `batch/v1beta1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-batch-v1-api-group.json"},{"id":"cronjob-concurrency-policy-default-allow","text":"CronJob `concurrencyPolicy` defaults to `Allow`; other values are `Forbid` (skip if previous running) and `Replace` (cancel running and start new)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-concurrency-policy-default-allow.json"},{"id":"cronjob-concurrency-policy-values","text":"CronJob concurrencyPolicy accepts three values: Allow (default), Forbid, or Replace.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-concurrency-policy-values.json"},{"id":"cronjob-history-defaults-3-success-1-failed","text":"CronJob history limits default to 3 successful jobs (successfulJobsHistoryLimit) and 1 failed job (failedJobsHistoryLimit).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-history-defaults-3-success-1-failed.json"},{"id":"cronjob-history-limits-defaults","text":"CronJob `failedJobsHistoryLimit` defaults to 1; `successfulJobsHistoryLimit` defaults to 3","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-history-limits-defaults.json"},{"id":"cronjob-suspend-does-not-stop-running-jobs","text":"Setting `suspend: true` on a CronJob prevents new Jobs from being created but does NOT stop already-running Jobs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-suspend-does-not-stop-running-jobs.json"},{"id":"cronjob-timezone-iana","text":"CronJob `timeZone` field uses IANA tz database names; if the timezone becomes invalid, the controller stops creating Jobs and emits an `UnknownTimeZone` event","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-timezone-iana.json"},{"id":"cronjob-ttl-zero-immediate-deletion","text":"`ttlSecondsAfterFinished: 0` means the Job is eligible for deletion immediately after finishing","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjob-ttl-zero-immediate-deletion.json"},{"id":"cronjobs-must-be-idempotent","text":"CronJobs may fail to create a job or create duplicates, so jobs must be idempotent.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cronjobs-must-be-idempotent.json"},{"id":"cross-project-image-pull-role","text":"Cross-project image access is granted by binding `system:image-puller` role to `system:serviceaccount:<project>:<sa>` in the target namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cross-project-image-pull-role.json"},{"id":"csi-communication-unix-domain-sockets","text":"CSI controller containers and driver containers communicate via UNIX Domain Sockets — no CSI traffic leaves the pod.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-communication-unix-domain-sockets.json"},{"id":"csi-controller-five-containers","text":"The external CSI controller is a Deployment with 5 containers: snapshotter, resizer, attacher, provisioner, and the CSI driver itself.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-controller-five-containers.json"},{"id":"csi-controllers-run-on-infra-nodes","text":"CSI controller pods should run on infrastructure nodes to protect storage credentials.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-controllers-run-on-infra-nodes.json"},{"id":"csi-ephemeral-no-label-defaults-privileged","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-ephemeral-no-label-defaults-privileged.json"},{"id":"csi-inline-ephemeral-supported-drivers","text":"CSI inline ephemeral volumes are supported only by Shared Resource, Azure File, and Secrets Store CSI drivers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-inline-ephemeral-supported-drivers.json"},{"id":"csi-migration-versions","text":"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+).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-migration-versions.json"},{"id":"csi-standard-api-replaces-in-tree-plugins","text":"CSI (Container Storage Interface) is the standard vendor-agnostic API for storage in OCP, replacing in-tree volume plugins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-standard-api-replaces-in-tree-plugins.json"},{"id":"csi-storage-capacity-is-namespaced","text":"CSIStorageCapacity is a namespaced resource in the `storage.k8s.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-storage-capacity-is-namespaced.json"},{"id":"csi-storage-capacity-nodetopology-immutable","text":"The `nodeTopology` field on CSIStorageCapacity is immutable; if unset, storage is inaccessible; if empty, storage is accessible from all nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-storage-capacity-nodetopology-immutable.json"},{"id":"csi-storage-capacity-storageclassname-required-immutable","text":"The `storageClassName` field on CSIStorageCapacity is required and immutable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csi-storage-capacity-storageclassname-required-immutable.json"},{"id":"csidriver-attach-required-immutable","text":"The `attachRequired` and `volumeLifecycleModes` fields on CSIDriver are immutable after creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csidriver-attach-required-immutable.json"},{"id":"csidriver-cluster-scoped-resource","text":"The CSIDriver resource (`storage.k8s.io/v1`) is a cluster-scoped (non-namespaced) Kubernetes object.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csidriver-cluster-scoped-resource.json"},{"id":"csidriver-default-fsgrouppolicy","text":"The default `fsGroupPolicy` for CSIDriver is `ReadWriteOnceWithFSType` — fsGroup is only applied when fstype is defined and access mode is ReadWriteOnce.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csidriver-default-fsgrouppolicy.json"},{"id":"csidriver-volume-lifecycle-modes","text":"CSIDriver supports two volume lifecycle modes: Persistent (default, standard PV/PVC) and Ephemeral (inline volumes tied to pod lifecycle).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csidriver-volume-lifecycle-modes.json"},{"id":"csinode-allocatable-count-max-volumes","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csinode-allocatable-count-max-volumes.json"},{"id":"csinode-auto-created-by-kubelet","text":"CSINode objects are automatically created by the kubelet via the node-driver-registrar sidecar — CSI drivers do not create them directly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csinode-auto-created-by-kubelet.json"},{"id":"csinode-name-matches-node-name","text":"CSINode name must match the Kubernetes node name, and the CSINode has an OwnerReference to the corresponding Node object.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csinode-name-matches-node-name.json"},{"id":"csinode-nodeid-maps-to-storage-system","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csinode-nodeid-maps-to-storage-system.json"},{"id":"csisnapshotcontroller-manages-csi-volume-snapshots","text":"The CSISnapshotController operator manages CSI volume snapshot functionality and works with VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csisnapshotcontroller-manages-csi-volume-snapshots.json"},{"id":"csisnapshotcontroller-singleton-named-cluster","text":"The CSISnapshotController operator resource canonical instance is named `cluster` in the `operator.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csisnapshotcontroller-singleton-named-cluster.json"},{"id":"csr-three-signer-names","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csr-three-signer-names.json"},{"id":"csv-api-group-v1alpha1","text":"The ClusterServiceVersion (CSV) resource belongs to the `operators.coreos.com/v1alpha1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-api-group-v1alpha1.json"},{"id":"csv-install-strategy-deployment","text":"The CSV install strategy type is typically `\"deployment\"`, with the install spec containing deployments, permissions, and clusterPermissions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-install-strategy-deployment.json"},{"id":"csv-installmodes-four-types","text":"CSV `installModes` supports four types: OwnNamespace, SingleNamespace, MultiNamespace, and AllNamespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-installmodes-four-types.json"},{"id":"csv-rbac-permissions-location","text":"RBAC rules are embedded in the CSV under `spec.install.spec.permissions` (namespace-scoped) and `spec.install.spec.clusterPermissions` (cluster-scoped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-rbac-permissions-location.json"},{"id":"csv-related-images-must-use-digest","text":"The `relatedImages` field in a CSV must use digest (SHA) references, not tags — important for disconnected/air-gapped environments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-related-images-must-use-digest.json"},{"id":"csv-replaces-skips-upgrade-graph","text":"The CSV `replaces` field names the CSV version being replaced (establishing upgrade path), while `skips` allows skipping intermediate versions in the upgrade graph.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-replaces-skips-upgrade-graph.json"},{"id":"csv-required-spec-fields-displayname-install","text":"The required spec fields for a ClusterServiceVersion are `displayName` and `install`; the install block requires a `strategy` field.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-required-spec-fields-displayname-install.json"},{"id":"csv-status-allnamespaces-copied","text":"For AllNamespaces install mode, the CSV status shows `Succeeded` in `openshift-operators` and `Copied` in other namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-status-allnamespaces-copied.json"},{"id":"csv-succeeded-means-installed","text":"A ClusterServiceVersion (CSV) in `Succeeded` phase means the Operator is installed and running","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/csv-succeeded-means-installed.json"},{"id":"custom-mcps-inherit-worker","text":"Custom MCPs inherit from the worker pool; non-inheriting custom pools are unsupported by the MCO.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/custom-mcps-inherit-worker.json"},{"id":"custom-metrics-autoscaler-built-on-keda","text":"The Custom Metrics Autoscaler Operator is built on KEDA (Kubernetes-based Event Driven Autoscaler) and extends the HPA — it does not replace HPA","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/custom-metrics-autoscaler-built-on-keda.json"},{"id":"custom-metrics-autoscaler-separate-install","text":"The Custom Metrics Autoscaler Operator is an optional, separately installed Operator with its own version lifecycle distinct from core OpenShift","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/custom-metrics-autoscaler-separate-install.json"},{"id":"custom-project-request-template-configurable","text":"Cluster admins can configure a custom project request template to control default resources (quotas, limit ranges, network policies) provisioned with every new project","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/custom-project-request-template-configurable.json"},{"id":"cvo-applies-manifests-in-runlevels","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cvo-applies-manifests-in-runlevels.json"},{"id":"cvo-bootstraps-etcd-operator","text":"The Cluster Version Operator (CVO) comes online during bootstrap and installs the etcd Operator and other cluster components","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cvo-bootstraps-etcd-operator.json"},{"id":"cvo-manages-cluster-operators-olm-manages-addons","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/cvo-manages-cluster-operators-olm-manages-addons.json"},{"id":"daemonset-apps-v1-api-group","text":"DaemonSets belong to the `apps/v1` API group (not the deprecated `extensions` group)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-apps-v1-api-group.json"},{"id":"daemonset-default-update-strategy-rollingupdate","text":"DaemonSet default update strategy is `RollingUpdate` (not `OnDelete`); `maxSurge` defaults to 0, `maxUnavailable` defaults to 1, and they cannot both be 0","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-default-update-strategy-rollingupdate.json"},{"id":"daemonset-pods-never-evicted-by-default","text":"DaemonSet pods get default tolerations for unreachable and not-ready with no tolerationSeconds, meaning they are never evicted.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-pods-never-evicted-by-default.json"},{"id":"daemonset-requires-disable-default-node-selector","text":"DaemonSets require disabling the default project node selector (openshift.io/node-selector: \"\") on the namespace, or pods will be incorrectly scheduled with frequent recreates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-requires-disable-default-node-selector.json"},{"id":"daemonset-restart-policy-always-only","text":"The only allowed `restartPolicy` for DaemonSet pod templates is `\"Always\"`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-restart-policy-always-only.json"},{"id":"daemonset-revision-history-limit-default-10","text":"DaemonSet `revisionHistoryLimit` defaults to 10","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-revision-history-limit-default-10.json"},{"id":"daemonset-runs-one-pod-per-node","text":"A DaemonSet ensures a Pod runs on every (or selected) node(s) in the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-runs-one-pod-per-node.json"},{"id":"daemonset-update-does-not-affect-existing-pods","text":"Updating a DaemonSet pod template does not affect existing pod replicas — old pods must be deleted manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonset-update-does-not-affect-existing-pods.json"},{"id":"daemonsets-pod-on-every-node","text":"DaemonSets ensure a pod runs on every node (or a subset via node labels); used for DNS, monitoring, and similar infrastructure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonsets-pod-on-every-node.json"},{"id":"daemonsets-run-pod-on-every-node","text":"DaemonSets ensure a copy of a Pod runs on all (or selected) nodes, commonly used for node-level agents like logging, monitoring, and networking.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/daemonsets-run-pod-on-every-node.json"},{"id":"dashboard-five-cards","text":"The cluster dashboard has five cards: Details, Cluster Inventory, Status, Cluster Utilization, and Activity","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dashboard-five-cards.json"},{"id":"dashboard-home-overview-path","text":"The OCP cluster dashboard is accessed at Home → Overview in the web console","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dashboard-home-overview-path.json"},{"id":"dashboard-utilization-five-metrics","text":"Cluster Utilization card tracks five metrics: CPU time, memory, storage, network, and pod count","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dashboard-utilization-five-metrics.json"},{"id":"dataimage-bare-metal-only","text":"DataImage is specific to bare-metal provisioning and does not apply to cloud-based or virtualized deployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dataimage-bare-metal-only.json"},{"id":"dataimage-only-required-field-url","text":"The DataImage resource (`metal3.io/v1alpha1`) has only one required spec field: `url`, specifying the data image to attach to a BareMetalHost.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dataimage-only-required-field-url.json"},{"id":"dc-no-triggers-adds-configchange","text":"If no triggers are defined on a DeploymentConfig, a ConfigChange trigger is added by default; an empty triggers field (`triggers: []`) means manual-only deployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dc-no-triggers-adds-configchange.json"},{"id":"default-catalog-namespace-openshift-marketplace","text":"The default catalog source namespace for OperatorHub catalogs is `openshift-marketplace`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-catalog-namespace-openshift-marketplace.json"},{"id":"default-catalog-sources-four-shipped","text":"OpenShift ships with four default catalog sources: `redhat-operators`, `certified-operators`, `community-operators`, `redhat-marketplace`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-catalog-sources-four-shipped.json"},{"id":"default-cluster-network-cidr","text":"The default cluster network is `10.128.0.0/14` with a `/23` host prefix, providing 510 pod IPs per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-cluster-network-cidr.json"},{"id":"default-clusterroles-list","text":"OpenShift ships with default ClusterRoles: `admin`, `edit`, `view`, `cluster-admin`, and `self-provisioner`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-clusterroles-list.json"},{"id":"default-imagepullpolicy-by-tag","text":"Default imagePullPolicy: `:latest` tag → `Always`; any other tag → `IfNotPresent`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-imagepullpolicy-by-tag.json"},{"id":"default-max-pods-per-node-250","text":"The default maximum number of pods per node in OpenShift is 250.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-max-pods-per-node-250.json"},{"id":"default-mcps-master-worker","text":"The two default Machine Config Pools are `master` and `worker`; custom MCPs for control plane are not supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-mcps-master-worker.json"},{"id":"default-pod-eviction-timeout-5-minutes","text":"When a node becomes unreachable, pods are scheduled for eviction after 5 minutes by default (tolerationSeconds=300 added automatically).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-pod-eviction-timeout-5-minutes.json"},{"id":"default-replicas-3-control-3-compute","text":"Default control plane replicas are 3 (or 1 for single-node OpenShift); default compute replicas are 3 with a minimum of 2.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-replicas-3-control-3-compute.json"},{"id":"default-route-uses-reencrypt","text":"Enabling `defaultRoute` on the Image Registry Operator creates an external route with re-encrypt TLS termination.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-route-uses-reencrypt.json"},{"id":"default-service-network-cidr","text":"The default service network is `172.30.0.0/16`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-service-network-cidr.json"},{"id":"default-storageclass-annotation","text":"The annotation to mark a StorageClass as default is `storageclass.kubernetes.io/is-default-class: \"true\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/default-storageclass-annotation.json"},{"id":"degraded-does-not-cause-workload-failure","text":"ClusterOperator condition `Degraded` does not cause workload failure as long as `Available` is `True`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/degraded-does-not-cause-workload-failure.json"},{"id":"delete-istag-two-methods","text":"Image stream tags can be deleted with either `oc delete istag/<name>:<tag>` or `oc tag -d <name>:<tag>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/delete-istag-two-methods.json"},{"id":"delete-machine-annotation","text":"The annotation `machine.openshift.io/delete-machine=true` marks a specific machine for priority deletion, overriding the MachineSet deletion policy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/delete-machine-annotation.json"},{"id":"delete-oauthaccesstoken-revokes-session","text":"Deleting an OAuthAccessToken (`oc delete oauthaccesstoken <name>`) effectively revokes a user's session.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/delete-oauthaccesstoken-revokes-session.json"},{"id":"delete-operator-order-subscription-then-csv","text":"To fully delete an Operator: delete the Subscription first, then delete the CSV; may also need to clean up CRDs and operand resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/delete-operator-order-subscription-then-csv.json"},{"id":"delete-user-also-delete-identities","text":"When deleting a user, associated Identity objects may also need to be deleted to fully clean up authentication state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/delete-user-also-delete-identities.json"},{"id":"deleting-imagestreamtag-removes-spec-and-status","text":"Deleting an ImageStreamTag resource removes both the spec and status entries for that tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deleting-imagestreamtag-removes-spec-and-status.json"},{"id":"deployment-favors-availability-dc-favors-consistency","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deployment-favors-availability-dc-favors-consistency.json"},{"id":"deployment-uses-replicasets-dc-uses-rc","text":"Deployment objects use ReplicaSets as building blocks; DeploymentConfig objects use ReplicationControllers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deployment-uses-replicasets-dc-uses-rc.json"},{"id":"deploymentconfig-deprecated-ocp-414","text":"DeploymentConfig is an OpenShift-specific workload resource deprecated in favor of Kubernetes Deployments starting in OCP 4.14.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-deprecated-ocp-414.json"},{"id":"deploymentconfig-deprecated-ocp414","text":"DeploymentConfig is deprecated as of OpenShift Container Platform 4.14; Deployment objects should be used for new installations.","truth_value":"IN","justification_count":0,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-deprecated-ocp414.json"},{"id":"deploymentconfig-deprecated-use-deployment","text":"DeploymentConfig (`apps.openshift.io/v1`) is deprecated in favor of Kubernetes Deployments (`apps/v1`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-deprecated-use-deployment.json"},{"id":"deploymentconfig-legacy-apps-openshift","text":"DeploymentConfig (`apps.openshift.io/v1`) is OpenShift-specific and legacy; Deployment (`apps/v1`) is the standard Kubernetes resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-legacy-apps-openshift.json"},{"id":"deploymentconfig-native-image-triggers","text":"DeploymentConfigs and BuildConfigs have image change trigger fields built into their API spec, unlike standard Kubernetes resources which require annotations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-native-image-triggers.json"},{"id":"deploymentconfig-openshift-specific","text":"DeploymentConfig is an OpenShift-specific resource distinct from Kubernetes Deployment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-openshift-specific.json"},{"id":"deploymentconfig-used-replicationcontrollers","text":"OpenShift DeploymentConfig (now deprecated) used ReplicationControllers internally, while Deployments use ReplicaSets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-used-replicationcontrollers.json"},{"id":"deploymentconfig-uses-replicationcontrollers","text":"DeploymentConfig creates ReplicationControllers for each deployment, whereas Deployment uses ReplicaSets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentconfig-uses-replicationcontrollers.json"},{"id":"deploymentrequest-exclude-triggers","text":"DeploymentRequest `excludeTriggers` field provides fine-grained control over which triggers fire during instantiation, overriding the triggers that `latest` would otherwise process","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentrequest-exclude-triggers.json"},{"id":"deploymentrequest-force-paused-invalid-error","text":"You cannot force a deployment on a paused DeploymentConfig — DeploymentRequest returns an Invalid error","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentrequest-force-paused-invalid-error.json"},{"id":"deploymentrequest-openshift-specific","text":"DeploymentRequest (`apps.openshift.io/v1`) is OpenShift-specific, not part of upstream Kubernetes; it triggers deployments via the `instantiate` subresource of DeploymentConfig","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentrequest-openshift-specific.json"},{"id":"deploymentrequest-required-fields","text":"DeploymentRequest required fields are `name`, `latest`, and `force`; the endpoint is `POST /apis/apps.openshift.io/v1/namespaces/{namespace}/deploymentconfigs/{name}/instantiate`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/deploymentrequest-required-fields.json"},{"id":"descheduler-does-not-schedule-replacements","text":"The descheduler only evicts pods; it does not schedule replacement pods — the scheduler handles rescheduling.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/descheduler-does-not-schedule-replacements.json"},{"id":"descheduler-protected-namespaces","text":"The descheduler cannot evict pods in `openshift-*` or `kube-system` namespaces, nor static pods, mirror pods, stand-alone pods, or DaemonSet pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/descheduler-protected-namespaces.json"},{"id":"dev-spaces-based-on-eclipse-che","text":"Red Hat OpenShift Dev Spaces is Red Hat's productized, supported distribution of Eclipse Che, providing browser-based containerized development environments on OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dev-spaces-based-on-eclipse-che.json"},{"id":"dev-spaces-own-version-numbering","text":"OpenShift Dev Spaces has its own version numbering (3.x) independent of OpenShift Container Platform versions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dev-spaces-own-version-numbering.json"},{"id":"dev-spaces-uses-devfiles","text":"Dev Spaces workspace configurations use the devfile specification.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dev-spaces-uses-devfiles.json"},{"id":"developer-preview-vs-tech-preview","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/developer-preview-vs-tech-preview.json"},{"id":"disable-default-catalogsources-command","text":"Disabling all default catalog sources: `oc patch operatorhub cluster --type json -p '[{\"op\": \"add\", \"path\": \"/spec/disableAllDefaultSources\", \"value\": true}]'`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disable-default-catalogsources-command.json"},{"id":"disaster-recovery-diverges-despite-unified-platform-model","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disaster-recovery-diverges-despite-unified-platform-model.json"},{"id":"disaster-recovery-shares-immutability-constraint","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disaster-recovery-shares-immutability-constraint.json"},{"id":"disaster-recovery-varies-by-topology","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disaster-recovery-varies-by-topology.json"},{"id":"disaster-recovery-within-version-governance","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disaster-recovery-within-version-governance.json"},{"id":"disconnected-cluster-delivery-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-cluster-delivery-pipeline.json"},{"id":"disconnected-day2-requires-mirrored-content","text":"Both initial installation and day-2 operations (updates, operator installation) require mirrored content in disconnected environments","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-day2-requires-mirrored-content.json"},{"id":"disconnected-delivery-pipeline-fully-operational","text":"The disconnected cluster delivery pipeline (oc-mirror → IDMS → MCO for images; FBC catalogs for operators) is fully operational end-to-end only when OLM v1 can authenticate to private registries.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-delivery-pipeline-fully-operational.json"},{"id":"disconnected-image-mirror-redirect-icsp-idms","text":"In disconnected environments, ImageContentSourcePolicy (ICSP) or ImageDigestMirrorSet (IDMS) redirect image pulls to a mirror registry","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-image-mirror-redirect-icsp-idms.json"},{"id":"disconnected-image-mirroring-tools","text":"oc-mirror or oc adm catalog mirror are used to populate a local registry with required images for disconnected installations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-image-mirroring-tools.json"},{"id":"disconnected-samples-operator-defaults-removed","text":"In disconnected installations, the Cluster Samples Operator defaults to `Removed` status; it must be set to `Managed` to install image streams.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disconnected-samples-operator-defaults-removed.json"},{"id":"disk-encryption-tpm-pcr1-pcr7","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/disk-encryption-tpm-pcr1-pcr7.json"},{"id":"distributed-tracing-backed-by-jaeger-tempo-otel","text":"OpenShift distributed tracing is backed by Red Hat OpenShift distributed tracing platform (based on Jaeger/Tempo) and the OpenTelemetry Collector","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/distributed-tracing-backed-by-jaeger-tempo-otel.json"},{"id":"distributed-tracing-not-enabled-by-default","text":"Distributed tracing in OpenShift is a configurable platform feature that is not enabled by default — it requires operator installation and configuration","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/distributed-tracing-not-enabled-by-default.json"},{"id":"distributed-tracing-three-capabilities","text":"Distributed tracing provides three key capabilities: store, analyze, and visualize transaction data across microservices","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/distributed-tracing-three-capabilities.json"},{"id":"dns-basedomain-privatezone-publiczone-immutable","text":"The DNS config fields `baseDomain`, `publicZone`, and `privateZone` are immutable after initial creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-basedomain-privatezone-publiczone-immutable.json"},{"id":"dns-ca-bundle-configmap-openshift-config","text":"DNS TLS CA bundle ConfigMaps must be in `openshift-config` namespace with key `ca-bundle.crt` (PEM encoded).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-ca-bundle-configmap-openshift-config.json"},{"id":"dns-cache-default-ttls","text":"Default DNS cache TTLs are positive = 900 seconds (15 minutes) and negative = 30 seconds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-cache-default-ttls.json"},{"id":"dns-cache-positive-ttl-900s-negative-30s","text":"Default DNS cache TTLs are positiveTTL=900s and negativeTTL=30s when fields are omitted.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-cache-positive-ttl-900s-negative-30s.json"},{"id":"dns-cannot-specify-cluster-domain-as-zone","text":"The cluster domain (e.g., `cluster.local`) cannot be specified as a zone in `.spec.servers`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-cannot-specify-cluster-domain-as-zone.json"},{"id":"dns-cluster-ip-10th-address-service-cidr","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-cluster-ip-10th-address-service-cidr.json"},{"id":"dns-cluster-local-invalid-forwarding-zone","text":"`cluster.local` cannot be used as a forwarding zone in `spec.servers.zones`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-cluster-local-invalid-forwarding-zone.json"},{"id":"dns-config-vs-dns-operator-different-api-groups","text":"The DNS config object uses API group `config.openshift.io/v1`, distinct from the DNS operator object under `operator.openshift.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-config-vs-dns-operator-different-api-groups.json"},{"id":"dns-default-master-toleration-removal-risks-outage","text":"Removing the default `node-role.kubernetes.io/master` toleration from DNS pods risks cluster DNS outage if all worker nodes go down.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-default-master-toleration-removal-risks-outage.json"},{"id":"dns-forward-policy-defaults-differ","text":"DNS forward policy defaults differ: `Random` for `.spec.servers` entries, `Sequential` for `.spec.upstreamResolvers`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-forward-policy-defaults-differ.json"},{"id":"dns-forward-policy-random-servers-sequential-upstream","text":"DNS forward policy defaults differ: Random for spec.servers, Sequential for spec.upstreamResolvers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-forward-policy-random-servers-sequential-upstream.json"},{"id":"dns-max-15-upstreams-per-forwardplugin","text":"Maximum of 15 upstreams per forwardPlugin in DNS forwarding configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-max-15-upstreams-per-forwardplugin.json"},{"id":"dns-nil-publiczone-no-public-records","text":"If `publicZone` is nil on the DNS config, no public DNS records are created (relevant for private/disconnected clusters).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-nil-publiczone-no-public-records.json"},{"id":"dns-node-resolver-daemonset-image-registry","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-node-resolver-daemonset-image-registry.json"},{"id":"dns-operator-coredns-daemonset","text":"The DNS Operator deploys CoreDNS as a DaemonSet on all nodes with default domain `cluster.local`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-operator-coredns-daemonset.json"},{"id":"dns-operator-deploys-coredns-daemonset","text":"The DNS Operator deploys CoreDNS as a DaemonSet (not a Deployment) in the `openshift-dns` namespace.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-operator-deploys-coredns-daemonset.json"},{"id":"dns-operator-manages-coredns","text":"The DNS Operator (`operator.openshift.io/v1`) manages CoreDNS as the cluster-wide name resolution service in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-operator-manages-coredns.json"},{"id":"dns-operator-namespace-openshift-dns-operator","text":"The DNS Operator runs in the `openshift-dns-operator` namespace; CoreDNS pods run in `openshift-dns`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-operator-namespace-openshift-dns-operator.json"},{"id":"dns-over-tls-port-853","text":"DNS-over-TLS uses port 853 by default (per RFC 7858) and requires the `serverName` field to be set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-over-tls-port-853.json"},{"id":"dns-platform-config-only-aws","text":"The DNS config `spec.platform` currently only supports `AWS` as a named platform type, with `privateZoneIAMRole` for cross-account DNS management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-platform-config-only-aws.json"},{"id":"dns-service-discovery-architecture","text":"OpenShift DNS follows a deterministic architecture: CoreDNS runs as a DaemonSet (not Deployment) managed by the DNS Operator, the cluster DNS IP is algorithmically derived as the 10th address in the service CIDR, cluster.local is reserved and cannot be used as a forwarding zone, and the full cluster DNS name follows `<metadata.name>.<baseDomain>` — making DNS both predictable and constrained.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-service-discovery-architecture.json"},{"id":"dns-unmanaged-blocks-cluster-upgrades","text":"Setting DNS Operator managementState to Unmanaged blocks cluster upgrades.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dns-unmanaged-blocks-cluster-upgrades.json"},{"id":"dnsrecord-default-ttl-30-seconds","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dnsrecord-default-ttl-30-seconds.json"},{"id":"dnsrecord-internal-operator-resource","text":"The DNSRecord resource (`ingress.operator.openshift.io/v1`) is an internal operator resource not intended for cluster admin manipulation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dnsrecord-internal-operator-resource.json"},{"id":"dnsrecord-is-namespaced","text":"The DNSRecord resource is namespaced, not cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dnsrecord-is-namespaced.json"},{"id":"dnsrecord-management-policy-managed-unmanaged","text":"The `dnsManagementPolicy` field on DNSRecord controls whether the ingress operator manages DNS records; valid values are `Managed` (default) and `Unmanaged`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dnsrecord-management-policy-managed-unmanaged.json"},{"id":"do-not-edit-cno-managed-nad","text":"NetworkAttachmentDefinition CRs managed by the Cluster Network Operator must not be manually edited","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/do-not-edit-cno-managed-nad.json"},{"id":"do-not-modify-clusterversion-directly","text":"Administrators should not directly modify the ClusterVersion object — use `oc` CLI or web console instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/do-not-modify-clusterversion-directly.json"},{"id":"docker-runtime-deprecated-k8s-120","text":"Docker as a container runtime is deprecated in Kubernetes 1.20, but Docker-built images still work with all container runtimes including CRI-O.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/docker-runtime-deprecated-k8s-120.json"},{"id":"docker-strategy-requires-elevated-privileges","text":"Docker strategy builds require elevated privileges and may be restricted in multi-tenant clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/docker-strategy-requires-elevated-privileges.json"},{"id":"dockerimagelayers-manifests-mutually-exclusive","text":"In Image objects, `dockerImageManifests[]` and `dockerImageLayers[]` are mutually exclusive — manifest lists vs single images","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dockerimagelayers-manifests-mutually-exclusive.json"},{"id":"dpdk-1gi-hugepages-require-kernel-args","text":"1Gi hugepages require kernel arguments: `default_hugepagesz=1GB`, `hugepagesz=1G`, `hugepages=16`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dpdk-1gi-hugepages-require-kernel-args.json"},{"id":"dpdk-intel-vfio-pci-mellanox-netdevice","text":"For DPDK workloads, Intel NICs use `deviceType: vfio-pci` (vendor `8086`) while Mellanox NICs use `deviceType: netdevice` with `isRdma: true` (vendor `15b3`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dpdk-intel-vfio-pci-mellanox-netdevice.json"},{"id":"dpdk-pod-required-capabilities","text":"DPDK/RDMA pods require three security capabilities: `IPC_LOCK`, `SYS_RESOURCE`, and `NET_RAW`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dpdk-pod-required-capabilities.json"},{"id":"dpdk-requires-hugepages-and-static-cpu-manager","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dpdk-requires-hugepages-and-static-cpu-manager.json"},{"id":"drain-ignore-daemonsets-flag","text":"`oc adm drain` requires `--ignore-daemonsets=true` when DaemonSet-managed pods exist on the node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/drain-ignore-daemonsets-flag.json"},{"id":"dual-stack-ip-order-must-match","text":"In dual-stack configurations, IPv4 and IPv6 addresses must be listed in the same order across all network parameters (clusterNetwork, serviceNetwork, machineNetwork).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dual-stack-ip-order-must-match.json"},{"id":"dual-stack-networking-operational-on-platform","text":"Dual-stack IPv4/IPv6 networking is fully operational on the target platform when no platform-specific IPv4-only restrictions apply.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dual-stack-networking-operational-on-platform.json"},{"id":"dual-stack-networking-with-constraints","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dual-stack-networking-with-constraints.json"},{"id":"dual-stack-same-interface-required","text":"Dual-stack networking requires both IP families (IPv4 and IPv6) to use the same network interface for the default gateway.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dual-stack-same-interface-required.json"},{"id":"dynamic-plugin-disable-query-param","text":"Users can disable console plugins via the `disable-plugins` query parameter in the browser URL","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-disable-query-param.json"},{"id":"dynamic-plugin-enable-path","text":"Dynamic plugins are enabled/disabled by cluster admins via Administration → Cluster Settings → Configuration → Console (`operator.openshift.io`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-enable-path.json"},{"id":"dynamic-plugin-helm-deploy-command","text":"Dynamic plugins are deployed via Helm using `helm upgrade -i <name> charts/openshift-console-plugin -n <namespace> --create-namespace --set plugin.image=<image>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-helm-deploy-command.json"},{"id":"dynamic-plugin-i18n-namespace-prefix","text":"Dynamic plugin i18n namespace must be prefixed with `plugin__` and match the `ConsolePlugin` resource name","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-i18n-namespace-prefix.json"},{"id":"dynamic-plugin-no-redhat-support","text":"Custom dynamic plugin code is not supported by Red Hat — only cooperative community support is available","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-no-redhat-support.json"},{"id":"dynamic-plugin-patternfly-version-alignment","text":"Dynamic plugins require PatternFly 4.x for OCP ≤4.14 and PatternFly 5.x for OCP ≥4.15","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-patternfly-version-alignment.json"},{"id":"dynamic-plugin-proxy-auth-values","text":"The proxy `authorization` field in a `ConsolePlugin` CR accepts values `UserToken` (forwards user's OCP token) or `None`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-proxy-auth-values.json"},{"id":"dynamic-plugin-proxy-url-pattern","text":"Service proxy endpoint for dynamic plugins follows the pattern `/api/proxy/plugin/<plugin-name>/<proxy-alias>/<request-path>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-plugin-proxy-url-pattern.json"},{"id":"dynamic-provisioned-volumes-delete-policy","text":"Dynamically provisioned volumes always use the `Delete` reclaim policy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-provisioned-volumes-delete-policy.json"},{"id":"dynamic-provisioning-requires-storageclass","text":"Dynamic provisioning requires a StorageClass — it creates PVs on-demand, eliminating the need for admin pre-provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamic-provisioning-requires-storageclass.json"},{"id":"dynamically-provisioned-volumes-delete-policy","text":"Dynamically provisioned persistent volumes always use the Delete reclaim policy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/dynamically-provisioned-volumes-delete-policy.json"},{"id":"ebpf-agent-layer3-not-layer2","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-agent-layer3-not-layer2.json"},{"id":"ebpf-manager-alpha-channel-community-operators","text":"The eBPF Manager Operator uses the `alpha` channel from the `community-operators` catalog source.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-manager-alpha-channel-community-operators.json"},{"id":"ebpf-manager-bpfman-namespace-privileged","text":"The eBPF Manager Operator is installed in the `bpfman` namespace with privileged pod security enforcement.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-manager-bpfman-namespace-privileged.json"},{"id":"ebpf-manager-operator-tech-preview","text":"The eBPF Manager Operator is a Technology Preview feature — not supported for production use.","truth_value":"IN","justification_count":0,"dependent_count":5,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-manager-operator-tech-preview.json"},{"id":"ebpf-maps-accessed-via-csi-volume-mounts","text":"Applications access eBPF maps via CSI volume mounts, so application pods do not need privileged access.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-maps-accessed-via-csi-volume-mounts.json"},{"id":"ebpf-programs-packaged-oci-images","text":"eBPF programs managed by the eBPF Manager Operator are packaged as OCI container images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ebpf-programs-packaged-oci-images.json"},{"id":"edge-compute-pool-noschedule-taint","text":"Edge compute pool nodes (Local Zones / Wavelength Zones) have a NoSchedule taint by default; workloads require explicit tolerations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-compute-pool-noschedule-taint.json"},{"id":"edge-computing-first-class-ocp-deployment","text":"Edge computing is a first-class deployment model in OpenShift Container Platform with dedicated documentation, tooling, and specialized topologies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-computing-first-class-ocp-deployment.json"},{"id":"edge-computing-targets-far-edge","text":"Edge computing in OpenShift targets far-edge use cases (e.g., cell towers, retail locations, industrial sites), not near-edge or regional data centers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-computing-targets-far-edge.json"},{"id":"edge-disconnected-fleet-delivery","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-disconnected-fleet-delivery.json"},{"id":"edge-disconnected-fleet-fully-operational","text":"Edge fleet deployments with disconnected content delivery are fully operational end-to-end — ZTP provisions clusters while mirror pipelines deliver all content — only when OLM v1 reaches GA and supports private registry authentication for operator catalogs.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-disconnected-fleet-fully-operational.json"},{"id":"edge-fleet-management-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-fleet-management-pipeline.json"},{"id":"edge-fleet-with-full-observability","text":"Edge fleet deployments with disconnected content delivery achieve full operational visibility — ZTP provisions clusters, mirror pipelines deliver content, and the complete observability stack (monitoring + network observability + power monitoring) provides feedback — only when observability tech preview components reach GA.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-fleet-with-full-observability.json"},{"id":"edge-routes-tls-at-router","text":"Edge routes provide TLS termination at the router level (HAProxy Ingress Controller). Created with `oc create route edge <name> --service=<service>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-routes-tls-at-router.json"},{"id":"edge-zone-default-ebs-gp2","text":"Default EBS volume type for AWS Local Zone and Wavelength Zone compute pools is gp2, unlike non-edge compute pools.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/edge-zone-default-ebs-gp2.json"},{"id":"egress-firewall-default-allow","text":"EgressFirewall default behavior is allow — without an EgressFirewall or when no rule matches, all egress traffic is permitted","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egress-firewall-default-allow.json"},{"id":"egress-firewall-dns-wildcard-single-level","text":"EgressFirewall dnsName wildcards match only one label level — `*.example.com` matches `sub1.example.com` but not `sub2.sub1.example.com`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egress-firewall-dns-wildcard-single-level.json"},{"id":"egress-firewall-namespace-scoped-ovn","text":"EgressFirewall is namespace-scoped (not cluster-scoped) and uses the `k8s.ovn.org/v1` API group (OVN-Kubernetes specific)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egress-firewall-namespace-scoped-ovn.json"},{"id":"egress-firewall-ordered-first-match-wins","text":"EgressFirewall rules are evaluated in order (first match wins) with three mutually exclusive destination selectors: cidrSelector, dnsName, or nodeSelector","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egress-firewall-ordered-first-match-wins.json"},{"id":"egress-firewall-protocols-tcp-udp-sctp","text":"EgressFirewall supports three protocols for port filtering: tcp, udp, and sctp","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egress-firewall-protocols-tcp-udp-sctp.json"},{"id":"egressfirewall-api-group-ovn","text":"The EgressFirewall CR uses the API group `k8s.ovn.org/v1` in OVN-Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-api-group-ovn.json"},{"id":"egressfirewall-broken-config-drops-all","text":"A broken EgressFirewall configuration causes all external traffic to be dropped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-broken-config-drops-all.json"},{"id":"egressfirewall-cluster-admin-only","text":"Only cluster administrators can create, edit, or delete EgressFirewall resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-cluster-admin-only.json"},{"id":"egressfirewall-default-allow","text":"EgressFirewall default behavior is allow when no rule matches or no EgressFirewall exists; rules are evaluated in order (first match wins)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-default-allow.json"},{"id":"egressfirewall-deny-all-blocks-api-server","text":"A deny-all rule (`0.0.0.0/0`) in EgressFirewall blocks API server access; API server IPs must be explicitly allowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-deny-all-blocks-api-server.json"},{"id":"egressfirewall-dns-polling-30min-default","text":"DNS-based EgressFirewall rules poll for IP changes based on TTL with a default interval of 30 minutes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-dns-polling-30min-default.json"},{"id":"egressfirewall-filter-types","text":"EgressFirewall rules can filter outbound traffic by DNS name, IP address, or CIDR range.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-filter-types.json"},{"id":"egressfirewall-first-match-wins","text":"EgressFirewall rules are evaluated in order; the first matching rule wins and subsequent rules are ignored for that connection.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-first-match-wins.json"},{"id":"egressfirewall-host-network-pods-unaffected","text":"Pods with host networking enabled are not affected by EgressFirewall rules.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-host-network-pods-unaffected.json"},{"id":"egressfirewall-max-8000-rules","text":"Maximum of 8,000 rules per EgressFirewall object.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-max-8000-rules.json"},{"id":"egressfirewall-one-per-namespace","text":"Only one EgressFirewall custom resource is allowed per namespace when using OVN-Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-one-per-namespace.json"},{"id":"egressfirewall-one-per-project-named-default","text":"Only one EgressFirewall CR is allowed per project, and it must be named `default`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-one-per-project-named-default.json"},{"id":"egressfirewall-requires-ovn-kubernetes","text":"EgressFirewall requires the OVN-Kubernetes network plugin (API group `k8s.ovn.org/v1`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-requires-ovn-kubernetes.json"},{"id":"egressfirewall-routes-bypass","text":"Traffic going through OpenShift Routes bypasses EgressFirewall rules; users with Route CR permissions can bypass restrictions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressfirewall-routes-bypass.json"},{"id":"egressip-api-group-ovn","text":"EgressIP uses API group `k8s.ovn.org/v1` and is specific to the OVN-Kubernetes network plugin","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-api-group-ovn.json"},{"id":"egressip-cluster-scoped","text":"EgressIP is a cluster-scoped resource (not namespaced)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-cluster-scoped.json"},{"id":"egressip-dual-stack-support","text":"EgressIP supports dual-stack with both IPv4 and IPv6 addresses in the same resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-dual-stack-support.json"},{"id":"egressip-fixed-source-ip","text":"EgressIP (`k8s.ovn.org/v1`) provides a fixed source IP for egress traffic from matching pods","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-fixed-source-ip.json"},{"id":"egressip-podselector-omit-behavior","text":"When EgressIP `podSelector` is omitted, the egress IP applies to all pods in matched namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-podselector-omit-behavior.json"},{"id":"egressip-required-fields","text":"EgressIP requires both `spec.egressIPs` (list of IPs) and `spec.namespaceSelector` in the spec; `podSelector` is optional","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-required-fields.json"},{"id":"egressip-selector-intersection","text":"When both `namespaceSelector` and `podSelector` are set on an EgressIP, they are intersected — pods must match both","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-selector-intersection.json"},{"id":"egressip-status-shows-node-mapping","text":"EgressIP `.status.items[]` is read-only and shows the node-to-IP mapping for assigned egress IPs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressip-status-shows-node-mapping.json"},{"id":"egressqos-dscp-marking","text":"EgressQoS assigns DSCP (Differentiated Services Code Point) values to egress traffic from pods for QoS differentiation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressqos-dscp-marking.json"},{"id":"egressqos-dscp-only-required-field","text":"In each EgressQoS rule, `dscp` is the only required field; `dstCIDR` and `podSelector` are optional","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressqos-dscp-only-required-field.json"},{"id":"egressqos-namespace-scoped","text":"EgressQoS is a namespace-scoped resource in the `k8s.ovn.org/v1` API group, specific to OVN-Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressqos-namespace-scoped.json"},{"id":"egressqos-omit-dstcidr-all-traffic","text":"When `dstCIDR` is omitted from an EgressQoS rule, the DSCP marking applies to all egress traffic regardless of destination","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressqos-omit-dstcidr-all-traffic.json"},{"id":"egressqos-rules-ordered","text":"EgressQoS traffic is checked against rules in order; matching traffic gets the DSCP value from the first matching rule","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressqos-rules-ordered.json"},{"id":"egressrouter-api-group","text":"EgressRouter uses API group `network.operator.openshift.io/v1` and is managed by the Cluster Network Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-api-group.json"},{"id":"egressrouter-creates-three-resources","text":"Creating an EgressRouter CR automatically creates three resources with the same name: a Service, a Pod, and a NetworkAttachmentDefinition (NAD)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-creates-three-resources.json"},{"id":"egressrouter-macvlan-default-bridge","text":"EgressRouter macvlan default mode is `Bridge`; the `master` interface is optional if inferable from the IP","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-macvlan-default-bridge.json"},{"id":"egressrouter-no-fallbackip-rejects","text":"If EgressRouter has redirect rules but no `fallbackIP`, connections on undefined ports are rejected","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-no-fallbackip-rejects.json"},{"id":"egressrouter-only-redirect-macvlan","text":"EgressRouter only supports mode `Redirect` (DNAT-based) and only supports `macvlan` as the network interface type","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-only-redirect-macvlan.json"},{"id":"egressrouter-redirect-protocols","text":"EgressRouter redirect rules support TCP, UDP, and SCTP protocols; `targetPort` defaults to `port` if omitted","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressrouter-redirect-protocols.json"},{"id":"egressservice-loadbalancerip-single-node","text":"When EgressService `sourceIPBy=LoadBalancerIP`, traffic is pinned to a single node shown in `.status.host`; when `sourceIPBy=Network`, status host is `\"ALL\"`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-loadbalancerip-single-node.json"},{"id":"egressservice-matches-loadbalancer-ip","text":"EgressService (`k8s.ovn.org/v1`) makes egress source IP equal to the LoadBalancer Service's ingress IP","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-matches-loadbalancer-ip.json"},{"id":"egressservice-network-field-vrf","text":"EgressService `network` field enables routing egress through an alternate network/VRF rather than the default routing table","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-network-field-vrf.json"},{"id":"egressservice-nodeselector-only-loadbalancerip","text":"EgressService `nodeSelector` field only applies when `sourceIPBy=LoadBalancerIP`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-nodeselector-only-loadbalancerip.json"},{"id":"egressservice-ovn-namespaced","text":"EgressService is a namespaced CRD in the `k8s.ovn.org/v1` API group, specific to OVN-Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-ovn-namespaced.json"},{"id":"egressservice-sourceipby-modes","text":"EgressService `sourceIPBy` has two modes: `LoadBalancerIP` (uses LB ingress IP as source) and `Network` (uses node interface IP)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/egressservice-sourceipby-modes.json"},{"id":"emptydir-usage-counts-toward-pod-ephemeral-limit","text":"EmptyDir volume usage counts toward the pod's overall ephemeral storage consumption and limits.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/emptydir-usage-counts-toward-pod-ephemeral-limit.json"},{"id":"enable-default-route-patch-command","text":"The default external route for the registry is enabled with `oc patch configs.imageregistry.operator.openshift.io/cluster --type merge -p '{\"spec\":{\"defaultRoute\":true}}'`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/enable-default-route-patch-command.json"},{"id":"encryption-and-tls-infrastructure-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/encryption-and-tls-infrastructure-model.json"},{"id":"end-users-access-images-via-imagestreamtag-or-imagestreamimage","text":"End users access images via ImageStreamTags or ImageStreamImages, not the Image resource directly.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/end-users-access-images-via-imagestreamtag-or-imagestreamimage.json"},{"id":"end-users-access-images-via-istag-isimage","text":"End users should access images through ImageStreamTag or ImageStreamImage resources, not directly through Image resources (which are for cluster admins and integrations)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/end-users-access-images-via-istag-isimage.json"},{"id":"end-users-create-projects-via-projectrequest","text":"End users create projects via the ProjectRequest resource (`oc new-project`), not by directly creating Project objects","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/end-users-create-projects-via-projectrequest.json"},{"id":"endpoints-auto-created-same-name","text":"Endpoints objects are automatically created with the same name as the Service when the Service has a selector","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-auto-created-same-name.json"},{"id":"endpoints-cartesian-product","text":"The expanded endpoint set within a subset is the Cartesian product of Addresses × Ports","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-cartesian-product.json"},{"id":"endpoints-core-v1-namespaced","text":"Endpoints are namespaced core `v1` objects at API path `/api/v1/`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-core-v1-namespaced.json"},{"id":"endpoints-forbidden-ip-ranges","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-forbidden-ip-ranges.json"},{"id":"endpoints-manual-no-selector","text":"Manual Endpoints (Service with no selector) allow routing to external IPs or other namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-manual-no-selector.json"},{"id":"endpoints-notready-excluded-lb","text":"Addresses in `notReadyAddresses` have failed health checks or are still starting and are excluded from load balancing","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-notready-excluded-lb.json"},{"id":"endpoints-port-default-tcp","text":"EndpointPort protocol defaults to TCP; valid values are TCP, UDP, and SCTP","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpoints-port-default-tcp.json"},{"id":"endpointslice-address-type-immutable","text":"EndpointSlice `addressType` field is immutable after creation and supports three values: IPv4, IPv6, FQDN","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-address-type-immutable.json"},{"id":"endpointslice-api-group-discovery-v1","text":"EndpointSlice belongs to API group `discovery.k8s.io/v1`, not the `v1` core API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-api-group-discovery-v1.json"},{"id":"endpointslice-default-port-protocol-tcp","text":"The default port protocol for EndpointSlice ports is TCP; supported protocols are TCP, UDP, and SCTP","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-default-port-protocol-tcp.json"},{"id":"endpointslice-max-1000-endpoints-100-ports","text":"Each EndpointSlice can hold a maximum of 1000 endpoints and 100 ports","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-max-1000-endpoints-100-ports.json"},{"id":"endpointslice-nil-ready-means-ready","text":"A nil `ready` condition on an EndpointSlice endpoint should be interpreted as ready by consumers","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-nil-ready-means-ready.json"},{"id":"endpointslice-three-conditions","text":"EndpointSlice endpoints track three conditions: `ready` (prepared to receive traffic), `serving` (like ready but remains true during termination), and `terminating` (endpoint is shutting down)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/endpointslice-three-conditions.json"},{"id":"ephemeral-containers-added-at-runtime-only","text":"Ephemeral containers are added to running pods via the ephemeralcontainers subresource for debugging — they cannot be specified at pod creation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-containers-added-at-runtime-only.json"},{"id":"ephemeral-containers-via-subresource","text":"Ephemeral containers are added to running pods via the `ephemeralcontainers` subresource, not by updating the pod spec directly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-containers-via-subresource.json"},{"id":"ephemeral-storage-best-effort-resource","text":"Ephemeral storage is a best-effort resource — pods cannot detect available local storage or request guaranteed local storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-storage-best-effort-resource.json"},{"id":"ephemeral-storage-pod-limit-is-sum-of-container-limits","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-storage-pod-limit-is-sum-of-container-limits.json"},{"id":"ephemeral-storage-root-partition-path","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-storage-root-partition-path.json"},{"id":"ephemeral-storage-unit-suffixes-case-sensitive","text":"Ephemeral storage unit suffixes are case-sensitive: `M` = megabytes, `Mi` = mebibytes, `m` = millibytes (0.001 bytes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ephemeral-storage-unit-suffixes-case-sensitive.json"},{"id":"etc-passwd-must-not-exist-in-image","text":"The /etc/passwd file must not exist in the container image because CRI-O injects random UIDs into it at runtime","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etc-passwd-must-not-exist-in-image.json"},{"id":"etcd-automated-backup-pvc-in-openshift-etcd","text":"The PVC for automated etcd backups must be in the `openshift-etcd` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-automated-backup-pvc-in-openshift-etcd.json"},{"id":"etcd-automated-backup-retention-default-15","text":"Automated etcd backup retention types are RetentionNumber (default: 15 backups) or RetentionSize.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-automated-backup-retention-default-15.json"},{"id":"etcd-backup-before-cluster-shutdown","text":"etcd must be backed up before shutting down a cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-before-cluster-shutdown.json"},{"id":"etcd-backup-from-single-control-plane-host","text":"etcd backup must be taken from only one control plane host, not from each control plane host.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-from-single-control-plane-host.json"},{"id":"etcd-backup-not-rollback-mechanism","text":"etcd backup/restore is a last-resort disaster recovery mechanism, not a rollback mechanism — rolling back to a previous OCP version is not supported.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-not-rollback-mechanism.json"},{"id":"etcd-backup-primary-disaster-recovery","text":"etcd backup and restore is the primary mechanism for cluster-level disaster recovery in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-primary-disaster-recovery.json"},{"id":"etcd-backup-produces-two-files","text":"etcd backup produces two files: `snapshot_<datetimestamp>.db` (the etcd snapshot) and `static_kuberesources_<datetimestamp>.tar.gz` (static pod resources and encryption keys if enabled).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-produces-two-files.json"},{"id":"etcd-backup-requires-oc-debug-chroot","text":"To run the etcd backup, you must first `oc debug --as-root node/<node>` then `chroot /host` before executing the backup script.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-requires-oc-debug-chroot.json"},{"id":"etcd-backup-script-path","text":"The etcd backup script is located at `/usr/local/bin/cluster-backup.sh` and is maintained by the etcd Cluster Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-script-path.json"},{"id":"etcd-backup-separate-from-oadp","text":"etcd backup is separate from OADP and uses its own backup/restore mechanism; etcd backup is the fundamental cluster-level backup in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-backup-separate-from-oadp.json"},{"id":"etcd-controlplanehardwarespeed-slower-for-latency","text":"The Etcd operator `controlPlaneHardwareSpeed` field with value `Slower` tunes etcd for environments with higher network latency between control plane nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-controlplanehardwarespeed-slower-for-latency.json"},{"id":"etcd-default-revision-limits-5","text":"Etcd operator default revision limits (both `failedRevisionLimit` and `succeededRevisionLimit`) are 5 when set to 0 or unset; `-1` means unlimited.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-default-revision-limits-5.json"},{"id":"etcd-disaster-recovery-constraints","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-disaster-recovery-constraints.json"},{"id":"etcd-encrypted-resource-types","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encrypted-resource-types.json"},{"id":"etcd-encryption-encrypts-values-not-keys","text":"etcd encryption only encrypts values, not keys — resource types, namespaces, and object names remain unencrypted.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encryption-encrypts-values-not-keys.json"},{"id":"etcd-encryption-keys-rotate-weekly","text":"etcd encryption keys are rotated automatically on a weekly basis for both AES-GCM and AES-CBC encryption types.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encryption-keys-rotate-weekly.json"},{"id":"etcd-encryption-not-default","text":"OpenShift does not encrypt etcd data by default; encryption must be explicitly enabled via the APIServer custom resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encryption-not-default.json"},{"id":"etcd-encryption-three-types","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encryption-three-types.json"},{"id":"etcd-encryption-verify-three-api-servers","text":"etcd encryption completion must be verified on three separate API servers: openshiftapiserver, kubeapiserver, and authentication.operator.openshift.io.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-encryption-verify-three-api-servers.json"},{"id":"etcd-ephemeral-min-10gb","text":"The Nova ephemeral disk for etcd requires a minimum of 10 GB per control plane node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-ephemeral-min-10gb.json"},{"id":"etcd-ephemeral-not-rbd","text":"Nova ephemeral storage for etcd must use a local storage backend, not `rbd`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-ephemeral-not-rbd.json"},{"id":"etcd-ephemeral-xfs-format","text":"The ephemeral disk for etcd is formatted as XFS with label `local-etcd` and mounted with `defaults,prjquota` options.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-ephemeral-xfs-format.json"},{"id":"etcd-force-redeployment-reason-retries-failed","text":"The `forceRedeploymentReason` field on the Etcd CR is the mechanism to force redeployment of a previously failed static pod revision using a unique string.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-force-redeployment-reason-retries-failed.json"},{"id":"etcd-local-disk-rhosp-day2","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-local-disk-rhosp-day2.json"},{"id":"etcd-machineconfig-98-var-lib-etcd","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-machineconfig-98-var-lib-etcd.json"},{"id":"etcd-machineconfig-never-remove","text":"The `98-var-lib-etcd` MachineConfig must never be removed while ephemeral disks are in use — doing so breaks etcd and causes system instability.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-machineconfig-never-remove.json"},{"id":"etcd-no-backup-before-first-cert-rotation","text":"Do not take an etcd backup before the first certificate rotation (24 hours after install) because the backup will contain expired certificates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-no-backup-before-first-cert-rotation.json"},{"id":"etcd-primary-cluster-state-datastore","text":"etcd is the primary datastore for OpenShift cluster state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-primary-cluster-state-datastore.json"},{"id":"etcd-quorum-fault-tolerance","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-quorum-fault-tolerance.json"},{"id":"etcd-quorum-protection-predrain-hook","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-quorum-protection-predrain-hook.json"},{"id":"etcd-requires-fast-low-latency-io","text":"etcd is the primary data store for Kubernetes and requires fast, low-latency I/O due to high-frequency small writes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-requires-fast-low-latency-io.json"},{"id":"etcd-restore-requires-same-z-stream","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-restore-requires-same-z-stream.json"},{"id":"etcd-rollback-cpms-no-ephemeral","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-rollback-cpms-no-ephemeral.json"},{"id":"etcd-runs-as-static-pods","text":"Etcd runs as static pods on control plane nodes, managed by the etcd operator with a revision-based deployment model tracked per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-runs-as-static-pods.json"},{"id":"etcd-runs-on-control-plane-nodes","text":"etcd runs exclusively on control plane (master) nodes as static pods managed by the cluster etcd operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-runs-on-control-plane-nodes.json"},{"id":"etcd-sole-persistent-store","text":"etcd is the sole persistent key-value store for all Kubernetes and OpenShift cluster objects and configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-sole-persistent-store.json"},{"id":"etcd-stores-cluster-data","text":"etcd stores cluster state data; kube-scheduler allocates pods to nodes; kube-controller-manager governs cluster state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/etcd-stores-cluster-data.json"},{"id":"eus-extended-ibm-z-power-ocp-414","text":"Extended Update Support (EUS) was extended to IBM Power and IBM Z platforms starting with OCP 4.14.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eus-extended-ibm-z-power-ocp-414.json"},{"id":"event-api-group-events-k8s-io-v1","text":"Events use API group `events.k8s.io/v1` (distinct from the older `v1` core Events).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-api-group-events-k8s-io-v1.json"},{"id":"event-eventtime-only-required-field","text":"`eventTime` (MicroTime) is the only required field on an Event (besides standard metadata).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-eventtime-only-required-field.json"},{"id":"event-namespaced-but-cluster-listable","text":"Events are namespaced resources but can be listed cluster-wide via `/api/v1/events` or `oc get events -A`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-namespaced-but-cluster-listable.json"},{"id":"event-required-fields-metadata-involvedobject","text":"Event objects require `metadata` and `involvedObject` fields; `involvedObject` uses an ObjectReference structure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-required-fields-metadata-involvedobject.json"},{"id":"event-standard-types-normal-warning","text":"The Event `type` field has two standard values: `Normal` and `Warning`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-standard-types-normal-warning.json"},{"id":"event-types-normal-and-warning","text":"Event `type` values are `Normal` and `Warning`; new types may be added in the future.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-types-normal-and-warning.json"},{"id":"event-v1-limited-retention","text":"Kubernetes Events (v1) have limited retention time and are automatically garbage-collected; they should not be relied upon as a reliable audit log.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/event-v1-limited-retention.json"},{"id":"events-limited-retention-not-reliable","text":"Events have limited retention and are best-effort supplemental data; they should not be relied upon for persistent state or decision-making.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/events-limited-retention-not-reliable.json"},{"id":"events-namespaced-resource","text":"Events are namespaced resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/events-namespaced-resource.json"},{"id":"eviction-and-pdb-use-policy-v1-api","text":"Both Eviction and PodDisruptionBudget belong to the `policy/v1` API group (stable/GA).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-and-pdb-use-policy-v1-api.json"},{"id":"eviction-api-group-policy-v1","text":"The Eviction resource uses API group `policy/v1` (stable), replacing the deprecated `policy/v1beta1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-api-group-policy-v1.json"},{"id":"eviction-field-validation-default-warn","text":"The `fieldValidation` parameter defaults to `Warn` in Kubernetes v1.23+ (relevant for OCP 4.x which is based on K8s 1.24+).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-field-validation-default-warn.json"},{"id":"eviction-is-pod-subresource","text":"Eviction is a subresource of Pod, created by POSTing to `/api/v1/namespaces/{namespace}/pods/{pod-name}/eviction`, not a standalone top-level resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-is-pod-subresource.json"},{"id":"eviction-respects-pdb-delete-does-not","text":"Eviction respects PodDisruptionBudgets (PDBs); direct pod deletion does not.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-respects-pdb-delete-does-not.json"},{"id":"eviction-subresource-of-pod","text":"Eviction is a subresource of Pod accessed via `POST /api/v1/namespaces/{namespace}/pods/{name}/eviction`, not a top-level resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/eviction-subresource-of-pod.json"},{"id":"exclude-node-draining-annotation","text":"The annotation `machine.openshift.io/exclude-node-draining` on a machine skips the node drain step during deletion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/exclude-node-draining-annotation.json"},{"id":"expired-certs-approve-csrs","text":"If Ignition certificates expire, recovery requires manually approving pending node-bootstrapper CSRs to restore kubelet certificates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/expired-certs-approve-csrs.json"},{"id":"expired-silences-gc-120-hours","text":"Expired silences in Alertmanager cannot be deleted manually and are garbage collected after 120 hours.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/expired-silences-gc-120-hours.json"},{"id":"explicit-multi-component-enablement-pattern","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/explicit-multi-component-enablement-pattern.json"},{"id":"extension-api-groups-three","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/extension-api-groups-three.json"},{"id":"external-dns-aws-creds-kube-system","text":"AWS credentials for the External DNS Operator come from the `aws-creds` secret in the `kube-system` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-aws-creds-kube-system.json"},{"id":"external-dns-aws-govcloud-no-sts","text":"AWS GovCloud with STS-enabled clusters is not supported by the External DNS Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-aws-govcloud-no-sts.json"},{"id":"external-dns-channel-stable-v1-redhat-operators","text":"The External DNS Operator subscription uses channel `stable-v1` from the `redhat-operators` catalog source.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-channel-stable-v1-redhat-operators.json"},{"id":"external-dns-domain-length-cname-44-a-48","text":"External DNS domain name length limits due to TXT registry prefix: CNAME max 44 chars, A record max 48 chars.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-domain-length-cname-44-a-48.json"},{"id":"external-dns-operator-namespace","text":"The External DNS Operator is installed into the `external-dns-operator` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-operator-namespace.json"},{"id":"external-dns-operator-x86-64-only","text":"The External DNS Operator supports x86_64 architecture only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-operator-x86-64-only.json"},{"id":"external-dns-source-types-service-route","text":"The External DNS Operator supports two source types: Service and OpenShiftRoute.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/external-dns-source-types-service-route.json"},{"id":"externalip-autoassign-bare-metal","text":"`externalIP.autoAssignCIDRs` is primarily useful for bare-metal clusters","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/externalip-autoassign-bare-metal.json"},{"id":"externalip-rejected-takes-precedence","text":"`externalIP.policy.rejectedCIDRs` takes precedence over `allowedCIDRs`; if `externalIP` is nil, ExternalIP cannot be set on Services","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/externalip-rejected-takes-precedence.json"},{"id":"extract-installer-from-mirrored-content","text":"In disconnected installs, the installer must be extracted from mirrored content using `oc adm release extract --command=openshift-install` to ensure version correctness.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/extract-installer-from-mirrored-content.json"},{"id":"factory-precaching-cli-technology-preview","text":"The `factory-precaching-cli` tool (in `quay.io/openshift-kni/telco-ran-tools:latest`) is Technology Preview — not supported under production SLAs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/factory-precaching-cli-technology-preview.json"},{"id":"fbc-bundle-immutability","text":"Bundle images and metadata in FBC are immutable; broken bundles require releasing a new bundle with an upgrade edge rather than in-place fixes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-bundle-immutability.json"},{"id":"fbc-default-format-since-ocp411","text":"File-based catalogs (FBC) in JSON/YAML are the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-default-format-since-ocp411.json"},{"id":"fbc-default-since-ocp-411-sqlite-deprecated","text":"File-based catalogs (FBC) became the default Operator catalog format since OCP 4.11; the SQLite database format is deprecated.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-default-since-ocp-411-sqlite-deprecated.json"},{"id":"fbc-deprecations-schema","text":"The `olm.deprecations` schema defines deprecation info for packages, bundles, and channels, surfacing `PackageDeprecated`, `ChannelDeprecated`, and `BundleDeprecated` status conditions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-deprecations-schema.json"},{"id":"fbc-format-json-yaml-not-sqlite","text":"File-based catalogs (FBC) use plain-text JSON or YAML declarative configuration, replacing the older SQLite database format","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-format-json-yaml-not-sqlite.json"},{"id":"fbc-modernizes-operator-catalog-format","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-modernizes-operator-catalog-format.json"},{"id":"fbc-required-schemas-per-package","text":"Each FBC package requires exactly one `olm.package` blob, at least one `olm.channel`, and one or more `olm.bundle` blobs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-required-schemas-per-package.json"},{"id":"fbc-skiprange-prunes-update-graph","text":"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","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-skiprange-prunes-update-graph.json"},{"id":"fbc-three-required-schemas","text":"File-based catalogs require three schema types per package: `olm.package` (exactly one), `olm.channel` (at least one), and `olm.bundle` (one or more).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-three-required-schemas.json"},{"id":"fbc-three-schemas","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fbc-three-schemas.json"},{"id":"featuregate-custom-no-upgrade-irreversible-blocks-upgrades","text":"Setting `featureSet` to `CustomNoUpgrade` on the FeatureGate resource is unsupported, irreversible, and blocks cluster upgrades.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/featuregate-custom-no-upgrade-irreversible-blocks-upgrades.json"},{"id":"featuregate-default-featureset-empty","text":"The default `featureSet` on the FeatureGate resource is empty (no value), which applies the standard feature set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/featuregate-default-featureset-empty.json"},{"id":"featuregate-operators-read-status-not-spec","text":"Operators must read `.status.featureGates` (not `.spec`) to determine which features are active for their managed version.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/featuregate-operators-read-status-not-spec.json"},{"id":"field-selector-filter-events-by-involved-object","text":"Events can be filtered by involved object using field selectors: `oc get events --field-selector involvedObject.name=<pod-name>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-selector-filter-events-by-involved-object.json"},{"id":"field-validation-default-changed-k8s-1.23","text":"The `fieldValidation` query parameter default changed from `Ignore` to `Warn` in Kubernetes v1.23.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-changed-k8s-1.23.json"},{"id":"field-validation-default-changed-k8s-v123","text":"Kubernetes `fieldValidation` parameter default changed from `Ignore` (pre-v1.23) to `Warn` (v1.23+); `Strict` rejects unknown or duplicate fields","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-changed-k8s-v123.json"},{"id":"field-validation-default-changed-v123","text":"The `fieldValidation` parameter default changed at Kubernetes v1.23: prior to v1.23 it defaults to `Ignore`, v1.23+ defaults to `Warn`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-changed-v123.json"},{"id":"field-validation-default-warn-since-k8s-123","text":"The `fieldValidation` parameter default changed at Kubernetes v1.23: before v1.23 it was `Ignore`, from v1.23+ it is `Warn`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-warn-since-k8s-123.json"},{"id":"field-validation-default-warn-since-v1-23","text":"The `fieldValidation` default changed from `Ignore` (pre-v1.23) to `Warn` (v1.23+) for Kubernetes API requests.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-warn-since-v1-23.json"},{"id":"field-validation-default-warn-since-v123","text":"The `fieldValidation` parameter default changed at Kubernetes v1.23 from `Ignore` to `Warn`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-warn-since-v123.json"},{"id":"field-validation-default-warn-v123","text":"The `fieldValidation` query parameter defaults to `Ignore` before Kubernetes v1.23 and `Warn` in v1.23+; `Strict` rejects requests with unknown or duplicate fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-default-warn-v123.json"},{"id":"field-validation-defaults","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-defaults.json"},{"id":"field-validation-strict-rejects-unknown","text":"The `fieldValidation=Strict` query parameter on OpenShift/Kubernetes API requests rejects requests containing unknown or duplicate fields; default changed to `Warn` in v1.23+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-strict-rejects-unknown.json"},{"id":"field-validation-strict-rejects-unknown-fields","text":"Setting `fieldValidation=Strict` on API requests rejects requests with unknown or duplicate fields; default since v1.23 is `Warn`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/field-validation-strict-rejects-unknown-fields.json"},{"id":"fieldvalidation-default-changed-k8s-123","text":"The `fieldValidation` query parameter default changed at Kubernetes v1.23 from `Ignore` to `Warn`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fieldvalidation-default-changed-k8s-123.json"},{"id":"fieldvalidation-default-warn-since-v123","text":"The `fieldValidation` parameter defaults to `Ignore` prior to Kubernetes v1.23 and `Warn` in v1.23+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fieldvalidation-default-warn-since-v123.json"},{"id":"fieldvalidation-default-warn-v123","text":"The `fieldValidation` query parameter defaults to `Warn` in Kubernetes v1.23+, replacing the previous `Ignore` default; `Strict` rejects requests with unknown or duplicate fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fieldvalidation-default-warn-v123.json"},{"id":"fieldvalidation-three-modes","text":"Kubernetes API `fieldValidation` query parameter supports three modes: `Ignore` (pre-v1.23 default), `Warn` (v1.23+ default), and `Strict` (rejects unknown/duplicate fields).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fieldvalidation-three-modes.json"},{"id":"file-based-catalogs-replace-sqlite","text":"File-based catalogs (FBC) using JSON/YAML format replace the deprecated SQLite catalog format; built with `opm render`, `opm validate`, and `opm init`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/file-based-catalogs-replace-sqlite.json"},{"id":"filesystem-resize-requires-pod-restart","text":"File-system-based volume expansion (EBS, GCE, Cinder) requires a pod restart to complete the filesystem resize on the node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/filesystem-resize-requires-pod-restart.json"},{"id":"filesystemresizepending-condition","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/filesystemresizepending-condition.json"},{"id":"fio-default-alert-nodehasintegrityfailure","text":"The File Integrity Operator ships a default PrometheusRule alert `NodeHasIntegrityFailure` that fires a warning after 1 second of integrity failure on a node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-default-alert-nodehasintegrityfailure.json"},{"id":"fio-maxbackups-default-5","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-maxbackups-default-5.json"},{"id":"fio-namespace-openshift-file-integrity","text":"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+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-namespace-openshift-file-integrity.json"},{"id":"fio-not-supported-hcp","text":"The File Integrity Operator is not supported on Hosted Control Planes (HCP) clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-not-supported-hcp.json"},{"id":"fio-reinit-failed-annotation","text":"The annotation `file-integrity.openshift.io/re-init-on-failed=` on a FileIntegrity CR reinitializes the AIDE database baseline on only failed nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-reinit-failed-annotation.json"},{"id":"fio-uses-aide-daemonset","text":"The File Integrity Operator uses AIDE (Advanced Intrusion Detection Environment) deployed as a DaemonSet running privileged containers on each matching node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fio-uses-aide-daemonset.json"},{"id":"fips-enforcement-spans-install-runtime-and-architecture","text":"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)","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fips-enforcement-spans-install-runtime-and-architecture.json"},{"id":"fips-mode-requires-fips-rhel-host","text":"Enabling FIPS mode for OpenShift installation requires running the installer from a RHEL machine already in FIPS mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fips-mode-requires-fips-rhel-host.json"},{"id":"fips-requires-fips-enabled-rhel","text":"FIPS mode for OCP installation requires the installer to run from a FIPS-enabled RHEL machine.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fips-requires-fips-enabled-rhel.json"},{"id":"fips-supported-x86-ppc64le-s390x","text":"FIPS 140-2/140-3 validation applies to `x86_64`, `ppc64le`, and `s390x` architectures, and must be installed from a FIPS-enabled RHEL machine.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fips-supported-x86-ppc64le-s390x.json"},{"id":"firmwareschema-defines-bios-constraints","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/firmwareschema-defines-bios-constraints.json"},{"id":"firmwareschema-only-required-field-schema","text":"The only required field in FirmwareSchema `.spec` is `schema`, which maps firmware setting names to their schema definitions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/firmwareschema-only-required-field-schema.json"},{"id":"flexvolume-not-on-control-plane","text":"FlexVolume plugins are not supported on control plane nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flexvolume-not-on-control-plane.json"},{"id":"flowcollector-default-sampling-50","text":"Default eBPF sampling rate is 50 (1-in-50 flows captured); value of 0 or 1 captures all flows","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-default-sampling-50.json"},{"id":"flowcollector-deployment-models","text":"FlowCollector supports two deployment models: `Service` (direct, default) and `Kafka` (high-throughput/low-latency)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-deployment-models.json"},{"id":"flowcollector-ebpf-only-agent","text":"eBPF is the only supported agent type for flow collection in the Network Observability Operator (`spec.agent.type: EBPF`)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-ebpf-only-agent.json"},{"id":"flowcollector-exporters-types","text":"FlowCollector exporters support Kafka, IPFIX, and OpenTelemetry simultaneously for enriched flow data export","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-exporters-types.json"},{"id":"flowcollector-kafka-tls-both-namespaces","text":"Kafka TLS certificates must be available in both `netobserv` (processor) and `netobserv-privileged` (eBPF agents) namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-kafka-tls-both-namespaces.json"},{"id":"flowcollector-must-be-named-cluster","text":"The FlowCollector custom resource must be named `cluster` and only one instance is allowed per cluster","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-must-be-named-cluster.json"},{"id":"flowcollector-name-always-cluster","text":"The FlowCollector custom resource is always named `cluster` and lives in the `netobserv` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-name-always-cluster.json"},{"id":"flowcollector-quick-filter-negation","text":"FlowCollector quick filter negation uses `!` appended to the key name (e.g., `src_namespace!`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-quick-filter-negation.json"},{"id":"flowcollector-singleton-named-cluster","text":"The FlowCollector custom resource is a singleton that must be named `cluster`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-singleton-named-cluster.json"},{"id":"flowcollector-without-loki-savings","text":"Running Network Observability without Loki saves 20–65% memory and 10–30% CPU by relying on Prometheus only","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowcollector-without-loki-savings.json"},{"id":"flowdirection-values","text":"FlowDirection field values: 0=Ingress, 1=Egress, 2=Inner (same source and destination node)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowdirection-values.json"},{"id":"flowmetric-api-group","text":"The FlowMetric custom resource uses API group `flows.netobserv.io/v1alpha1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-api-group.json"},{"id":"flowmetric-empty-valuefield-counts-flows","text":"When FlowMetric `valueField` is left empty, the metric counts flows rather than summing a specific field value","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-empty-valuefield-counts-flows.json"},{"id":"flowmetric-namespace-requirement","text":"FlowMetric resources must be created in the namespace defined in FlowCollector `spec.namespace` (default: `netobserv`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-namespace-requirement.json"},{"id":"flowmetric-netobserv-prefix","text":"FlowMetric-generated metrics are automatically prefixed with `netobserv_` in Prometheus","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-netobserv-prefix.json"},{"id":"flowmetric-ownername-over-name","text":"FlowMetric labels should prefer `SrcK8S_OwnerName`/`DstK8S_OwnerName` over `SrcK8S_Name`/`DstK8S_Name` to reduce Prometheus cardinality","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-ownername-over-name.json"},{"id":"flowmetric-three-metric-types","text":"FlowMetric supports three metric types: Counter (rates), Histogram (sampled values like latencies), and Gauge (point-in-time values)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowmetric-three-metric-types.json"},{"id":"flowschema-api-group","text":"FlowSchema belongs to API group `flowcontrol.apiserver.k8s.io/v1` and is a cluster-scoped resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-api-group.json"},{"id":"flowschema-distinguisher-types","text":"FlowSchema distinguisher method type is either `ByUser` or `ByNamespace`, determining how flows within the schema are separated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-distinguisher-types.json"},{"id":"flowschema-matching-precedence-default","text":"FlowSchema `matchingPrecedence` defaults to 1000 with valid range [1, 10000]; lower numeric value means higher logical priority (matched first).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-matching-precedence-default.json"},{"id":"flowschema-prioritylevel-apf-system","text":"FlowSchema and PriorityLevelConfiguration work together as the API Priority and Fairness (APF) system, which replaced max-in-flight request handling for the API server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-prioritylevel-apf-system.json"},{"id":"flowschema-prioritylevel-required","text":"`priorityLevelConfiguration` is the only required field in FlowSchema `.spec`, referencing the PriorityLevelConfiguration that controls queuing and concurrency limits for matched requests.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-prioritylevel-required.json"},{"id":"flowschema-rule-matching-logic","text":"A FlowSchema rule matches a request only if both a subject matches (User, Group, or ServiceAccount) and a resource or non-resource rule matches.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/flowschema-rule-matching-logic.json"},{"id":"force-redeployment-requires-unique-string","text":"The `forceRedeploymentReason` field requires a unique string each time to trigger a new static pod rollout","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/force-redeployment-requires-unique-string.json"},{"id":"forward-compatibility-only","text":"OCP provides forward compatibility only — applications built for 4.14 are not guaranteed to work on 4.13.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/forward-compatibility-only.json"},{"id":"fsgroup-changes-ownership-sets-setgid","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/fsgroup-changes-ownership-sets-setgid.json"},{"id":"gce-pd-max-128-per-node","text":"GCE Persistent Disk supports a maximum of 128 PDs per node (127 usable, 1 reserved for root).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gce-pd-max-128-per-node.json"},{"id":"gce-pd-types","text":"GCE Persistent Disk provisioner types are `pd-standard` (default) and `pd-ssd`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gce-pd-types.json"},{"id":"gcp-kms-key-location-defaults-global","text":"GCP KMS key `location` in ClusterCSIDriver defaults to `\"global\"` if not set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gcp-kms-key-location-defaults-global.json"},{"id":"generation-zero-forces-reimport","text":"Setting the generation field to 0 on an image stream tag resets it to the latest stream generation, triggering a fresh re-import","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generation-zero-forces-reimport.json"},{"id":"generic-ephemeral-indirect-pvc-creation-security","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-indirect-pvc-creation-security.json"},{"id":"generic-ephemeral-no-offline-snapshot-resize","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-no-offline-snapshot-resize.json"},{"id":"generic-ephemeral-pod-owns-pvc","text":"The pod is the owner of auto-created ephemeral volume PVCs; Kubernetes garbage collector handles cleanup when the pod is deleted.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-pod-owns-pvc.json"},{"id":"generic-ephemeral-pvc-naming-convention","text":"Generic ephemeral volume PVCs are named `<pod-name>-<volume-name>`; naming collisions in the same namespace can prevent pods from starting.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-pvc-naming-convention.json"},{"id":"generic-ephemeral-volumes-defined-inline-pod-spec","text":"Generic ephemeral volumes are defined under `volumes[].ephemeral.volumeClaimTemplate` in the pod spec and follow the pod lifecycle (created/deleted with the pod).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-volumes-defined-inline-pod-spec.json"},{"id":"generic-ephemeral-waitforfirstconsumer-recommended","text":"`WaitForFirstConsumer` volume binding mode is recommended for generic ephemeral volumes so the scheduler can pick an appropriate node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/generic-ephemeral-waitforfirstconsumer-recommended.json"},{"id":"get-infrastructure-id-command","text":"The command to retrieve the cluster infrastructure ID is `oc get -o jsonpath='{.status.infrastructureName}{\"\\n\"}' infrastructure cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/get-infrastructure-id-command.json"},{"id":"gitops-agent-multi-cluster","text":"The Argo CD Agent architecture enables agent-based GitOps communication between a control plane and remote workload clusters for multi-cluster synchronization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-agent-multi-cluster.json"},{"id":"gitops-applicationsets-non-control-plane-ns","text":"ApplicationSets can be managed in non-control-plane namespaces in OpenShift GitOps.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-applicationsets-non-control-plane-ns.json"},{"id":"gitops-argo-rollouts-progressive-delivery","text":"Argo Rollouts provides progressive delivery (canary, blue-green deployments) integrated into the OpenShift GitOps workflow.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-argo-rollouts-progressive-delivery.json"},{"id":"gitops-based-on-argocd","text":"Red Hat OpenShift GitOps is built on Argo CD and installed as an Operator via OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-based-on-argocd.json"},{"id":"gitops-cli-is-argocd-binary","text":"The GitOps CLI tool for OpenShift is the `argocd` binary, not a separate Red Hat-specific binary.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-cli-is-argocd-binary.json"},{"id":"gitops-git-single-source-of-truth","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-git-single-source-of-truth.json"},{"id":"gitops-handles-cd-pipelines-handles-ci","text":"OpenShift GitOps (Argo CD) handles continuous deployment (CD), while OpenShift Pipelines (Tekton) handles continuous integration (CI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-handles-cd-pipelines-handles-ci.json"},{"id":"gitops-infra-node-support","text":"OpenShift GitOps control plane workloads can run on infrastructure nodes, avoiding worker entitlement consumption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-infra-node-support.json"},{"id":"gitops-installed-via-operatorhub","text":"OpenShift GitOps is installed via OperatorHub as an Operator managed by OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-installed-via-operatorhub.json"},{"id":"gitops-multicluster-declarative-cd","text":"OpenShift GitOps supports multicluster declarative continuous deployment across OpenShift and Kubernetes clusters, managing both infrastructure and application configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-multicluster-declarative-cd.json"},{"id":"gitops-multicluster-support","text":"OpenShift GitOps supports multicluster OpenShift and Kubernetes infrastructure management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-multicluster-support.json"},{"id":"gitops-not-builtin-requires-install","text":"OpenShift GitOps is an Operator that must be installed separately — it is not a built-in platform component.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-not-builtin-requires-install.json"},{"id":"gitops-operator-built-on-argocd","text":"OpenShift GitOps is an Operator built on Argo CD that provides declarative GitOps workflows for Kubernetes-based infrastructure and applications.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-operator-built-on-argocd.json"},{"id":"gitops-separate-release-cadence","text":"OpenShift GitOps releases on a different cadence from OpenShift Container Platform itself.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-separate-release-cadence.json"},{"id":"gitops-three-app-creation-methods","text":"Argo CD applications can be created via the Argo CD dashboard, the `oc` CLI, or the `argocd` GitOps CLI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-three-app-creation-methods.json"},{"id":"gitops-ztp-primary-mechanism-edge","text":"GitOps ZTP is the Red Hat-recommended approach for provisioning and managing edge clusters at scale in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-ztp-primary-mechanism-edge.json"},{"id":"gitops-ztp-updated-independently","text":"GitOps ZTP can be updated independently from the hub cluster, RHACM, and managed OpenShift clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gitops-ztp-updated-independently.json"},{"id":"governance-controls-image-supply-chain","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/governance-controls-image-supply-chain.json"},{"id":"governance-spans-identity-resources-and-namespaces","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/governance-spans-identity-resources-and-namespaces.json"},{"id":"governed-immutable-image-and-operator-platform","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/governed-immutable-image-and-operator-platform.json"},{"id":"governed-supply-chains-operational-across-topologies","text":"The governed image and operator supply chains (build→ImageStream→registry for apps, FBC→OLM→CSV for operators) are fully operational across all topology variants (standalone, HCP, SNO) only when the next-generation operator delivery mechanism reaches GA and supports disconnected registries","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/governed-supply-chains-operational-across-topologies.json"},{"id":"gpu-operator-required-for-gpu-support","text":"GPU support in OpenShift requires installing a GPU Operator; it is not built into the platform by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gpu-operator-required-for-gpu-support.json"},{"id":"gpu-operators-installed-via-olm","text":"GPU Operators are installed via the Operator Lifecycle Manager (OLM).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gpu-operators-installed-via-olm.json"},{"id":"gpu-scheduling-resource-name","text":"GPU workloads use extended resource requests (e.g., `nvidia.com/gpu`) for pod scheduling to GPU-equipped nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gpu-scheduling-resource-name.json"},{"id":"gpu-support-via-operators","text":"GPU support in OpenShift is delivered through Operators (e.g., NVIDIA GPU Operator), not manual driver installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/gpu-support-via-operators.json"},{"id":"graceful-restart-order-control-plane-first","text":"During a graceful cluster restart, control plane nodes must come up first, then worker nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/graceful-restart-order-control-plane-first.json"},{"id":"group-api-user-openshift-io-v1","text":"The Group resource (`user.openshift.io/v1`) is a cluster-scoped OpenShift-specific resource; its only required field is `users` (string array of usernames).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/group-api-user-openshift-io-v1.json"},{"id":"groups-recommended-over-individual-bindings","text":"Groups are the recommended way to manage access at scale rather than binding roles to individual users.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/groups-recommended-over-individual-bindings.json"},{"id":"hardware-accelerators-scoped-to-openshift-ai","text":"Hardware accelerators documentation in OpenShift is specifically scoped to AI/ML use cases via Red Hat OpenShift AI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardware-accelerators-scoped-to-openshift-ai.json"},{"id":"hardware-enablement-via-nfd-kmm-operators","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardware-enablement-via-nfd-kmm-operators.json"},{"id":"hardware-networks-are-secondary-networks","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardware-networks-are-secondary-networks.json"},{"id":"hardware-networks-are-secondary-not-primary","text":"Hardware networks (SR-IOV) are configured as additional (secondary) pod networks via Multus NetworkAttachmentDefinitions, not as the primary cluster network.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardware-networks-are-secondary-not-primary.json"},{"id":"hardwaredata-api-group-metal3io-v1alpha1","text":"HardwareData is a custom resource under the `metal3.io/v1alpha1` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-api-group-metal3io-v1alpha1.json"},{"id":"hardwaredata-created-by-host-inspection","text":"HardwareData is created automatically as a result of bare-metal host inspection (introspection), not manually by users in typical workflows","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-created-by-host-inspection.json"},{"id":"hardwaredata-dual-stack-nic-separate-entries","text":"In dual-stack environments, NIC entries in HardwareData produce separate entries per IP address (one per IP family)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-dual-stack-nic-separate-entries.json"},{"id":"hardwaredata-is-namespaced","text":"HardwareData is a namespaced resource, not cluster-scoped","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-is-namespaced.json"},{"id":"hardwaredata-ram-mebibytes-cpu-mhz-nic-gbps","text":"HardwareData measures RAM in mebibytes (MiB), CPU clock speed in megahertz (MHz), and NIC speed in gigabits per second (Gbps)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-ram-mebibytes-cpu-mhz-nic-gbps.json"},{"id":"hardwaredata-storage-type-hdd-ssd-nvme","text":"HardwareData storage `type` field values are HDD, SSD, and NVME; the `rotational` boolean is deprecated in favor of `type`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hardwaredata-storage-type-hdd-ssd-nvme.json"},{"id":"hcp-adding-idp-removes-kubeadmin","text":"Adding any identity provider to a hosted cluster's OAuth configuration removes the default kubeadmin user provider.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-adding-idp-removes-kubeadmin.json"},{"id":"hcp-api-resources-hostedcluster-nodepool","text":"HCP uses `HostedCluster` and `NodePool` API resources from the `hypershift.openshift.io` API group (not `openshift-install`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-api-resources-hostedcluster-nodepool.json"},{"id":"hcp-auto-import-default","text":"Hosted clusters are automatically imported into the local multicluster engine Operator when the hosted control plane becomes available — this is the default behavior.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-auto-import-default.json"},{"id":"hcp-aws-destroy-five-params","text":"AWS hosted cluster destruction requires five parameters: `--name`, `--infra-id`, `--role-arn`, `--sts-creds`, `--base-domain`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-aws-destroy-five-params.json"},{"id":"hcp-aws-etcd-snapshot-requires-api-downtime","text":"On AWS, taking an etcd snapshot requires API downtime — kube-apiserver, openshift-apiserver, and openshift-oauth-apiserver must be scaled to 0 replicas first","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-aws-etcd-snapshot-requires-api-downtime.json"},{"id":"hcp-aws-kubevirt-delete-managedcluster-first","text":"On AWS and OpenShift Virtualization, the managed cluster resource must be deleted (`oc delete managedcluster`) before destroying the hosted cluster","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-aws-kubevirt-delete-managedcluster-first.json"},{"id":"hcp-bare-metal-manual-cleanup-without-render","text":"Bare metal hosted clusters created without `--render`/`--render-sensitive` flags require manual backend resource cleanup during destruction","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-bare-metal-manual-cleanup-without-render.json"},{"id":"hcp-cco-manual-mode-only-aws","text":"The Cloud Credential Operator (CCO) for hosted clusters on AWS supports manual mode only — this is the default and only supported mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-cco-manual-mode-only-aws.json"},{"id":"hcp-cco-sts-operator-annotation","text":"Operators declare support for CCO/STS in hosted control planes with the CSV annotation features.operators.openshift.io/token-auth-aws: \"true\".","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-cco-sts-operator-annotation.json"},{"id":"hcp-cluster-name-unique-clusters-reserved","text":"Hosted cluster names must be unique cluster-wide; the name `clusters` is reserved and cannot be used","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-cluster-name-unique-clusters-reserved.json"},{"id":"hcp-clusterversion-ignored","text":"`ClusterVersion` resource changes are ignored in hosted clusters — updates are driven through `HostedCluster` and `NodePool` `.spec.release.image`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-clusterversion-ignored.json"},{"id":"hcp-control-plane-namespace-pattern","text":"The hosted control plane namespace follows the pattern `${HOSTED_CLUSTER_NAMESPACE}-${CLUSTER_NAME}` (e.g., `clusters-my-cluster`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-control-plane-namespace-pattern.json"},{"id":"hcp-control-plane-node-updates-independent","text":"In hosted control planes, control plane and node pool updates are independent — unlike standalone OCP where they are coupled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-control-plane-node-updates-independent.json"},{"id":"hcp-control-plane-on-mgmt-data-plane-on-workers","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-control-plane-on-mgmt-data-plane-on-workers.json"},{"id":"hcp-control-plane-runs-as-pods","text":"Hosted control planes run control plane components (etcd, API server, controller manager, VPN) as pods on a management cluster, not on dedicated machines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-control-plane-runs-as-pods.json"},{"id":"hcp-control-plane-update-two-steps","text":"Updating a hosted control plane requires two steps: (1) annotate HostedCluster with `hypershift.openshift.io/force-upgrade-to`, (2) patch `spec.release.image`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-control-plane-update-two-steps.json"},{"id":"hcp-create-cluster-platforms","text":"The `hcp create cluster` command supports three platforms: aws, agent, and kubevirt.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-create-cluster-platforms.json"},{"id":"hcp-custom-cert-path-named-certificates","text":"Custom API server certificates for hosted control planes are configured at spec.configuration.apiServer.servingCerts.namedCertificates in the HostedCluster resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-custom-cert-path-named-certificates.json"},{"id":"hcp-custom-kubeconfig-secret-naming","text":"When kubeAPIServerDNSName is set on a HostedCluster, the HyperShift Operator generates a custom kubeconfig secret named `<cluster_name>-custom-admin-kubeconfig`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-custom-kubeconfig-secret-naming.json"},{"id":"hcp-decouples-control-plane-data-plane","text":"Hosted control planes decouple the control plane from the data plane — the hosting cluster runs control plane pods while worker nodes run separately.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-decouples-control-plane-data-plane.json"},{"id":"hcp-decouples-control-plane-from-data-plane","text":"Hosted control planes decouple the control plane from the data plane — the control plane runs on the management cluster while worker nodes run separately.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-decouples-control-plane-from-data-plane.json"},{"id":"hcp-default-cidr-ranges","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-default-cidr-ranges.json"},{"id":"hcp-default-metrics-set-telemetry","text":"The default metrics set for hosted control planes is Telemetry (the smallest set).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-default-metrics-set-telemetry.json"},{"id":"hcp-default-namespace-clusters","text":"The default namespace for hosted clusters is `clusters`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-default-namespace-clusters.json"},{"id":"hcp-default-tuned-profile-openshift-node","text":"The default TuneD profile in HCP is `openshift-node` when no custom profiles are defined","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-default-tuned-profile-openshift-node.json"},{"id":"hcp-destroy-subcommand-per-platform","text":"The `hcp destroy cluster` subcommand varies by platform: `aws`, `kubevirt`, or `agent`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-destroy-subcommand-per-platform.json"},{"id":"hcp-differs-from-standalone-in-machine-management","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-differs-from-standalone-in-machine-management.json"},{"id":"hcp-disable-auto-import-config","text":"Disabling auto-import of hosted clusters uses `autoImportDisabled: \"true\"` in the `hypershift-addon-deploy-config` AddonDeploymentConfig in the `multicluster-engine` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-disable-auto-import-config.json"},{"id":"hcp-disconnected-rhcos-manual-mirror","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-disconnected-rhcos-manual-mirror.json"},{"id":"hcp-diverges-from-standalone-machine-and-provisioning","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-diverges-from-standalone-machine-and-provisioning.json"},{"id":"hcp-dual-stack-disconnected-tech-preview","text":"Dual-stack networking for hosted control planes in disconnected environments is Technology Preview only — not supported for production","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-dual-stack-disconnected-tech-preview.json"},{"id":"hcp-enabled-by-default-in-mce","text":"Hosted control planes (HCP) is enabled by default in the multicluster engine Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-enabled-by-default-in-mce.json"},{"id":"hcp-encryption-key-saved-separately-for-dr","text":"The secret encryption key (`spec.secretEncryption.aescbc`) must be saved separately from the etcd snapshot for disaster recovery to a new cluster","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-encryption-key-saved-separately-for-dr.json"},{"id":"hcp-etcd-encryption-secretencryption-field","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-etcd-encryption-secretencryption-field.json"},{"id":"hcp-etcd-runs-as-3-member-statefulset","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-etcd-runs-as-3-member-statefulset.json"},{"id":"hcp-etcd-runs-as-pod-on-management-cluster","text":"Each hosted cluster's etcd runs as a pod on the management cluster rather than on dedicated control plane nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-etcd-runs-as-pod-on-management-cluster.json"},{"id":"hcp-etcd-uses-pvcs","text":"In hosted control planes, etcd uses Persistent Volume Claims for storage (not local node storage) and is managed by the Control Plane Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-etcd-uses-pvcs.json"},{"id":"hcp-etcdutl-not-etcdctl-for-restore","text":"`etcdutl snapshot restore` (not `etcdctl`) is used for restoring etcd snapshots in HCP, with `--skip-hash-check`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-etcdutl-not-etcdctl-for-restore.json"},{"id":"hcp-featuregate-path-spec-configuration","text":"Feature gates on hosted clusters are configured at `spec.configuration.featureGate.featureSet` in the HostedCluster CR on the management cluster","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-featuregate-path-spec-configuration.json"},{"id":"hcp-featuregate-set-on-mgmt-cluster-cr","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-featuregate-set-on-mgmt-cluster-cr.json"},{"id":"hcp-force-rollout-restart-date-annotation","text":"After etcd restore, a manual rollout is triggered using the `hypershift.openshift.io/restart-date` annotation on the HostedCluster resource","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-force-rollout-restart-date-annotation.json"},{"id":"hcp-ha-control-plane-resource-requirements","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-ha-control-plane-resource-requirements.json"},{"id":"hcp-hostedcluster-api-group-hypershift-v1beta1","text":"The HostedCluster CR uses the API group `hypershift.openshift.io/v1beta1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-hostedcluster-api-group-hypershift-v1beta1.json"},{"id":"hcp-htpasswd-request-header-no-nodepool-required","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-htpasswd-request-header-no-nodepool-required.json"},{"id":"hcp-hypershift-operator-in-mce","text":"The HyperShift Operator is included in the multicluster engine (MCE) for Kubernetes Operator; MCE is installed with RHACM or standalone from OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-hypershift-operator-in-mce.json"},{"id":"hcp-ibm-power-cluster-grace-period","text":"The `--cluster-grace-period` flag is used with `hcp destroy cluster agent` on IBM Power to specify destruction timeout","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-ibm-power-cluster-grace-period.json"},{"id":"hcp-ibmz-kvm-auto-detach-zvm-lpar-manual","text":"On IBM Z, scaling NodePool to 0 auto-detaches compute nodes only with KVM; z/VM and LPAR require manual compute node deletion","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-ibmz-kvm-auto-detach-zvm-lpar-manual.json"},{"id":"hcp-icsp-idms-restarts-kubelet-not-node","text":"Applying ICSP/IDMS triggers a MachineConfig change that restarts kubelet (not the entire node) on each node","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-icsp-idms-restarts-kubelet-not-node.json"},{"id":"hcp-idms-icsp-mgmt-imagecontentsource-hosted","text":"IDMS/ICSP applies to the management cluster; ImageContentSource in the hosted cluster spec is translated to IDMS on the hosted cluster","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-idms-icsp-mgmt-imagecontentsource-hosted.json"},{"id":"hcp-ignition-version-3-2-0","text":"MachineConfig objects in HCP use Ignition version 3.2.0","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-ignition-version-3-2-0.json"},{"id":"hcp-integrates-with-acm-mce","text":"Hosted control planes integrate with Red Hat Advanced Cluster Management (ACM) / Multicluster Engine (MCE) for lifecycle management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-integrates-with-acm-mce.json"},{"id":"hcp-klusterlet-deploy-mode-hosted-annotation","text":"The annotation `import.open-cluster-management.io/klusterlet-deploy-mode: Hosted` is required when manually importing a hosted cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-klusterlet-deploy-mode-hosted-annotation.json"},{"id":"hcp-klusterletaddonconfig-rhacm-only","text":"`KlusterletAddonConfig` is only needed when RHACM is installed, not for MCE-only deployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-klusterletaddonconfig-rhacm-only.json"},{"id":"hcp-konnectivity-api-server-to-node","text":"In HCP, API server-to-node communication uses Konnectivity (not direct communication), since control plane and workers are in different VPCs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-konnectivity-api-server-to-node.json"},{"id":"hcp-kubevirt-container-oc-mirror-v2-only","text":"The `kubeVirtContainer: true` flag in ImageSetConfiguration mirrors the RHCOS boot container disk image and is available only in oc-mirror v2","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-kubevirt-container-oc-mirror-v2-only.json"},{"id":"hcp-kubevirt-ingress-dns-pattern","text":"Default ingress DNS for KubeVirt hosted clusters follows the pattern `*.apps.<hosted_cluster_name>.apps.<mgmt_cluster_domain>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-kubevirt-ingress-dns-pattern.json"},{"id":"hcp-kubevirt-ingress-https-only-port-443","text":"Default hosted cluster ingress for KubeVirt only supports HTTPS on port 443; plain HTTP on port 80 is rejected","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-kubevirt-ingress-https-only-port-443.json"},{"id":"hcp-kubevirt-provision-time-10-15-min","text":"A KubeVirt hosted cluster typically takes 10–15 minutes to fully provision","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-kubevirt-provision-time-10-15-min.json"},{"id":"hcp-kubevirt-requires-bare-metal-mgmt","text":"KubeVirt-based hosted control planes require the management cluster to run on bare metal","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-kubevirt-requires-bare-metal-mgmt.json"},{"id":"hcp-machineconfig-wrapped-in-configmap","text":"Machine configuration objects (MachineConfig, KubeletConfig, Tuned) must be embedded inside a ConfigMap in the management cluster's `clusters` namespace to be applied in HCP","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-machineconfig-wrapped-in-configmap.json"},{"id":"hcp-managed-via-hypershift-operator","text":"Hosted control planes are powered by the HyperShift operator and managed via the `hcp` CLI and CRDs (HostedCluster, NodePool).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-managed-via-hypershift-operator.json"},{"id":"hcp-management-cluster-min-3-workers","text":"A hosted control planes management cluster requires at least 3 worker nodes; single-node OpenShift is not supported as a management cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-management-cluster-min-3-workers.json"},{"id":"hcp-management-cluster-version-support-n-minus-3","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-management-cluster-version-support-n-minus-3.json"},{"id":"hcp-max-latency-200ms","text":"Maximum supported latency between a management cluster and hosted clusters is 200 ms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-max-latency-200ms.json"},{"id":"hcp-maxpods-density-tuning","text":"Default `maxPods` of 250 allows ~3 hosted control planes per node; increasing to 500 via KubeletConfig allows more density.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-maxpods-density-tuning.json"},{"id":"hcp-mce-minor-upgrade-updates-hypershift-patch-does-not","text":"Upgrading MCE minor version updates the HyperShift Operator; upgrading MCE patch/z-stream does not update HyperShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-mce-minor-upgrade-updates-hypershift-patch-does-not.json"},{"id":"hcp-mce-supports-n-plus-1-to-n-minus-2","text":"The multicluster engine Operator manages hosted clusters from `n+1` to `n-2` OCP versions where `n` is the current minor version.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-mce-supports-n-plus-1-to-n-minus-2.json"},{"id":"hcp-metrics-set-env-var","text":"The metrics set is configured via the `METRICS_SET` environment variable on the HyperShift Operator deployment in the `hypershift` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-metrics-set-env-var.json"},{"id":"hcp-mgmt-failure-impact-workloads-continue","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-mgmt-failure-impact-workloads-continue.json"},{"id":"hcp-mixed-infra-requires-publicandprivate","text":"Mixed infrastructure hosted control planes (e.g., management on AWS, workers on-premise) require the `PublicAndPrivate` publishing strategy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-mixed-infra-requires-publicandprivate.json"},{"id":"hcp-monitoring-dashboards-configmap-naming","text":"HCP monitoring dashboard ConfigMaps are created in `openshift-config-managed` namespace with naming pattern `cp-<namespace>-<name>`, and deleting a hosted cluster automatically deletes its dashboard.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-monitoring-dashboards-configmap-naming.json"},{"id":"hcp-monitoring-dashboards-install-flags","text":"Monitoring dashboards are enabled via the `hypershift-operator-install-flags` ConfigMap in the `local-cluster` namespace with `--monitoring-dashboards` flag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-monitoring-dashboards-install-flags.json"},{"id":"hcp-must-gather-image-from-mce","text":"The must-gather image for hosted control planes is `registry.redhat.io/multicluster-engine/must-gather-rhel9:v<mce_version>`, not the standard OCP must-gather image.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-must-gather-image-from-mce.json"},{"id":"hcp-no-machine-config-operator","text":"The Machine Config Operator does not exist in hosted control planes; machine configuration is applied via ConfigMap referenced in NodePool's `spec.config`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-no-machine-config-operator.json"},{"id":"hcp-no-machineconfigpool-uses-nodepool","text":"In hosted control planes, `MachineConfigPool` does not exist; `NodePool` is used instead for managing node configuration","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-no-machineconfigpool-uses-nodepool.json"},{"id":"hcp-node-labels-lost-on-upgrade-unless-inplace","text":"In HCP, node labels do not persist during upgrades unless `spec.management.upgradeType` is set to `InPlace` on the NodePool","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-node-labels-lost-on-upgrade-unless-inplace.json"},{"id":"hcp-nodehealthcheck-must-pause-before-update","text":"NodeHealthCheck remediation must be manually paused (via `pauseRequests` field) before updating hosted clusters because it cannot detect CVO status in hosted control planes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodehealthcheck-must-pause-before-update.json"},{"id":"hcp-nodepool-autorepair-spec","text":"Machine health checks in HCP use `.spec.management.autoRepair` on NodePool (not MachineHealthCheck resource).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-autorepair-spec.json"},{"id":"hcp-nodepool-autoscaling-spec","text":"Autoscaling in HCP is configured via `spec.autoScaling` on NodePool (not ClusterAutoscaler/MachineAutoscaler).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-autoscaling-spec.json"},{"id":"hcp-nodepool-replaces-machinesets-autoscaler-healthcheck","text":"NodePool replaces MachineSets, MachineAutoscaler, MachineHealthCheck, and MachineConfigPool concepts from standalone OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-replaces-machinesets-autoscaler-healthcheck.json"},{"id":"hcp-nodepool-spec-config-vs-tuningconfig","text":"NodePool `spec.config` references ConfigMaps containing MachineConfig/KubeletConfig; `spec.tuningConfig` references ConfigMaps containing Tuned objects — these are separate fields","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-spec-config-vs-tuningconfig.json"},{"id":"hcp-nodepool-upgrade-types-replace-inplace","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-upgrade-types-replace-inplace.json"},{"id":"hcp-nodepool-version-cannot-exceed-control-plane","text":"Node pool version must not surpass the hosted control plane version per Kubernetes version skew policy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-nodepool-version-cannot-exceed-control-plane.json"},{"id":"hcp-oauth-configured-in-hostedcluster-cr","text":"OAuth for hosted clusters is configured in spec.configuration.oauth of the HostedCluster CR, not in a separate OAuth CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-oauth-configured-in-hostedcluster-cr.json"},{"id":"hcp-olm-management-mode-no-icsp-overrides","text":"When OLM catalogs use `management` (default) placement mode, ICSP overrides are not automatically applied to the OLM catalog image stream — requires manual annotation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-olm-management-mode-no-icsp-overrides.json"},{"id":"hcp-pause-reconciliation-for-backup-restore","text":"Before performing etcd backup/restore operations on a hosted cluster, reconciliation must be paused with `spec.pausedUntil: \"true\"` and resumed afterward with `\"null\"`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-pause-reconciliation-for-backup-restore.json"},{"id":"hcp-registry-ca-two-places","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-registry-ca-two-places.json"},{"id":"hcp-remote-hub-updates-local-mce-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-remote-hub-updates-local-mce-only.json"},{"id":"hcp-replace-and-inplace-upgrades","text":"HCP supports both replace and in-place upgrade types for node pools; standalone OCP supports only in-place.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-replace-and-inplace-upgrades.json"},{"id":"hcp-requires-distinct-operational-playbook","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-requires-distinct-operational-playbook.json"},{"id":"hcp-requires-multicluster-engine-not-rhacm","text":"Hosted control planes require multicluster engine for Kubernetes Operator; RHACM is optional and not required.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-requires-multicluster-engine-not-rhacm.json"},{"id":"hcp-restart-via-annotation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-restart-via-annotation.json"},{"id":"hcp-san-no-conflict-with-api-int","text":"Custom API server certificate SANs must not conflict with the internal API endpoint (api-int), except on AWS with Private or PublicAndPrivate publishing strategies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-san-no-conflict-with-api-int.json"},{"id":"hcp-service-publishing-strategy-immutable","text":"The service publishing strategy for hosted control planes is immutable after cluster creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-service-publishing-strategy-immutable.json"},{"id":"hcp-single-control-plane-operator","text":"HCP uses a single Control Plane Operator that replaces the many individual operators used in standalone OCP control planes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-single-control-plane-operator.json"},{"id":"hcp-sizing-override-configmap","text":"HCP resource utilization can be overridden via a ConfigMap named `hcp-sizing-baseline` in the `local-cluster` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-sizing-override-configmap.json"},{"id":"hcp-sts-token-path","text":"The web identity token path for STS in hosted control planes is /var/run/secrets/openshift/serviceaccount/token.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-sts-token-path.json"},{"id":"hcp-supported-platforms","text":"Hosted control planes support bare metal (Agent provider), OpenShift Virtualization, AWS, IBM Z, and IBM Power as platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-supported-platforms.json"},{"id":"hcp-supported-versions-configmap-hypershift-ns","text":"The `supported-versions` ConfigMap is created by the HyperShift Operator in the `hypershift` namespace with label `hypershift.openshift.io/supported-versions: \"true\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-supported-versions-configmap-hypershift-ns.json"},{"id":"hcp-techpreviewnoupgrade-irreversible-blocks-updates","text":"Enabling `TechPreviewNoUpgrade` feature set on a hosted cluster is irreversible and prevents minor version updates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-techpreviewnoupgrade-irreversible-blocks-updates.json"},{"id":"hcp-three-metrics-sets","text":"Hosted control planes support three metrics sets: Telemetry (default, smallest), SRE (alerting/troubleshooting), and All (every metric standalone OCP produces).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-three-metrics-sets.json"},{"id":"hcp-tls-secret-on-management-cluster","text":"Custom TLS certificate secrets for hosted cluster API servers are created on the management cluster, not within the hosted cluster itself.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-tls-secret-on-management-cluster.json"},{"id":"hcp-tuned-cr-name-hash-appended","text":"The Node Tuning Operator appends a hash of the node pool name and namespace to Tuned CR names to avoid collisions across node pools","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-tuned-cr-name-hash-appended.json"},{"id":"hcp-update-order-management-mce-hosted","text":"HCP update order is strict: (1) management cluster OCP, (2) multicluster engine Operator, (3) hosted cluster and node pools.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-update-order-management-mce-hosted.json"},{"id":"hcp-web-console-limitations","text":"The web console for hosted clusters cannot show control plane status, manage machines, or perform cluster updates.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-web-console-limitations.json"},{"id":"hcp-wildcard-dns-required-for-ingress","text":"Wildcard DNS routes (`WildcardsAllowed` on the IngressController) must be enabled on the infrastructure cluster for default Ingress behavior on OpenShift Virtualization hosted clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-wildcard-dns-required-for-ingress.json"},{"id":"hcp-worker-notready-15min-threshold","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hcp-worker-notready-15min-threshold.json"},{"id":"helm-and-template-dual-packaging-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-and-template-dual-packaging-model.json"},{"id":"helm-chart-release-revision-definitions","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-chart-release-revision-definitions.json"},{"id":"helm-chart-yaml-apiv2-for-helm3","text":"Chart.yaml apiVersion must be v2 for Helm 3 charts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-chart-yaml-apiv2-for-helm3.json"},{"id":"helm-default-chart-repo-url","text":"Red Hat provides a default Helm chart repository at https://charts.openshift.io/.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-default-chart-repo-url.json"},{"id":"helm-namespace-scoped-repos-no-cluster-admin","text":"Namespace-scoped Helm chart repos (ProjectHelmChartRepository) require appropriate RBAC permissions but not cluster-admin.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-namespace-scoped-repos-no-cluster-admin.json"},{"id":"helm-private-repo-ca-cert-openshift-config","text":"CA certificates for private Helm chart repos are stored as ConfigMaps in the openshift-config namespace with key ca-bundle.crt.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-private-repo-ca-cert-openshift-config.json"},{"id":"helm-removing-all-repos-hides-ui","text":"Removing all Helm chart repositories (cluster and namespace level) hides the Helm option from the Developer Console UI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-removing-all-repos-hides-ui.json"},{"id":"helm-two-repo-crd-kinds","text":"OpenShift has two CRD kinds for Helm chart repos: HelmChartRepository (cluster-scoped) and ProjectHelmChartRepository (namespace-scoped), both using API group helm.openshift.io/v1beta1.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helm-two-repo-crd-kinds.json"},{"id":"helmchartrepo-ca-tls-in-openshift-config","text":"HelmChartRepository CA ConfigMaps and TLS Secrets must reside in the `openshift-config` namespace, with keys `ca-bundle.crt`, `tls.crt`, and `tls.key`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helmchartrepo-ca-tls-in-openshift-config.json"},{"id":"helmchartrepo-cluster-scoped-v1beta1","text":"HelmChartRepository is a cluster-scoped resource under API group `helm.openshift.io/v1beta1` (Compatibility Level 2).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helmchartrepo-cluster-scoped-v1beta1.json"},{"id":"helmchartrepo-disabled-without-deleting","text":"Setting `spec.disabled: true` on a HelmChartRepository disables the repository without removing it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/helmchartrepo-disabled-without-deleting.json"},{"id":"high-node-utilization-replica-warning","text":"The `HighNodeUtilization` scheduler profile may place all replicas of a ReplicaSet on the same node","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/high-node-utilization-replica-warning.json"},{"id":"highly-privileged-projects-bypass-admission","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/highly-privileged-projects-bypass-admission.json"},{"id":"hive-provisions-klusterlet-registers","text":"Hive provisions self-managed OCP clusters to the hub; the klusterlet agent registers managed clusters to the hub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hive-provisions-klusterlet-registers.json"},{"id":"host-device-one-selector","text":"The host-device CNI plugin requires specifying a device by exactly one of: `device`, `hwaddr`, `kernelpath`, or `pciBusID`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/host-device-one-selector.json"},{"id":"hosted-control-planes-based-on-hypershift","text":"Hosted control planes in OpenShift are based on the HyperShift upstream project and enable hyperscale cluster operations with centralized control planes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hosted-control-planes-based-on-hypershift.json"},{"id":"hosted-control-planes-run-as-pods","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hosted-control-planes-run-as-pods.json"},{"id":"hostfirmwaresettings-api-group-metal3io-v1alpha1","text":"HostFirmwareSettings belongs to API group `metal3.io/v1alpha1` and is a namespaced resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostfirmwaresettings-api-group-metal3io-v1alpha1.json"},{"id":"hostfirmwaresettings-conditions-track-schema-validation","text":"HostFirmwareSettings `.status.conditions` tracks schema validation of spec settings against a referenced FirmwareSchema resource, not host health","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostfirmwaresettings-conditions-track-schema-validation.json"},{"id":"hostfirmwaresettings-spec-settings-only-required-field","text":"`.spec.settings` is the only required field in the HostFirmwareSettings spec","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostfirmwaresettings-spec-settings-only-required-field.json"},{"id":"hostfirmwaresettings-spec-status-pattern","text":"HostFirmwareSettings uses a spec/status pattern: `.spec.settings` holds desired BIOS/firmware name/value pairs, `.status.settings` reflects actual firmware state","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostfirmwaresettings-spec-status-pattern.json"},{"id":"hostnetwork-requires-clusterfirstwithhostnet","text":"When using `hostNetwork: true`, `dnsPolicy` must be set to `ClusterFirstWithHostNet` to retain cluster DNS resolution.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostnetwork-requires-clusterfirstwithhostnet.json"},{"id":"hostprefix-23-gives-510-pod-ips","text":"A hostPrefix of 23 in clusterNetwork CIDR provides 510 pod IPs per node (2^(32-23) - 2).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hostprefix-23-gives-510-pod-ips.json"},{"id":"hpa-api-group-autoscaling-v2","text":"The HorizontalPodAutoscaler uses the `autoscaling/v2` API group, which supports multiple metrics and custom metrics (v1 only supports CPU)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-api-group-autoscaling-v2.json"},{"id":"hpa-average-utilization-resource-only","text":"The `averageUtilization` target type is only valid for Resource metric source type (percentage of pod's resource request)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-average-utilization-resource-only.json"},{"id":"hpa-default-metric-80-percent-cpu","text":"When no metrics are specified in an HPA, it defaults to 80% average CPU utilization","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-default-metric-80-percent-cpu.json"},{"id":"hpa-five-metric-source-types","text":"HPA supports five metric source types: Resource, ContainerResource (requires `HPAContainerMetrics` feature gate), Pods, Object, and External","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-five-metric-source-types.json"},{"id":"hpa-is-namespaced-resource","text":"HorizontalPodAutoscaler (HPA) is a namespaced resource that targets a scalable workload such as a Deployment or ReplicaSet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-is-namespaced-resource.json"},{"id":"hpa-multiple-metrics-max-wins","text":"When multiple metrics are defined in an HPA, the maximum calculated replica count across all metrics is used","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-multiple-metrics-max-wins.json"},{"id":"hpa-policy-period-max-1800","text":"HPA behavior policy `periodSeconds` maximum is 1800 seconds (30 min); `selectPolicy` defaults to `Max`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-policy-period-max-1800.json"},{"id":"hpa-replica-calculation-formula","text":"HPA calculates desired replicas as: `desiredReplicas = currentReplicas × (currentMetricValue / targetMetricValue)`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-replica-calculation-formula.json"},{"id":"hpa-required-fields-scaletargetref-maxreplicas","text":"HPA spec requires `scaleTargetRef` and `maxReplicas`; `minReplicas` defaults to 1","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-required-fields-scaletargetref-maxreplicas.json"},{"id":"hpa-requires-metrics-source","text":"HorizontalPodAutoscaler (HPA) requires a metrics source (Metrics Server or Prometheus adapter) to function.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-requires-metrics-source.json"},{"id":"hpa-scale-to-zero-requirements","text":"HPA `minReplicas: 0` requires both the `HPAScaleToZero` feature gate and at least one Object or External metric configured","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-scale-to-zero-requirements.json"},{"id":"hpa-stabilization-window-defaults","text":"HPA scale-down stabilization window defaults to 300 seconds (5 min); scale-up defaults to 0 seconds; maximum is 3600 seconds (1 hour)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-stabilization-window-defaults.json"},{"id":"hpa-v2-in-ocp417","text":"HorizontalPodAutoscaler uses the `autoscaling/v2` API in OCP 4.17, which supports custom and external metrics (not just CPU)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpa-v2-in-ocp417.json"},{"id":"hpp-no-block-storage","text":"HostPath Provisioner (HPP) does not support block storage; LSO and LVM Storage do.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hpp-no-block-storage.json"},{"id":"htpasswd-secret-key-htpasswd","text":"HTPasswd identity provider data is stored in a Secret with key `htpasswd` (not in a ConfigMap)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/htpasswd-secret-key-htpasswd.json"},{"id":"hub-template-configmap-changes-require-manual-sync","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hub-template-configmap-changes-require-manual-sync.json"},{"id":"hub-template-configmap-same-namespace-as-policy","text":"ConfigMaps referenced by hub templates must be in the same namespace as the generated policy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hub-template-configmap-same-namespace-as-policy.json"},{"id":"hub-template-fromconfigmap-function","text":"The `fromConfigMap` function is the primary hub template function for pulling values from ConfigMaps, with syntax `fromConfigMap \"<namespace>\" \"<configmap-name>\" \"<key>\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hub-template-fromconfigmap-function.json"},{"id":"hub-template-syntax-hub-delimiters","text":"RHACM hub cluster templates use `{{hub ... hub}}` delimiters (not standard Go `{{ }}`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hub-template-syntax-hub-delimiters.json"},{"id":"hub-template-toliteral-for-json-arrays","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hub-template-toliteral-for-json-arrays.json"},{"id":"hw-networks-additional-interfaces-via-multus","text":"Hardware networks are consumed as additional/secondary network interfaces on pods via Multus CNI, alongside the primary OVN-Kubernetes cluster network","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-networks-additional-interfaces-via-multus.json"},{"id":"hw-offload-eswitchmode-switchdev","text":"Hardware offloading requires `eSwitchMode: \"switchdev\"` in the `SriovNetworkNodePolicy` with `deviceType: netdevice` (vfio-pci is not supported)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-eswitchmode-switchdev.json"},{"id":"hw-offload-incompatible-with-dpdk","text":"Hardware offloading is not compatible with DPDK applications","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-incompatible-with-dpdk.json"},{"id":"hw-offload-requires-bare-metal-smartnic","text":"Hardware offloading in OpenShift requires bare metal nodes with SmartNICs and is not available on VMs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-requires-bare-metal-smartnic.json"},{"id":"hw-offload-requires-ovn-kubernetes","text":"Hardware offloading requires the OVN-Kubernetes network plugin with `gatewayConfig.routingViaHost` set to `false`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-requires-ovn-kubernetes.json"},{"id":"hw-offload-sriov-systemd-mode","text":"The SR-IOV Operator must be set to `configurationMode: \"systemd\"` in the `SriovOperatorConfig` CR (named `default`) for hardware offloading","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-sriov-systemd-mode.json"},{"id":"hw-offload-supported-traffic-types","text":"Hardware offloading supports only two communication types: pod-to-pod and pod-to-ClusterIP-service (backed by regular pods)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-supported-traffic-types.json"},{"id":"hw-offload-without-pod-config-decreases-throughput","text":"Enabling hardware offloading on a node without configuring pods to use it results in decreased throughput","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/hw-offload-without-pod-config-decreases-throughput.json"},{"id":"ibi-cluster-service-network-immutable","text":"The `clusterNetwork` and `serviceNetwork` settings from the seed cluster are baked into the seed image and cannot be changed after seed image creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-cluster-service-network-immutable.json"},{"id":"ibi-dual-stack-not-supported","text":"Dual-stack networking is not supported for image-based installation (IBI) in OCP 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-dual-stack-not-supported.json"},{"id":"ibi-lifecycle-agent-namespace","text":"The Lifecycle Agent is installed in the `openshift-lifecycle-agent` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-lifecycle-agent-namespace.json"},{"id":"ibi-seed-image-is-oci-container","text":"The IBI seed image is an OCI container image (not a disk image), generated from a seed cluster using the Lifecycle Agent.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-seed-image-is-oci-container.json"},{"id":"ibi-seed-target-must-match-cpu-topology","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-seed-target-must-match-cpu-topology.json"},{"id":"ibi-shared-partition-machineconfig-install-time","text":"The shared container partition MachineConfig for IBI must be applied at installation time of the seed cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-shared-partition-machineconfig-install-time.json"},{"id":"ibi-two-phase-installation-deployment","text":"Image-based installation (IBI) separates installation (preinstalling at central site) from deployment (reconfiguring at remote site) as two distinct phases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-two-phase-installation-deployment.json"},{"id":"ibi-var-lib-containers-minimum-500gb","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibi-var-lib-containers-minimum-500gb.json"},{"id":"ibm-cloud-bare-metal-classic-supported-platform","text":"IBM Cloud Bare Metal (Classic) is a supported installation platform for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-cloud-bare-metal-classic-supported-platform.json"},{"id":"ibm-cloud-classic-distinct-from-vpc","text":"IBM Cloud Bare Metal (Classic) is distinct from IBM Cloud VPC, IBM Power, and IBM Z/LinuxONE as separate installation targets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-cloud-classic-distinct-from-vpc.json"},{"id":"ibm-cloud-classic-vs-vpc-distinct-install-paths","text":"IBM Cloud has distinct installation paths: Bare Metal (Classic), VPC, and IBM Power Virtual Server, each with separate documentation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-cloud-classic-vs-vpc-distinct-install-paths.json"},{"id":"ibm-cloud-supported-install-target-ocp417","text":"IBM Cloud (VPC) is a supported installation target for OpenShift Container Platform 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-cloud-supported-install-target-ocp417.json"},{"id":"ibm-power-architecture-ppc64le-no-heterogeneous","text":"IBM Power uses the `ppc64le` architecture and heterogeneous clusters are not supported — all machine pools must use the same architecture.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-power-architecture-ppc64le-no-heterogeneous.json"},{"id":"ibm-power-two-install-methods","text":"IBM Power has exactly two installation methods: standard (internet-connected) and restricted/disconnected network (using an internal mirror of release content).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-power-two-install-methods.json"},{"id":"ibm-power-typically-upi","text":"IBM Power installations typically require user-provisioned infrastructure (UPI) rather than installer-provisioned infrastructure (IPI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-power-typically-upi.json"},{"id":"ibm-power-upi-only-no-ipi","text":"IBM Power supports only user-provisioned infrastructure (UPI) installations — IPI is not available.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-power-upi-only-no-ipi.json"},{"id":"ibm-powervc-openstack-based","text":"IBM PowerVC (Power Virtualization Center) is built on OpenStack and provides virtualization management for IBM Power Systems.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-powervc-openstack-based.json"},{"id":"ibm-z-deployment-targets-zvm-lpar-kvm","text":"IBM Z deployments can run on z/VM, LPAR (Logical Partitions), or KVM on IBM Z.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-z-deployment-targets-zvm-lpar-kvm.json"},{"id":"ibm-z-power-openshift-virt-unsupported","text":"OpenShift Virtualization is unsupported on IBM Z and IBM Power platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-z-power-openshift-virt-unsupported.json"},{"id":"ibm-z-storage-dasd-or-fcp-scsi","text":"IBM Z installations use platform-specific disk provisioning via DASD or FCP/SCSI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-z-storage-dasd-or-fcp-scsi.json"},{"id":"ibm-z-upi-only-no-ipi","text":"IBM Z installations use User-Provisioned Infrastructure (UPI) only — IPI is not available for the IBM Z platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibm-z-upi-only-no-ipi.json"},{"id":"ibmcloud-cco-manual-mode-only","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-cco-manual-mode-only.json"},{"id":"ibmcloud-ccoctl-delete-service-id-post-destroy","text":"After `openshift-install destroy cluster` on IBM Cloud, CCO credentials must be separately deleted using `ccoctl ibmcloud delete-service-id` as a manual step.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-ccoctl-delete-service-id-post-destroy.json"},{"id":"ibmcloud-five-install-variants","text":"IBM Cloud supports five IPI installation variants: customized cluster, network customizations, existing VPC, private cluster on existing VPC, and restricted network (air-gapped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-five-install-variants.json"},{"id":"ibmcloud-ic-api-key-env-var","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-ic-api-key-env-var.json"},{"id":"ibmcloud-ipi-only","text":"IBM Cloud supports only installer-provisioned infrastructure (IPI) for OpenShift installation — user-provisioned infrastructure (UPI) is not supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-ipi-only.json"},{"id":"ibmcloud-only-ipv4-supported","text":"Only IPv4 addresses are supported for networking on IBM Cloud OpenShift installations.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-only-ipv4-supported.json"},{"id":"ibmcloud-pvcs-not-auto-removed","text":"PVCs created after cluster deployment are not automatically removed during `openshift-install destroy cluster` on IBM Cloud.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-pvcs-not-auto-removed.json"},{"id":"ibmcloud-resource-group-uninstall-behavior","text":"On cluster uninstall, installer-created resource groups are deleted while user-provided resource groups are preserved (only installer-provisioned resources within them are removed).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-resource-group-uninstall-behavior.json"},{"id":"ibmcloud-subnet-names-not-ids","text":"Only subnet names (not IDs) are supported for `computeSubnets` and `controlPlaneSubnets` in IBM Cloud `install-config.yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-subnet-names-not-ids.json"},{"id":"ibmcloud-uninstall-requires-metadata-json","text":"The `metadata.json` file in the installation directory is required for cluster deletion via `openshift-install destroy cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ibmcloud-uninstall-requires-metadata-json.json"},{"id":"icsp-api-group-alpha","text":"ICSP uses API group `operator.openshift.io/v1alpha1` — it is an alpha-level API with no compatibility guarantees (Compatibility Level 4).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-api-group-alpha.json"},{"id":"icsp-cluster-scoped-resource","text":"ImageContentSourcePolicy (ICSP) is a cluster-scoped resource with no namespace, applying globally across the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-cluster-scoped-resource.json"},{"id":"icsp-deprecated-in-favor-of-idms","text":"ICSP is deprecated starting in OCP 4.13 in favor of ImageDigestMirrorSet (IDMS), which provides the same digest-based mirroring with a stable API.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-deprecated-in-favor-of-idms.json"},{"id":"icsp-deprecated-replaced-by-idms-itms","text":"ImageContentSourcePolicy (ICSP) is deprecated and replaced by ImageDigestMirrorSet (IDMS) and ImageTagMirrorSet (ITMS) starting in OpenShift 4.13+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-deprecated-replaced-by-idms-itms.json"},{"id":"icsp-digest-only-mirroring","text":"ImageContentSourcePolicy (ICSP) mirrors only apply to images pulled by digest — images referenced by tag are always pulled from the original source repository.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-digest-only-mirroring.json"},{"id":"icsp-key-usecase-disconnected-installs","text":"ICSP is essential for disconnected/air-gapped environments where images must be pulled from a local mirror rather than internet-facing registries.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-key-usecase-disconnected-installs.json"},{"id":"icsp-multiple-policies-merge-mirrors","text":"When multiple ICSP objects define mirrors for the same source, mirror lists are merged preserving relative order where possible.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-multiple-policies-merge-mirrors.json"},{"id":"icsp-triggers-node-reboots-via-mco","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/icsp-triggers-node-reboots-via-mco.json"},{"id":"identity-api-group","text":"The Identity resource belongs to the `user.openshift.io/v1` API group, not core Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-api-group.json"},{"id":"identity-governed-software-delivery","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-governed-software-delivery.json"},{"id":"identity-governs-operator-and-workload-access","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-governs-operator-and-workload-access.json"},{"id":"identity-requires-providername-and-providerusername","text":"An Identity resource requires both `providerName` and `providerUserName` fields, which together uniquely identify an authentication record.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-requires-providername-and-providerusername.json"},{"id":"identity-session-and-authorization-complete","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-session-and-authorization-complete.json"},{"id":"identity-to-authorization-governance-chain","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-to-authorization-governance-chain.json"},{"id":"identity-user-reference-requires-name-and-uid","text":"The `user` field on an Identity object is an ObjectReference that requires both Name and UID to be set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/identity-user-reference-requires-name-and-uid.json"},{"id":"idms-digest-only-mirroring","text":"ImageDigestMirrorSet (IDMS) applies only to images referenced by digest (`@sha256:...`); ImageTagMirrorSet (ITMS) is the companion resource for tag-based pulls","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/idms-digest-only-mirroring.json"},{"id":"idms-mirror-source-policy-never-contact","text":"IDMS and ITMS support `mirrorSourcePolicy: NeverContactSource` to block fallback to the original source registry, critical for fully disconnected environments","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/idms-mirror-source-policy-never-contact.json"},{"id":"idms-most-specific-source-wins","text":"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`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/idms-most-specific-source-wins.json"},{"id":"ignition-certs-expire-24-hours","text":"Ignition config files contain certificates that expire after 24 hours; best practice is to use them within 12 hours of generation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ignition-certs-expire-24-hours.json"},{"id":"ignition-configs-expire-24h","text":"Ignition certificates expire after 24 hours and auto-renew; Ignition configs should be used within 12 hours of generation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ignition-configs-expire-24h.json"},{"id":"ignition-files-expire-24-hours","text":"Ignition configuration files expire after 24 hours — installation must begin within that window.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ignition-files-expire-24-hours.json"},{"id":"ignition-first-boot-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ignition-first-boot-only.json"},{"id":"ignition-supports-raid-not-lvm","text":"Ignition supports RAID but does not support LVM for disk configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ignition-supports-raid-not-lvm.json"},{"id":"image-additional-trusted-ca-in-openshift-config","text":"The `additionalTrustedCA` field on the Image config references a ConfigMap in the `openshift-config` namespace for custom CA bundles trusted during image operations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-additional-trusted-ca-in-openshift-config.json"},{"id":"image-allowed-blocked-registries-mutually-exclusive","text":"In the Image config resource, `registrySources.allowedRegistries` and `registrySources.blockedRegistries` are mutually exclusive — only one may be set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-allowed-blocked-registries-mutually-exclusive.json"},{"id":"image-allowed-registries-for-import-not-restrict-admins","text":"The `allowedRegistriesForImport` field does not restrict admin users who can directly create Images or ImageStreamMappings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-allowed-registries-for-import-not-restrict-admins.json"},{"id":"image-apis-are-openshift-specific","text":"Image APIs (Image, ImageStream, ImageStreamTag, ImageStreamImage, ImageStreamImport, ImageTag) are OpenShift-specific extensions that do not exist in vanilla Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-apis-are-openshift-specific.json"},{"id":"image-apis-openshift-specific","text":"Image APIs (Image, ImageStream, ImageStreamTag, etc.) are OpenShift-specific extensions to the Kubernetes API, not available in vanilla Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-apis-openshift-specific.json"},{"id":"image-config-cr-name-cluster","text":"The cluster-wide image registry configuration CR is image.config.openshift.io/cluster (kind Image, name must be \"cluster\")","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-config-cr-name-cluster.json"},{"id":"image-container-runtime-search-registries-crio-only","text":"The `containerRuntimeSearchRegistries` field in the Image config works only with CRI-O, not with builds or imagestream imports.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-container-runtime-search-registries-crio-only.json"},{"id":"image-content-source-policy-v1alpha1-level4","text":"ImageContentSourcePolicy is Compatibility level 4 (v1alpha1) with no compatibility guarantees, unlike most operator APIs which are level 1","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-content-source-policy-v1alpha1-level4.json"},{"id":"image-external-registry-hostnames-first-entry-used","text":"The first entry in `externalRegistryHostnames` populates `publicDockerImageRepository` in ImageStreams.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-external-registry-hostnames-first-entry-used.json"},{"id":"image-governed-from-build-through-lifecycle","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-governed-from-build-through-lifecycle.json"},{"id":"image-layering-base-image-command","text":"The correct base RHCOS image for image layering is obtained with `oc adm release info --image-for rhel-coreos`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-layering-base-image-command.json"},{"id":"image-layering-containerfile-must-end-ostree-commit","text":"All RHCOS image layering Containerfiles must end with `ostree container commit` after installing packages.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-layering-containerfile-must-end-ostree-commit.json"},{"id":"image-layering-custom-node-os","text":"Image layering is the supported method for adding custom content to RHCOS node OS images without building entirely custom images","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-layering-custom-node-os.json"},{"id":"image-layering-no-rt-kernel-extensions","text":"Realtime kernel or extensions RPMs must NOT be installed as custom layered content — they conflict with MCO-managed RPMs and cause a degraded state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-layering-no-rt-kernel-extensions.json"},{"id":"image-layering-verify-rpm-ostree-status","text":"Custom layered image deployment on a node is verified with `rpm-ostree status` (via `oc debug node`).","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-layering-verify-rpm-ostree-status.json"},{"id":"image-lifecycle-management-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-lifecycle-management-model.json"},{"id":"image-manifest-list-uses-dockerimagemanifests","text":"An Image with `dockerImageManifests` populated represents a manifest list (multi-arch); `dockerImageLayers` should not be set in this case.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-manifest-list-uses-dockerimagemanifests.json"},{"id":"image-metadata-stored-as-api-resources","text":"Image metadata is stored as standard API resources (images and image streams), not in the registry storage; actual image data goes to configurable storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-metadata-stored-as-api-resources.json"},{"id":"image-mirror-configuration-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-mirror-configuration-pipeline.json"},{"id":"image-name-max-63-chars","text":"Maximum image name length in OpenShift is 63 characters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-name-max-63-chars.json"},{"id":"image-objects-immutable-content-addressed","text":"Image objects in OpenShift are immutable and content-addressed (named by a hash of their contents)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-objects-immutable-content-addressed.json"},{"id":"image-registry-auto-detects-storage","text":"The Cluster Image Registry Operator auto-detects storage based on cloud provider; creates an incomplete resource if storage info is missing.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-auto-detects-storage.json"},{"id":"image-registry-cluster-operator","text":"The `image-registry` cluster operator manages the lifecycle of OpenShift's built-in internal container image registry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-cluster-operator.json"},{"id":"image-registry-config-singleton-named-cluster","text":"The image registry Config resource (`imageregistry.operator.openshift.io/v1`) is a cluster-scoped singleton named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-config-singleton-named-cluster.json"},{"id":"image-registry-default-route-true-exposes-externally","text":"Setting `defaultRoute: true` on the image registry Config creates an externally accessible route using the default hostname.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-default-route-true-exposes-externally.json"},{"id":"image-registry-disable-redirect-forces-data-through-registry","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-disable-redirect-forces-data-through-registry.json"},{"id":"image-registry-emptydir-not-production","text":"The image registry `emptyDir` storage backend is not production-grade — data is lost when the pod restarts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-emptydir-not-production.json"},{"id":"image-registry-external-access-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-external-access-model.json"},{"id":"image-registry-operator-separate-api-group","text":"The image registry operator uses configs.imageregistry.operator.openshift.io (not operator.openshift.io)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-operator-separate-api-group.json"},{"id":"image-registry-pvc-claim-immutable","text":"The image registry PVC `claim` field cannot be changed once set — the PVC must be deleted and recreated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-pvc-claim-immutable.json"},{"id":"image-registry-replicas-only-required-field","text":"The `replicas` field is the only required field in the image registry Config `.spec`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-replicas-only-required-field.json"},{"id":"image-registry-storage-backends","text":"The image registry supports seven storage backends: S3, Azure Blob, GCS, OpenStack Swift, PVC, IBM COS, and emptyDir.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-registry-storage-backends.json"},{"id":"image-resource-cluster-scoped","text":"Image objects are cluster-scoped resources (not namespaced).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-resource-cluster-scoped.json"},{"id":"image-resource-immutable-content-addressable","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-resource-immutable-content-addressable.json"},{"id":"image-signatures-enforce-cluster-wide-policy","text":"Image signatures can enforce cluster-wide image policy restricting which images are allowed to run.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-signatures-enforce-cluster-wide-policy.json"},{"id":"image-streams-enable-automated-rollouts","text":"Image Streams and Triggers enable automated rollouts when upstream images change, tying into CI/CD workflows.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-streams-enable-automated-rollouts.json"},{"id":"image-supply-chain-end-to-end","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-supply-chain-end-to-end.json"},{"id":"image-tags-mutable-ids-immutable","text":"Image tags are mutable human-readable labels pointing to immutable SHA digests; multiple tags can point to the same digest.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-tags-mutable-ids-immutable.json"},{"id":"image-trigger-annotation-for-k8s-resources","text":"Kubernetes-native resources (Deployments, StatefulSets, DaemonSets, CronJobs, Jobs, ReplicationControllers, Pods) use the `image.openshift.io/triggers` annotation to trigger on image stream tag changes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-trigger-annotation-for-k8s-resources.json"},{"id":"image-trigger-fieldpath-no-wildcards","text":"The `fieldPath` in an image trigger annotation must precisely match a container by name or index and cannot use wildcards.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-trigger-fieldpath-no-wildcards.json"},{"id":"image-trigger-from-kind-imagestreamtag-only","text":"The `from.kind` in an image trigger annotation must be `ImageStreamTag` — no other kinds are supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-trigger-from-kind-imagestreamtag-only.json"},{"id":"image-trigger-paused-disables-without-removing","text":"Setting `paused: true` in an image trigger annotation disables the trigger without removing the annotation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/image-trigger-paused-disables-without-removing.json"},{"id":"imagecontentpolicy-cluster-scoped","text":"ImageContentPolicy is a cluster-scoped (not namespaced) resource in the `config.openshift.io/v1` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagecontentpolicy-cluster-scoped.json"},{"id":"imagecontentpolicy-digest-only-default","text":"ImageContentPolicy mirrors only work for digest-based image pulls by default; `allowMirrorByTags: true` must be set to enable tag-based mirroring","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagecontentpolicy-digest-only-default.json"},{"id":"imagecontentpolicy-multiple-policies-merged","text":"When multiple ImageContentPolicy objects define mirrors for the same source, mirror lists are merged (not rejected); conflicting orderings result in unspecified behavior, not errors","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagecontentpolicy-multiple-policies-merged.json"},{"id":"imagemanifestvuln-crd-shortname-vuln","text":"Vulnerability scan results are exposed as `ImageManifestVuln` CRs (CRD: `imagemanifestvulns.secscan.quay.redhat.com`); CLI shorthand is `oc get vuln --all-namespaces`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagemanifestvuln-crd-shortname-vuln.json"},{"id":"imagepruner-api-group","text":"The ImagePruner resource uses API group `imageregistry.operator.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-api-group.json"},{"id":"imagepruner-default-min-age-60m","text":"The ImagePruner default minimum image age before pruning eligibility is 60 minutes (`keepYoungerThanDuration`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-default-min-age-60m.json"},{"id":"imagepruner-default-schedule-daily-midnight","text":"The ImagePruner default schedule is `0 0 * * *` (daily at midnight).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-default-schedule-daily-midnight.json"},{"id":"imagepruner-default-tag-revisions-3","text":"The ImagePruner preserves a default of 3 tag revisions per image stream tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-default-tag-revisions-3.json"},{"id":"imagepruner-keepyoungerthan-deprecated","text":"The ImagePruner `keepYoungerThan` field (nanoseconds) is deprecated in favor of `keepYoungerThanDuration` (duration string); if both are set, the duration field wins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-keepyoungerthan-deprecated.json"},{"id":"imagepruner-managed-by-image-registry-operator","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-managed-by-image-registry-operator.json"},{"id":"imagepruner-suspend-true-pauses","text":"Setting `suspend: true` on the ImagePruner stops pruning without removing the configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagepruner-suspend-true-pauses.json"},{"id":"imagesignature-immutable-post-delete-only","text":"ImageSignature resources support only POST (create) and DELETE operations — no PATCH or PUT — making signatures immutable once created.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagesignature-immutable-post-delete-only.json"},{"id":"imagesignature-required-fields","text":"ImageSignature required fields are `type` and `content`; `issuedTo` also requires `publicKeyID` (at least 64 lowest bits of the public key fingerprint).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagesignature-required-fields.json"},{"id":"imagestream-api-group","text":"The API group for image streams is `image.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-api-group.json"},{"id":"imagestream-buildconfig-openshift-native","text":"ImageStream and BuildConfig are OpenShift-native concepts with no direct Kubernetes equivalents.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-buildconfig-openshift-native.json"},{"id":"imagestream-controlled-access-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-controlled-access-model.json"},{"id":"imagestream-dockerimagerepository-deprecated","text":"The `spec.dockerImageRepository` field on ImageStream is deprecated since v3.7; replaced by per-tag `spec.tags[].from`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-dockerimagerepository-deprecated.json"},{"id":"imagestream-imports-ignore-mirror-search","text":"Image stream imports do not use the mirror/search mechanism — `samplesRegistry` must be explicitly set to the mirror hostname.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-imports-ignore-mirror-search.json"},{"id":"imagestream-lookup-policy-local-resolves-short-names","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-lookup-policy-local-resolves-short-names.json"},{"id":"imagestream-lookup-policy-local-true","text":"Setting `spec.lookupPolicy.local: true` on an image stream enables all resources in the same project to resolve image stream references without additional configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-lookup-policy-local-true.json"},{"id":"imagestream-metadata-stored-in-etcd","text":"Image stream metadata is stored in etcd.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-metadata-stored-in-etcd.json"},{"id":"imagestream-pull-requires-get-layers-permission","text":"Pulling from the integrated registry requires `get imagestreams/layers` permission.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-pull-requires-get-layers-permission.json"},{"id":"imagestream-reference-policy-local-vs-source","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-reference-policy-local-vs-source.json"},{"id":"imagestream-resolve-names-annotation","text":"The annotation `alpha.image.policy.openshift.io/resolve-names: '*'` on a pod template enables image stream resolution for that specific resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-resolve-names-annotation.json"},{"id":"imagestream-same-project-single-segment-name","text":"Image stream references must use single-segment names (`<name>:<tag>`, not full registry paths) and the image stream must be in the same project as the referencing resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-same-project-single-segment-name.json"},{"id":"imagestream-scheduled-import-policy","text":"Setting `importPolicy.scheduled: true` on an ImageStream tag enables periodic re-import to track upstream changes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-scheduled-import-policy.json"},{"id":"imagestream-status-tags-first-item-is-current","text":"The first entry in `status.tags[].items` is the currently active image for that tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-status-tags-first-item-is-current.json"},{"id":"imagestream-tag-vs-image-distinction","text":"ImageStreamTag references an image by tag name while ImageStreamImage references a specific image by digest within an ImageStream.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestream-tag-vs-image-distinction.json"},{"id":"imagestreamimage-name-format-stream-at-digest","text":"ImageStreamImage name format is `<STREAM>@<DIGEST>` (e.g., `mystream@sha256:abc123...`), using a content-addressable digest reference rather than a tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamimage-name-format-stream-at-digest.json"},{"id":"imagestreamimage-read-only","text":"ImageStreamImage is a read-only resource — only GET is supported, no create/update/delete.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamimage-read-only.json"},{"id":"imagestreamimport-only-dockerimage-source","text":"ImageStreamImport only allows `kind: DockerImage` as the `from` source for importing images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamimport-only-dockerimage-source.json"},{"id":"imagestreamimport-spec-import-true-triggers-import","text":"On ImageStreamImport, `spec.import: true` triggers actual import; `false` is a metadata preview/dry-run only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamimport-spec-import-true-triggers-import.json"},{"id":"imagestreamlayers-imagemissing-flag","text":"The `imageMissing` boolean in ImageStreamLayers indicates an Image object was deleted by an admin but is still referenced by the ImageStream","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamlayers-imagemissing-flag.json"},{"id":"imagestreamlayers-layers-ordered-base-to-top","text":"ImageStreamLayers layers are ordered from base layer to top layer, and all referenced layers are guaranteed to exist in the blobs map","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamlayers-layers-ordered-base-to-top.json"},{"id":"imagestreamlayers-multiarch-uses-manifests","text":"In ImageStreamLayers, multi-architecture images use the `manifests` field (list of digests) instead of `layers`/`config`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamlayers-multiarch-uses-manifests.json"},{"id":"imagestreamlayers-read-only-subresource","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamlayers-read-only-subresource.json"},{"id":"imagestreammapping-create-only","text":"ImageStreamMapping only supports the create operation — no get, list, update, or delete","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreammapping-create-only.json"},{"id":"imagestreammapping-grants-view-access","text":"Creating an ImageStreamMapping grants view access to the image for anyone who can view the image stream","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreammapping-grants-view-access.json"},{"id":"imagestreammapping-privileged-integrators","text":"ImageStreamMapping is used by privileged integrators (not end users) to associate a container image with an image stream tag","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreammapping-privileged-integrators.json"},{"id":"imagestreams-abstract-over-registry-locations","text":"ImageStreams provide an abstraction over container image repositories, enabling tag-based references, indirection over registry locations, and automatic updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreams-abstract-over-registry-locations.json"},{"id":"imagestreams-enable-automatic-rollouts","text":"ImageStreams enable automatic rollouts when upstream images change — DeploymentConfigs can trigger on ImageStream tag changes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreams-enable-automatic-rollouts.json"},{"id":"imagestreams-no-actual-image-data","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreams-no-actual-image-data.json"},{"id":"imagestreams-openshift-specific-not-k8s","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreams-openshift-specific-not-k8s.json"},{"id":"imagestreamtag-delete-clears-spec-and-status","text":"Deleting an ImageStreamTag clears both the status and spec fields of the associated image stream tag","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagestreamtag-delete-clears-spec-and-status.json"},{"id":"imagetag-create-requires-no-existing-spec","text":"Creating an ImageTag only succeeds if no spec tag already exists and the spec field is set","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagetag-create-requires-no-existing-spec.json"},{"id":"imagetag-replaces-imagestreamtag","text":"ImageTag (`image.openshift.io/v1`) is the newer replacement for ImageStreamTag, providing spec + status + image in a single object","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagetag-replaces-imagestreamtag.json"},{"id":"imagetag-spec-from-reference-types","text":"An ImageTag's `spec.from` can reference `ImageStreamTag` (same stream only), `ImageStreamImage`, or `DockerImage`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/imagetag-spec-from-reference-types.json"},{"id":"immutability-enforced-at-resource-and-platform-levels","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/immutability-enforced-at-resource-and-platform-levels.json"},{"id":"immutable-nodes-with-singleton-operator-control","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/immutable-nodes-with-singleton-operator-control.json"},{"id":"importpolicy-scheduled-periodic-reimport","text":"Setting `importPolicy.scheduled: true` on an image stream tag enables periodic re-checking and re-import of external tags","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/importpolicy-scheduled-periodic-reimport.json"},{"id":"infra-node-label","text":"Infrastructure nodes are identified by the label `node-role.kubernetes.io/infra: \"\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infra-node-label.json"},{"id":"infra-node-taint","text":"The recommended taint for infrastructure nodes is `node-role.kubernetes.io/infra:NoSchedule` to prevent user workloads from scheduling.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infra-node-taint.json"},{"id":"infra-nodes-no-subscription-cost","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infra-nodes-no-subscription-cost.json"},{"id":"infra-workload-move-requires-per-operator-config","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infra-workload-move-requires-per-operator-config.json"},{"id":"infrastructure-cloud-config-configmap-namespace","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-cloud-config-configmap-namespace.json"},{"id":"infrastructure-dual-stack-two-ips","text":"Dual-stack clusters have two entries in `apiServerInternalIPs` and `ingressIPs` (one IPv4, one IPv6)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-dual-stack-two-ips.json"},{"id":"infrastructure-operator-bare-metal-vsphere-sno","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-operator-bare-metal-vsphere-sno.json"},{"id":"infrastructure-platform-type-controls-automation","text":"`Infrastructure.spec.platformSpec.type` determines whether infrastructure automation (load balancers, dynamic volumes, machine lifecycle) is enabled; setting `None` disables all automation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-platform-type-controls-automation.json"},{"id":"infrastructure-platform-types","text":"Allowed `platformSpec.type` values include: AWS, Azure, BareMetal, GCP, Libvirt, OpenStack, VSphere, oVirt, KubeVirt, EquinixMetal, PowerVS, AlibabaCloud, Nutanix, None","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-platform-types.json"},{"id":"infrastructure-resource-singleton-cluster","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/infrastructure-resource-singleton-cluster.json"},{"id":"ingress-api-group-networking-v1","text":"Kubernetes Ingress belongs to API group `networking.k8s.io/v1` (not the deprecated `extensions/v1beta1`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-api-group-networking-v1.json"},{"id":"ingress-appsdomain-mutable-post-install","text":"`spec.appsDomain` on the Ingress config is an optional alternative domain for route host generation that can be modified post-install","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-appsdomain-mutable-post-install.json"},{"id":"ingress-backend-same-namespace","text":"The service referenced by an Ingress backend must be in the same namespace as the Ingress object","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-backend-same-namespace.json"},{"id":"ingress-cloud-default-loadbalancer-external","text":"Cloud platforms (AWS, Azure, GCP) default to LoadBalancerService with External scope for endpoint publishing.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-cloud-default-loadbalancer-external.json"},{"id":"ingress-config-singleton-named-cluster","text":"The Ingress resource (`config.openshift.io/v1`) is a cluster-wide singleton with canonical name `cluster`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-config-singleton-named-cluster.json"},{"id":"ingress-controller-default-replicas-2","text":"The default number of replicas per Ingress Controller is 2.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-controller-default-replicas-2.json"},{"id":"ingress-controller-default-tls-intermediate","text":"The default TLS security profile for Ingress Controllers is Intermediate (TLS 1.2 minimum).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-controller-default-tls-intermediate.json"},{"id":"ingress-controller-namespace-openshift-ingress-operator","text":"The default Ingress Controller is named `default` and lives in the `openshift-ingress-operator` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-controller-namespace-openshift-ingress-operator.json"},{"id":"ingress-default-placement-workers","text":"`status.defaultPlacement` on the Ingress config controls whether ingress router pods run on control-plane or worker nodes (default: Workers)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-default-placement-workers.json"},{"id":"ingress-domain-field-immutable-unique","text":"The domain field on an IngressController cannot be updated after creation and must be unique across all Ingress Controllers.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-domain-field-immutable-unique.json"},{"id":"ingress-domain-immutable-after-install","text":"`spec.domain` on the Ingress config sets the default domain for route host generation and cannot be changed after installation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-domain-immutable-after-install.json"},{"id":"ingress-forwarded-header-default-append","text":"The HTTP header forwarding policy defaults to Append.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-forwarded-header-default-append.json"},{"id":"ingress-haproxy-default-threads-4-max-64","text":"HAProxy default thread count is 4 (max 64) and default max connections is 50000.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-haproxy-default-threads-4-max-64.json"},{"id":"ingress-hsts-first-match-wins","text":"HSTS policies in `spec.requiredHSTSPolicies` are enforced via the `haproxy.router.openshift.io/hsts_header` annotation with first matching policy winning","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-hsts-first-match-wins.json"},{"id":"ingress-http2-headerbuffer-min-16384","text":"The headerBufferBytes must be at least 16384 if HTTP/2 is enabled (default 32768).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-http2-headerbuffer-min-16384.json"},{"id":"ingress-longest-path-wins","text":"When multiple Ingress paths match a request, the longest matching path takes priority","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-longest-path-wins.json"},{"id":"ingress-node-firewall-config-cr-name","text":"The `IngressNodeFirewallConfig` CR must be named `ingressnodefirewallconfig` and created in the `openshift-ingress-node-firewall` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-config-cr-name.json"},{"id":"ingress-node-firewall-ebpf-xdp","text":"The Ingress Node Firewall Operator uses eBPF programs with XDP preferred for packet processing; NICs without native XDP drivers run at lower performance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-ebpf-xdp.json"},{"id":"ingress-node-firewall-must-gather","text":"`oc adm must-gather -- gather_ingress_node_firewall` collects firewall-specific diagnostics including eBPF bpftool outputs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-must-gather.json"},{"id":"ingress-node-firewall-namespace","text":"The Ingress Node Firewall Operator runs in the `openshift-ingress-node-firewall` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-namespace.json"},{"id":"ingress-node-firewall-rule-order-1-100","text":"Ingress Node Firewall rules use an `order` field (1–100 per source CIDR); lower order number means higher priority (executes first).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-rule-order-1-100.json"},{"id":"ingress-node-firewall-sno-annotation","text":"For Single-Node OpenShift clusters, the `openshift-ingress-node-firewall` namespace requires the annotation `workload.openshift.io/allowed=management`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-sno-annotation.json"},{"id":"ingress-node-firewall-stateless-only","text":"The Ingress Node Firewall Operator supports only stateless firewall rules (no connection tracking).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-stateless-only.json"},{"id":"ingress-node-firewall-webhook-blocks-critical","text":"The Ingress Node Firewall verification webhook prevents invalid configs and blocks rules that would break critical cluster services such as the API server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-node-firewall-webhook-blocks-critical.json"},{"id":"ingress-operator-converts-tls10-to-tls11","text":"The Ingress Operator always converts TLS 1.0 to TLS 1.1 for Old or Custom security profiles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-operator-converts-tls10-to-tls11.json"},{"id":"ingress-operator-deploys-haproxy","text":"The Ingress Operator deploys and manages HAProxy-based Ingress Controllers to route external traffic into the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-operator-deploys-haproxy.json"},{"id":"ingress-operator-namespaces","text":"The Ingress Operator runs in the `openshift-ingress-operator` namespace; the router runs in the `openshift-ingress` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-operator-namespaces.json"},{"id":"ingress-pathtype-required-three-values","text":"Ingress `pathType` is required on every path entry with three possible values: Exact, Prefix, and ImplementationSpecific","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-pathtype-required-three-values.json"},{"id":"ingress-prefix-match-element-wise","text":"Ingress Prefix path matching is element-wise by `/` — `/foo/bar` matches `/foo/bar/baz` but does NOT match `/foo/barbaz`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-prefix-match-element-wise.json"},{"id":"ingress-route-admission-default-strict","text":"The routeAdmission.namespaceOwnership policy defaults to Strict (no cross-namespace hostname sharing).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-route-admission-default-strict.json"},{"id":"ingress-sharding-via-namespace-route-selectors","text":"Ingress Controller sharding is implemented via namespaceSelector and routeSelector on the IngressController CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-sharding-via-namespace-route-selectors.json"},{"id":"ingress-tls-port-443-only","text":"TLS on Kubernetes Ingress only supports port 443","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-tls-port-443-only.json"},{"id":"ingress-wildcard-policy-default-disallowed","text":"The IngressController wildcardPolicy defaults to WildcardsDisallowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-wildcard-policy-default-disallowed.json"},{"id":"ingress-wildcard-single-label","text":"Ingress wildcard hosts (`*.foo.com`) match exactly one DNS label — `*` alone is not a valid host","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingress-wildcard-single-label.json"},{"id":"ingressclass-cluster-scoped","text":"IngressClass is a cluster-scoped resource (not namespaced) in API group `networking.k8s.io/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingressclass-cluster-scoped.json"},{"id":"ingressclass-controller-immutable","text":"IngressClass `spec.controller` field is immutable — cannot be changed after creation","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingressclass-controller-immutable.json"},{"id":"ingressclass-default-annotation","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingressclass-default-annotation.json"},{"id":"ingresscontroller-controls-haproxy-router","text":"IngressController is the resource that controls HAProxy router deployments; updating it can cause traffic disruption","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-controls-haproxy-router.json"},{"id":"ingresscontroller-custom-error-pages-503-404-only","text":"Custom error pages for IngressController require a ConfigMap in `openshift-config` namespace; only 503 and 404 error pages are customizable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-custom-error-pages-503-404-only.json"},{"id":"ingresscontroller-default-tls-profile-intermediate","text":"The default IngressController TLS security profile is Intermediate (TLS 1.2–1.3); profiles may change on OCP upgrade causing rolling router updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-default-tls-profile-intermediate.json"},{"id":"ingresscontroller-endpoint-strategy-platform-dependent","text":"Default IngressController endpoint publishing strategy is platform-dependent: LoadBalancerService (External) for AWS/Azure/GCP/IBMCloud/AlibabaCloud; HostNetwork for Libvirt and unknown platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-endpoint-strategy-platform-dependent.json"},{"id":"ingresscontroller-mtls-edge-reencrypt-only","text":"IngressController clientTLS (mTLS) works only with edge-terminated and reencrypt routes, not passthrough TLS or cleartext HTTP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-mtls-edge-reencrypt-only.json"},{"id":"ingresscontroller-replicas-default-by-topology","text":"IngressController default replicas: 1 for SingleReplica topology, 2 for HighlyAvailable topology.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-replicas-default-by-topology.json"},{"id":"ingresscontroller-sharding-via-selectors","text":"IngressControllers can be sharded using `namespaceSelector` and/or `routeSelector` to control which routes they serve.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-sharding-via-selectors.json"},{"id":"ingresscontroller-strategy-and-domain-immutable","text":"IngressController `endpointPublishingStrategy` and `domain` fields cannot be updated after creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-strategy-and-domain-immutable.json"},{"id":"ingresscontroller-wildcard-dns-aws-azure-gcp-only","text":"Wildcard DNS management by the Ingress Operator is only supported on AWS, Azure, and GCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ingresscontroller-wildcard-dns-aws-azure-gcp-only.json"},{"id":"init-containers-run-before-app-containers","text":"Init containers run before application containers and are used for setup tasks not present in the application image.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/init-containers-run-before-app-containers.json"},{"id":"init-containers-run-sequentially","text":"Init containers run sequentially and each must complete successfully before the next starts; all must complete before app containers start.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/init-containers-run-sequentially.json"},{"id":"init-containers-sequential-no-probes","text":"Init containers run sequentially, must all succeed, and cannot have probes or lifecycle hooks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/init-containers-sequential-no-probes.json"},{"id":"insights-advisor-location","text":"Insights Advisor is available at console.redhat.com/openshift/insights/advisor/ and displays identified issues with remediation steps","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insights-advisor-location.json"},{"id":"insights-operator-enabled-by-default","text":"The Insights Operator is installed and enabled by default on OpenShift Container Platform clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insights-operator-enabled-by-default.json"},{"id":"insights-operator-interval-2h","text":"The Insights Operator uploads its archive to OpenShift Cluster Manager every 2 hours","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insights-operator-interval-2h.json"},{"id":"insights-operator-report-interval-2h","text":"The Insights Operator reports configuration and component failure status to Red Hat every 2 hours.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insights-operator-report-interval-2h.json"},{"id":"insightsoperator-api-group","text":"The InsightsOperator API group is `operator.openshift.io/v1` — not `config.openshift.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insightsoperator-api-group.json"},{"id":"insightsoperator-config-override-precedence","text":"InsightsOperator config override precedence order: hardcoded defaults → observedConfig → unsupportedConfigOverrides.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insightsoperator-config-override-precedence.json"},{"id":"insightsoperator-empty-report-means-no-gathering","text":"An empty InsightsOperator `gatherStatus` or `insightsReport` means no data gathering has occurred — relevant for disconnected cluster scenarios.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insightsoperator-empty-report-means-no-gathering.json"},{"id":"insightsoperator-healthcheck-totalrisk-1-to-4","text":"InsightsOperator health check `totalRisk` ranges from 1–4; higher values indicate more critical issues.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insightsoperator-healthcheck-totalrisk-1-to-4.json"},{"id":"insightsoperator-management-state-values","text":"InsightsOperator `managementState` controls the operator lifecycle with values: Managed, Unmanaged, Removed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/insightsoperator-management-state-values.json"},{"id":"install-config-immutable-after-install","text":"All install-config.yaml parameters (networking, platform, etc.) are immutable after OpenShift cluster installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/install-config-immutable-after-install.json"},{"id":"install-config-params-immutable-after-install","text":"The `install-config.yaml` parameters cannot be changed after cluster installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/install-config-params-immutable-after-install.json"},{"id":"install-config-yaml-consumed","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/install-config-yaml-consumed.json"},{"id":"install-specific-operator-version-startingcsv-manual","text":"To install a specific Operator version, set `startingCSV` in the Subscription and use `installPlanApproval: Manual`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/install-specific-operator-version-startingcsv-manual.json"},{"id":"install-time-irreversible-constraints","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/install-time-irreversible-constraints.json"},{"id":"installplan-approval-automatic-or-manual","text":"InstallPlan `spec.approval` must be either `\"Automatic\"` or `\"Manual\"` — this is a required field.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-approval-automatic-or-manual.json"},{"id":"installplan-approval-controls-upgrades","text":"The InstallPlan approval strategy determines whether Operator upgrades are applied automatically or require admin approval.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-approval-controls-upgrades.json"},{"id":"installplan-approval-required-before-install","text":"InstallPlans must be approved (manually or automatically) before an Operator installs or upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-approval-required-before-install.json"},{"id":"installplan-attenuated-service-account","text":"The InstallPlan `attenuatedServiceAccountRef` field enables scoped/least-privilege operator installation using a specific service account.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-attenuated-service-account.json"},{"id":"installplan-is-namespaced","text":"InstallPlan is a namespaced resource, not cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-is-namespaced.json"},{"id":"installplan-required-spec-fields","text":"The three required spec fields for an InstallPlan are `approval`, `approved`, and `clusterServiceVersionNames`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/installplan-required-spec-fields.json"},{"id":"integrated-registry-namespace","text":"The OpenShift integrated image registry runs in the `openshift-image-registry` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/integrated-registry-namespace.json"},{"id":"integrated-registry-sends-image-notifications","text":"The integrated registry sends notifications to the cluster when new images are pushed, which can trigger builds and deployments automatically.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/integrated-registry-sends-image-notifications.json"},{"id":"internal-registry-configurable-storage","text":"The OpenShift internal registry is configurable and can be enabled, disabled, or pointed at different storage backends (e.g., PVCs, S3 object storage).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/internal-registry-configurable-storage.json"},{"id":"internal-registry-service-endpoint","text":"The internal registry service endpoint is `image-registry.openshift-image-registry.svc:5000`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/internal-registry-service-endpoint.json"},{"id":"ip-forwarding-restricted-default","text":"OVN-Kubernetes gatewayConfig.ipForwarding defaults to Restricted (only Kubernetes traffic); Global forwards all traffic on OVN-managed interfaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ip-forwarding-restricted-default.json"},{"id":"ipaddress-api-group-ipam-cluster-x","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddress-api-group-ipam-cluster-x.json"},{"id":"ipaddress-is-namespaced","text":"The IPAddress resource is namespace-scoped (not cluster-scoped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddress-is-namespaced.json"},{"id":"ipaddress-required-fields","text":"The IPAddress spec has four required fields: `address`, `claimRef`, `poolRef`, and `prefix`; `gateway` is optional.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddress-required-fields.json"},{"id":"ipaddressclaim-allocation-pattern","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddressclaim-allocation-pattern.json"},{"id":"ipaddressclaim-condition-required-fields","text":"IPAddressClaim status conditions have three required fields: `lastTransitionTime`, `status`, and `type`; the `severity` field is only set when `Status=False`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddressclaim-condition-required-fields.json"},{"id":"ipaddressclaim-ipaddress-claim-binding-pattern","text":"IPAddressClaim is the request object and IPAddress is the fulfilled allocation object, following a claim/binding pattern similar to PVC/PV.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddressclaim-ipaddress-claim-binding-pattern.json"},{"id":"ipaddressclaim-poolref-only-required-field","text":"The IPAddressClaim spec has only one required field: `poolRef`, which itself requires `kind` and `name`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipaddressclaim-poolref-only-required-field.json"},{"id":"ipi-vs-upi-infrastructure-management","text":"With IPI (Installer-Provisioned Infrastructure) the installer manages cloud resources directly, while with UPI (User-Provisioned Infrastructure) the user provisions all infrastructure manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipi-vs-upi-infrastructure-management.json"},{"id":"ipi-vs-upi-machine-management","text":"IPI installations on cloud providers get full MachineSet/MachineAPI support; UPI and bare-metal may have limited automation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipi-vs-upi-machine-management.json"},{"id":"ipi-vs-upi-responsibility","text":"IPI — the installer manages infrastructure (networking, LBs, DNS, storage, machines); UPI — the user provisions and manages all infrastructure","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipi-vs-upi-responsibility.json"},{"id":"ippool-range-allocations-required","text":"IPPool spec requires both `range` (CIDR notation) and `allocations` fields; each allocation requires `id` and `podref` (with `ifname` optional)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ippool-range-allocations-required.json"},{"id":"ippool-whereabouts-api-group","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ippool-whereabouts-api-group.json"},{"id":"ipsec-ca-valid-10-years-node-cert-5-years","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-ca-valid-10-years-node-cert-5-years.json"},{"id":"ipsec-cipher-aes-gcm-16-256","text":"IPsec uses AES-GCM-16-256 encryption cipher (ICV=16 bytes, key length=256 bits).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-cipher-aes-gcm-16-256.json"},{"id":"ipsec-disabled-by-default","text":"IPsec encryption is disabled by default in OpenShift Container Platform and must be explicitly enabled via the `networks.operator.openshift.io` CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-disabled-by-default.json"},{"id":"ipsec-external-requires-nmstate-butane-routingviahost","text":"External IPsec requires NMState Operator, Butane tool, and `routingViaHost=true` in `ovnKubernetesConfig.gatewayConfig`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-external-requires-nmstate-butane-routingviahost.json"},{"id":"ipsec-mtu-reduction-46-bytes","text":"Cluster MTU must be reduced by 46 bytes when IPsec is enabled to accommodate ESP header overhead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-mtu-reduction-46-bytes.json"},{"id":"ipsec-not-supported-hosted-control-planes","text":"IPsec is not supported on hosted control planes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-not-supported-hosted-control-planes.json"},{"id":"ipsec-not-supported-rhel-compute-nodes","text":"IPsec is not supported on RHEL compute nodes due to libreswan incompatibility.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-not-supported-rhel-compute-nodes.json"},{"id":"ipsec-pod-to-pod-transport-mode","text":"IPsec uses Transport mode (not Tunnel mode) for pod-to-pod encryption on the OVN-Kubernetes cluster network.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-pod-to-pod-transport-mode.json"},{"id":"ipsec-ports-udp500-udp4500-esp","text":"IPsec requires UDP 500 (IKE), UDP 4500 (NAT-T), and ESP protocol to be allowed through firewalls.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-ports-udp500-udp4500-esp.json"},{"id":"ipsec-same-node-never-encrypted","text":"Same-node pod traffic is never encrypted by IPsec.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-same-node-never-encrypted.json"},{"id":"ipsec-three-modes","text":"IPsec has three modes: Disabled (default), Full (pod-to-pod + external), and External (external traffic only).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-three-modes.json"},{"id":"ipsec-verify-ovn-nbctl","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipsec-verify-ovn-nbctl.json"},{"id":"ipvlan-shares-mac-macvlan-unique-mac","text":"ipvlan shares the parent MAC address across pods; macvlan gives each pod a unique MAC address.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ipvlan-shares-mac-macvlan-unique-mac.json"},{"id":"istag-format-colon-separated","text":"Image stream tags are formatted as `<imagestream-name>:<tag>` (colon-separated); image stream images are formatted as `<imagestream-name>@<image-id>` (at-sign separated).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/istag-format-colon-separated.json"},{"id":"istag-history-enables-rollback","text":"Image stream tags maintain a history stack — new images are placed at the top, enabling rollback to previous image versions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/istag-history-enables-rollback.json"},{"id":"itms-tag-mirroring-risk","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/itms-tag-mirroring-risk.json"},{"id":"jenkins-agent-base-image-includes-oc-cli","text":"The Jenkins base agent image includes headless Java, Jenkins JNLP client, git, tar, zip, nss, and the oc CLI tool.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-agent-base-image-includes-oc-cli.json"},{"id":"jenkins-agent-default-java-version-java-11","text":"The default Java version in the Jenkins agent image is java-11, configurable via the USE_JAVA_VERSION environment variable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-agent-default-java-version-java-11.json"},{"id":"jenkins-agent-pods-deleted-by-default","text":"Jenkins agent pods are deleted by default after build completion; pod retention options are never(), onFailure(), always(), and default().","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-agent-pods-deleted-by-default.json"},{"id":"jenkins-agent-registry-ocp-tools-4","text":"Jenkins agent images are available from registry.redhat.io/ocp-tools-4/jenkins-agent-base-rhel8.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-agent-registry-ocp-tools-4.json"},{"id":"jenkins-deploy-methods-openshift","text":"Jenkins can be deployed on OpenShift via Samples Operator templates or a certified Helm chart.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-deploy-methods-openshift.json"},{"id":"jenkins-deprecated-in-favor-of-tekton-pipelines","text":"Jenkins is on a deprecation path in OCP; OpenShift Pipelines (Tekton) is the strategic replacement for CI/CD.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-deprecated-in-favor-of-tekton-pipelines.json"},{"id":"jenkins-deprecated-in-ocp","text":"Jenkins is deprecated in OpenShift Container Platform in favor of OpenShift Pipelines (Tekton).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-deprecated-in-ocp.json"},{"id":"jenkins-has-dedicated-ocp-docs-section","text":"Jenkins has its own dedicated documentation section in OpenShift Container Platform, available across versions 3.0 through 4.21.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-has-dedicated-ocp-docs-section.json"},{"id":"jenkins-images-moved-ocp-tools-4-in-411","text":"Jenkins and Agent Base images moved from OCP install payload to ocp-tools-4 repository at registry.redhat.io starting in OCP 4.11.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-images-moved-ocp-tools-4-in-411.json"},{"id":"jenkins-imagestream-tags-upgrade-behavior","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-imagestream-tags-upgrade-behavior.json"},{"id":"jenkins-java-max-heap-param-overrides-dynamic","text":"JAVA_MAX_HEAP_PARAM takes precedence over dynamic heap calculation when set on Jenkins agent containers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-java-max-heap-param-overrides-dynamic.json"},{"id":"jenkins-jnlp-agent-default-heap-50-percent","text":"The Jenkins JNLP agent JVM uses 50% of container memory for heap by default (CONTAINER_HEAP_PERCENT=0.5); additional JVMs default to 25%.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-jnlp-agent-default-heap-50-percent.json"},{"id":"jenkins-maven-nodejs-agents-deprecated-410-removed-411","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-maven-nodejs-agents-deprecated-410-removed-411.json"},{"id":"jenkins-not-supported-outside-openshift","text":"Running Jenkins outside of OpenShift is not supported by Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-not-supported-outside-openshift.json"},{"id":"jenkins-oauth-integration","text":"Jenkins in OpenShift integrates with the OpenShift OAuth server for authentication.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-oauth-integration.json"},{"id":"jenkins-oc-cli-may-not-match-cluster-from-412","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-oc-cli-may-not-match-cluster-from-412.json"},{"id":"jenkins-pipeline-strategy-deprecated","text":"The `jenkinsPipelineStrategy` build strategy is deprecated; OpenShift Pipelines (Tekton) is the replacement","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-pipeline-strategy-deprecated.json"},{"id":"jenkins-pipeline-was-original-build-strategy","text":"Jenkins pipelines were the original `JenkinsPipeline` build strategy in OCP before Tekton/Pipelines became the recommended approach.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-pipeline-was-original-build-strategy.json"},{"id":"jenkins-updates-quarterly-latest-lts-only","text":"Jenkins images are updated quarterly aligned with upstream Jenkins LTS; only the latest LTS version is supported by Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/jenkins-updates-quarterly-latest-lts-only.json"},{"id":"job-backofflimit-default-6","text":"The Job `.spec.backoffLimit` defaults to 6 retries before marking the Job as failed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-backofflimit-default-6.json"},{"id":"job-backofflimit-default-6-cap-6min","text":"Job backoffLimit defaults to 6 retries with exponential backoff (10s, 20s, 40s…) capped at 6 minutes.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-backofflimit-default-6-cap-6min.json"},{"id":"job-batch-v1-api-group","text":"Jobs belong to the `batch/v1` API group and are namespaced resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-batch-v1-api-group.json"},{"id":"job-completionmode-nonindexed-default","text":"Job `.spec.completionMode` has two values: `NonIndexed` (default) and `Indexed`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-completionmode-nonindexed-default.json"},{"id":"job-pod-failure-policy-actions","text":"Pod failure policy actions are `FailJob`, `FailIndex`, `Ignore`, and `Count`; rules are evaluated in order with first match winning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-pod-failure-policy-actions.json"},{"id":"job-restart-never-vs-onfailure-behavior","text":"Job restartPolicy: Never creates new pods on failure (job controller retries), while restartPolicy: OnFailure restarts in-place on the same node (kubelet retries).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-restart-never-vs-onfailure-behavior.json"},{"id":"job-restart-policy-never-or-onfailure","text":"Pod `restartPolicy` in a Job template must be `Never` or `OnFailure` (not `Always`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-restart-policy-never-or-onfailure.json"},{"id":"job-restartpolicy-never-or-onfailure","text":"Job Pod `restartPolicy` must be `Never` or `OnFailure`; `Always` is not allowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-restartpolicy-never-or-onfailure.json"},{"id":"job-suspend-resets-starttime","text":"Suspending a Job resets its `startTime` and `activeDeadlineSeconds` timer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-suspend-resets-starttime.json"},{"id":"job-ttl-zero-immediate-delete","text":"Setting `ttlSecondsAfterFinished: 0` on a Job deletes it immediately after completion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/job-ttl-zero-immediate-delete.json"},{"id":"k8s-csr-approved-denied-immutable","text":"CSR `Approved` and `Denied` conditions are mutually exclusive and cannot be removed once added.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-csr-approved-denied-immutable.json"},{"id":"k8s-csr-cluster-scoped","text":"CertificateSigningRequest (CSR) objects are cluster-scoped (not namespaced) in the `certificates.k8s.io/v1` API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-csr-cluster-scoped.json"},{"id":"k8s-csr-min-expiration-600s","text":"The minimum `expirationSeconds` for a CertificateSigningRequest is 600 seconds (10 minutes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-csr-min-expiration-600s.json"},{"id":"k8s-csr-only-kubelet-client-auto-approved","text":"Of the three well-known Kubernetes CSR signers, only `kubernetes.io/kube-apiserver-client-kubelet` can be auto-approved by the `csrapproving` controller.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-csr-only-kubelet-client-auto-approved.json"},{"id":"k8s-csr-three-well-known-signers","text":"Kubernetes has three well-known CSR signers: `kubernetes.io/kube-apiserver-client`, `kubernetes.io/kube-apiserver-client-kubelet`, and `kubernetes.io/kubelet-serving`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-csr-three-well-known-signers.json"},{"id":"k8s-flowlayer-app-infra","text":"The `K8S_FlowLayer` field categorizes network traffic as either `app` or `infra`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-flowlayer-app-infra.json"},{"id":"k8s-zone-eviction-rate-reduction","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/k8s-zone-eviction-rate-reduction.json"},{"id":"keda-custom-metrics-autoscaling-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/keda-custom-metrics-autoscaling-model.json"},{"id":"keda-custom-resources","text":"Key KEDA custom resources are: ScaledObject, ScaledJob, KedaController, and TriggerAuthentication","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/keda-custom-resources.json"},{"id":"keda-metrictype-replaces-type","text":"In KEDA CPU/Memory triggers, the `type` field is removed and replaced by `metricType`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/keda-metrictype-replaces-type.json"},{"id":"keda-trigger-types","text":"Custom Metrics Autoscaler supported trigger types include: Cron, Kafka, Prometheus, Kubernetes workload, CPU, and Memory","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/keda-trigger-types.json"},{"id":"kedacontroller-auto-created","text":"The KedaController CR is automatically created during Custom Metrics Autoscaler Operator installation (since version 2.17.2)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kedacontroller-auto-created.json"},{"id":"kepler-crd-deprecated-for-powermonitor","text":"The `Kepler` CRD is deprecated and replaced by the `PowerMonitor` CRD (starting with power monitoring 0.5).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-crd-deprecated-for-powermonitor.json"},{"id":"kepler-default-metric-levels","text":"Default Kepler metric levels are `node`, `pod`, and `vm` (not `container` or `process`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-default-metric-levels.json"},{"id":"kepler-default-sample-rate-5s-staleness-500ms","text":"Kepler default sample rate is 5 seconds and default staleness is 500 milliseconds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-default-sample-rate-5s-staleness-500ms.json"},{"id":"kepler-default-security-mode-rbac","text":"PowerMonitor default security mode is `rbac` with TLS encryption, not `none`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-default-security-mode-rbac.json"},{"id":"kepler-runs-as-daemonset","text":"Kepler runs as a DaemonSet (one pod per node), as evidenced by DaemonSet-like scheduling status fields (desiredNumberScheduled, currentNumberScheduled, numberReady, etc.).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-runs-as-daemonset.json"},{"id":"kepler-runs-as-daemonset-linux-nodes","text":"Kepler runs as a DaemonSet and is scheduled only on Linux nodes by default (`kubernetes.io/os: linux`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kepler-runs-as-daemonset-linux-nodes.json"},{"id":"kernel-bonding-default-when-no-ovs-bonds","text":"Kernel bonding is the default bonding type when no OVS bonds are configured in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kernel-bonding-default-when-no-ovs-bonds.json"},{"id":"kernel-bonding-fail-over-mac-only-zero","text":"Kernel bonding only supports `fail_over_mac=0` (`none`); values `1` (`active`) and `2` (`follow`) are not supported by Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kernel-bonding-fail-over-mac-only-zero.json"},{"id":"kernel-memory-overhead-formula","text":"On high-CPU nodes, container kernel memory overhead follows the formula: `$(nproc) × 1/2 MiB` due to per-cgroup kmem_cache.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kernel-memory-overhead-formula.json"},{"id":"key-escrow-not-supported-ocp","text":"Key escrow is not supported by OpenShift Container Platform; only TPM and NBDE are supported encryption methods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/key-escrow-not-supported-ocp.json"},{"id":"kn-cli-for-openshift-serverless","text":"The `kn` CLI interacts with OpenShift Serverless components (Knative Serving and Eventing).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kn-cli-for-openshift-serverless.json"},{"id":"kn-cli-manages-serving-and-eventing","text":"The `kn` CLI manages both Knative Serving (services, revisions, traffic-splitting) and Knative Eventing (sources, triggers) components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kn-cli-manages-serving-and-eventing.json"},{"id":"kn-plugin-architecture-like-kubectl","text":"The `kn` CLI has a flexible plugin architecture modeled after `kubectl`'s plugin system.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kn-plugin-architecture-like-kubectl.json"},{"id":"knative-cli-kn-separate-from-oc","text":"The Knative CLI (`kn`) is a separate CLI from `oc`, covering Functions, Serving, and Eventing operations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/knative-cli-kn-separate-from-oc.json"},{"id":"knative-eventing-components","text":"Knative Eventing handles event-driven architectures via event sources, brokers, triggers, and channels.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/knative-eventing-components.json"},{"id":"knative-eventing-event-driven","text":"Knative Eventing provides event-driven architecture capabilities (event sources, brokers, triggers) in OpenShift Serverless.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/knative-eventing-event-driven.json"},{"id":"knative-serving-scale-to-zero","text":"Knative Serving handles request-driven compute — deploying and auto-scaling serverless containers, including scale-to-zero.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/knative-serving-scale-to-zero.json"},{"id":"krew-works-with-oc-without-operator","text":"Krew works with `oc` even without the CLI Manager Operator installed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/krew-works-with-oc-without-operator.json"},{"id":"kube-storage-version-migrator-purpose","text":"The KubeStorageVersionMigrator operator manages a component that re-writes stored resources in etcd to their current storage version after API schema changes during upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kube-storage-version-migrator-purpose.json"},{"id":"kube-version-sorting-order","text":"Kubernetes \"kube-like\" version sorting order: GA > beta > alpha, then by major/minor version number (e.g., v10 > v2 > v1 > v11beta2 > v3beta1 > v12alpha1).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kube-version-sorting-order.json"},{"id":"kubeadmin-password-location","text":"The kubeadmin password is located at `<install_directory>/auth/kubeadmin-password`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeadmin-password-location.json"},{"id":"kubeapiserver-cr-api-group","text":"The KubeAPIServer custom resource uses the API group `operator.openshift.io/v1`, not `config.openshift.io`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeapiserver-cr-api-group.json"},{"id":"kubeapiserver-singleton-name-cluster","text":"The KubeAPIServer operator resource name is always `cluster` (singleton pattern for OpenShift operators)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeapiserver-singleton-name-cluster.json"},{"id":"kubelet-container-network-metrics-count-eight","text":"There are 8 standard kubelet `container_network_*` metrics: 4 receive and 4 transmit (bytes, errors, packets, packets_dropped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-container-network-metrics-count-eight.json"},{"id":"kubelet-default-log-level-2","text":"The default kubelet log verbosity level in OpenShift is 2 (KUBELET_LOG_LEVEL=2).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-default-log-level-2.json"},{"id":"kubelet-evicts-on-ephemeral-storage-exceeded","text":"Kubelet evicts pods when individual container ephemeral storage usage exceeds its limit or total pod usage exceeds the sum of all container limits.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-evicts-on-ephemeral-storage-exceeded.json"},{"id":"kubelet-log-levels-debug-0-4-trace-5-8","text":"Kubelet log levels 0–4 are debug-level; levels 5–8 are trace-level.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-log-levels-debug-0-4-trace-5-8.json"},{"id":"kubelet-onetime-log-change-dropin-path","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-onetime-log-change-dropin-path.json"},{"id":"kubelet-only-manages-k8s-created-containers","text":"The kubelet only manages containers created by Kubernetes, not other containers on the node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-only-manages-k8s-created-containers.json"},{"id":"kubelet-persistent-log-change-machineconfig","text":"Persistent kubelet log level changes require a MachineConfig object with the machineconfiguration.openshift.io/role label targeting the correct pool (master/worker).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-persistent-log-change-machineconfig.json"},{"id":"kubelet-runs-on-nodes","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-runs-on-nodes.json"},{"id":"kubelet-version-skew-rules","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubelet-version-skew-rules.json"},{"id":"kubeletconfig-containerruntimeconfig-generate-machineconfig","text":"KubeletConfig and ContainerRuntimeConfig are higher-level abstractions that generate MachineConfig objects under the hood via the Machine Config Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-containerruntimeconfig-generate-machineconfig.json"},{"id":"kubeletconfig-cr-for-kubelet-params","text":"KubeletConfig CRs are the supported way to modify kubelet parameters in OCP; direct kubelet config editing is not supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-cr-for-kubelet-params.json"},{"id":"kubeletconfig-for-kubelet-params","text":"KubeletConfig is the dedicated CR for managing Kubelet parameters (e.g., pod limits, eviction thresholds), separate from MachineConfig.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-for-kubelet-params.json"},{"id":"kubeletconfig-for-kubelet-settings","text":"KubeletConfig CR is used for managing Kubelet configuration on nodes; ContainerRuntimeConfig CR is used for CRI-O settings","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-for-kubelet-settings.json"},{"id":"kubeletconfig-nil-selector-selects-no-pools","text":"A nil `machineConfigPoolSelector` in KubeletConfig selects no pools — it must be explicitly set for the config to take effect.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-nil-selector-selects-no-pools.json"},{"id":"kubeletconfig-no-api-validation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-no-api-validation.json"},{"id":"kubeletconfig-tls-default-from-apiserver","text":"KubeletConfig `tlsSecurityProfile` defaults to the cluster-wide setting from `apiservers.config.openshift.io/cluster` when unset.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-tls-default-from-apiserver.json"},{"id":"kubeletconfig-tls-profiles-old-intermediate-only","text":"KubeletConfig only supports Old and Intermediate TLS profiles; Modern is not supported and maximum `minTLSVersion` is `VersionTLS12`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/kubeletconfig-tls-profiles-old-intermediate-only.json"},{"id":"latest-available-revision-triggers-redeployment","text":"A new latestAvailableRevision value on OpenShiftAPIServer triggers pod redeployments (used as suffix for revisioned secrets like encryption-config)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/latest-available-revision-triggers-redeployment.json"},{"id":"lb-required-ports-6443-22623-80-443","text":"The load balancer for OCP must proxy ports 6443 (Kubernetes API), 22623 (Machine Config Server), 80, and 443.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lb-required-ports-6443-22623-80-443.json"},{"id":"ldap-group-sync-command","text":"LDAP group sync (`oc adm groups sync`) automatically creates and maintains Group objects from external directory services.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ldap-group-sync-command.json"},{"id":"ldap-insecure-false-starttls","text":"LDAP with `insecure: false` and `ldap://` URL upgrades to TLS via StartTLS; `ldaps://` always uses TLS regardless of `insecure` setting","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ldap-insecure-false-starttls.json"},{"id":"lease-api-group-coordination-k8s-io-v1","text":"The Lease resource belongs to the `coordination.k8s.io/v1` API group, not core/v1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lease-api-group-coordination-k8s-io-v1.json"},{"id":"lease-namespaced-resource","text":"Leases are namespaced resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lease-namespaced-resource.json"},{"id":"lease-transitions-tracks-holder-changes","text":"The `leaseTransitions` field on a Lease tracks the number of times the lease has changed holders.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lease-transitions-tracks-holder-changes.json"},{"id":"lease-used-for-leader-election-and-node-heartbeats","text":"Leases are used for leader election among controller replicas and for node heartbeats (kubelets maintain Lease objects in the `kube-node-lease` namespace).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lease-used-for-leader-election-and-node-heartbeats.json"},{"id":"legacy-dc-build-workflow-functional","text":"The OpenShift build system supports legacy DeploymentConfig-based workflows where BuildConfigs trigger rolling deployments through the DC mechanism.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/legacy-dc-build-workflow-functional.json"},{"id":"lifecycle-constrained-across-heterogeneous-fleet","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lifecycle-constrained-across-heterogeneous-fleet.json"},{"id":"lifecycle-hook-failure-policies","text":"Deployment lifecycle hook failure policies are: Abort (fail deployment), Retry (retry until success), and Ignore (ignore failure and continue).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lifecycle-hook-failure-policies.json"},{"id":"lightspeed-ai-assistant-operator","text":"OpenShift Lightspeed is an AI-powered assistant delivered as a separate operator (version 1.0) with its own versioning independent of OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-ai-assistant-operator.json"},{"id":"lightspeed-genai-assistant","text":"OpenShift Lightspeed is a generative AI-powered virtual assistant accessed through a natural-language interface in the OpenShift web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-genai-assistant.json"},{"id":"lightspeed-introduced-ocp-417","text":"OpenShift Lightspeed is available as of OpenShift Container Platform 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-introduced-ocp-417.json"},{"id":"lightspeed-is-genai-virtual-assistant","text":"OpenShift Lightspeed is a generative AI-powered virtual assistant that provides a natural-language interface within the OpenShift web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-is-genai-virtual-assistant.json"},{"id":"lightspeed-separate-release-cadence","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-separate-release-cadence.json"},{"id":"lightspeed-version-compatibility-required","text":"OpenShift Lightspeed requires explicit verification of version compatibility with the underlying OpenShift Container Platform before installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-version-compatibility-required.json"},{"id":"lightspeed-web-console-not-cli","text":"OpenShift Lightspeed is accessed through the OpenShift web console, not the oc CLI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lightspeed-web-console-not-cli.json"},{"id":"limitrange-per-pod-container-defaults","text":"LimitRange sets default, minimum, and maximum resource constraints per pod or container within a namespace, complementing ResourceQuota's aggregate limits.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/limitrange-per-pod-container-defaults.json"},{"id":"limitrange-sets-per-pod-container-defaults-bounds","text":"LimitRange sets default resource values and min/max constraints on individual pods and containers within a namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/limitrange-sets-per-pod-container-defaults-bounds.json"},{"id":"limitrange-vs-resourcequota","text":"LimitRange sets default resource requests/limits per container in a project. ResourceQuota sets project-wide totals. They serve different purposes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/limitrange-vs-resourcequota.json"},{"id":"link-pull-secret-to-sa-command","text":"Pull secrets are linked to service accounts with `oc secrets link <sa> <secret> --for=pull`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/link-pull-secret-to-sa-command.json"},{"id":"list-available-operators-command","text":"`oc get packagemanifests -n openshift-marketplace` lists all available Operators from OperatorHub catalogs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-available-operators-command.json"},{"id":"list-config-resources-command","text":"`oc api-resources -o name | grep config.openshift.io` lists all cluster configuration resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-config-resources-command.json"},{"id":"list-machines-command","text":"The command to list machines is `oc get machine -n openshift-machine-api`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-machines-command.json"},{"id":"list-oauth-api-resources-cmd","text":"`oc api-resources --api-group=oauth.openshift.io` lists all OAuth API resources in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-oauth-api-resources-cmd.json"},{"id":"list-objects-share-uniform-structure","text":"All Kubernetes/OpenShift List API responses share four fields: `apiVersion`, `kind`, `items` (required), and `metadata` (ListMeta).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-objects-share-uniform-structure.json"},{"id":"list-packagemanifests-command","text":"Command to discover available Operators: `oc get packagemanifests -n openshift-marketplace`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/list-packagemanifests-command.json"},{"id":"local-prefix-means-namespace-scoped-authz","text":"Authorization resources prefixed with \"Local\" (e.g., LocalSubjectAccessReview, LocalResourceAccessReview) are namespace-scoped; non-local variants operate cluster-wide.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-prefix-means-namespace-scoped-authz.json"},{"id":"local-storage-all-rwo-only","text":"All three local storage solutions (HPP, LSO, LVM Storage) only support ReadWriteOnce (RWO) access mode — none support RWX.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-storage-all-rwo-only.json"},{"id":"local-storage-device-paths-use-by-id","text":"Device paths in local storage configurations should use `/dev/disk/by-id/` for stable identification.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-storage-device-paths-use-by-id.json"},{"id":"local-storage-supported-filesystems-ext4-xfs","text":"Supported filesystems for LSO and LVM Storage are ext4 and xfs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-storage-supported-filesystems-ext4-xfs.json"},{"id":"local-volume-operator-namespace","text":"The Local Volume Operator is installed in the `openshift-local-storage` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-volume-operator-namespace.json"},{"id":"local-volumes-no-dynamic-provisioning","text":"Local volumes in OpenShift do NOT support dynamic provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/local-volumes-no-dynamic-provisioning.json"},{"id":"localhost-recovery-kubeconfig-fallback","text":"The `localhost-recovery.kubeconfig` file on a control plane node can be used when `admin.kubeconfig` is unavailable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localhost-recovery-kubeconfig-fallback.json"},{"id":"localnet-requires-bridge-mappings-via-nncp","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localnet-requires-bridge-mappings-via-nncp.json"},{"id":"localresourceaccessreview-answers-who-can","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localresourceaccessreview-answers-who-can.json"},{"id":"localresourceaccessreview-is-namespace-scoped","text":"LocalResourceAccessReview is namespace-scoped; the namespace is part of the URL path (`POST /apis/authorization.openshift.io/v1/namespaces/{namespace}/localresourceaccessreviews`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localresourceaccessreview-is-namespace-scoped.json"},{"id":"localresourceaccessreview-vs-localsubjectaccessreview","text":"LocalResourceAccessReview asks \"who can do X?\" while LocalSubjectAccessReview asks \"can user Y do X?\"","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localresourceaccessreview-vs-localsubjectaccessreview.json"},{"id":"localsubjectaccessreview-allowed-false-denied-false-no-opinion","text":"When LocalSubjectAccessReview returns `allowed=false` and `denied=false`, the authorizer has no opinion — this is distinct from an explicit denial.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localsubjectaccessreview-allowed-false-denied-false-no-opinion.json"},{"id":"localsubjectaccessreview-api-group-k8s","text":"LocalSubjectAccessReview uses the upstream Kubernetes API group `authorization.k8s.io/v1`, not the OpenShift-specific `authorization.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localsubjectaccessreview-api-group-k8s.json"},{"id":"localsubjectaccessreview-exactly-one-attribute-type","text":"LocalSubjectAccessReview spec must set exactly one of `resourceAttributes` (for resource requests) or `nonResourceAttributes` (for non-resource URL requests).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/localsubjectaccessreview-exactly-one-attribute-type.json"},{"id":"logging-5-to-6-upgrade-not-automatic","text":"The upgrade from OpenShift Logging 5.x to 6.x is a documented manual migration procedure, not an in-place automatic upgrade.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-5-to-6-upgrade-not-automatic.json"},{"id":"logging-58-eol-date","text":"OpenShift Logging 5.8 reached End of Life on November 3, 2025 and is replaced by Logging 6.0.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-58-eol-date.json"},{"id":"logging-6x-requires-three-operators","text":"OpenShift Logging 6.x installation requires three operators: Loki Operator, Red Hat OpenShift Logging Operator, and Cluster Observability Operator (COO).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-6x-requires-three-operators.json"},{"id":"logging-6x-uses-loki-not-elasticsearch","text":"OpenShift Logging 6.x uses Loki (via LokiStack) as the default log store, replacing Elasticsearch from 5.x.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-6x-uses-loki-not-elasticsearch.json"},{"id":"logging-architecture-three-tier-evolution","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-architecture-three-tier-evolution.json"},{"id":"logging-collector-http-receiver","text":"The OpenShift Logging collector (Vector) can be configured as an HTTP server to receive logs as a webhook input.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-collector-http-receiver.json"},{"id":"logging-elasticsearch-fluentd-kibana-deprecated","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-elasticsearch-fluentd-kibana-deprecated.json"},{"id":"logging-four-functions","text":"OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-four-functions.json"},{"id":"logging-logfilemetricexporter-manual","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-logfilemetricexporter-manual.json"},{"id":"logging-multi-namespace-clusterlogforwarder","text":"In Logging 5.8, multiple isolated RBAC-protected ClusterLogForwarder CRs can be deployed in any namespace, not just openshift-logging.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-multi-namespace-clusterlogforwarder.json"},{"id":"logging-not-installed-by-default","text":"OpenShift Logging is not installed by default — it requires installing the Red Hat OpenShift Logging operator (and typically a log store operator like Loki).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-not-installed-by-default.json"},{"id":"logging-operator-not-default","text":"The OpenShift Logging Operator is not installed by default and must be installed separately.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-operator-not-default.json"},{"id":"logging-separate-product-from-ocp","text":"Red Hat OpenShift Logging is a separate product with its own release cycle, not bundled directly under OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-separate-product-from-ocp.json"},{"id":"logging-separate-release-cycle","text":"OpenShift Logging is a separate installable component with its own release cycle, independent from core OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-separate-release-cycle.json"},{"id":"logging-subscription-channel-stable-xy","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-subscription-channel-stable-xy.json"},{"id":"logging-three-log-categories","text":"OpenShift has three categories of logs: infrastructure logs, application logs, and audit logs.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-three-log-categories.json"},{"id":"logging-uninstall-requires-uiplugin-removal","text":"Uninstalling OpenShift Logging requires removing the operators and the UIPlugin resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/logging-uninstall-requires-uiplugin-removal.json"},{"id":"loki-default-rate-limits","text":"Default Loki `perStreamRateLimit` is 3 MB/sec and `perStreamRateLimitBurst` is 15; HTTP 429 errors are fixed by increasing these in the LokiStack CR","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/loki-default-rate-limits.json"},{"id":"loki-empty-ring-fix-reinstall","text":"Loki \"empty ring\" error after reinstall is fixed by removing old PVCs and reinstalling LokiStack","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/loki-empty-ring-fix-reinstall.json"},{"id":"loki-max-batch-size-98mib","text":"Red Hat Loki Operator sets max message size to 100 MiB; `spec.loki.batchSize` must not exceed 98 MiB","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/loki-max-batch-size-98mib.json"},{"id":"loki-network-tenant-orgid","text":"The Loki tenant for Network Observability uses `X-Scope-OrgID: network`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/loki-network-tenant-orgid.json"},{"id":"lokistack-1x-extra-small-100gb","text":"LokiStack supports a 1x.extra-small deployment size for up to 100GB/day log ingestion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lokistack-1x-extra-small-100gb.json"},{"id":"lokistack-recommended-log-store","text":"LokiStack is the recommended log storage backend, replacing the deprecated Elasticsearch/Kibana stack.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lokistack-recommended-log-store.json"},{"id":"lokistack-supports-node-scheduling","text":"LokiStack and log forwarding resources can be scheduled to specific nodes using node selectors and tolerations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lokistack-supports-node-scheduling.json"},{"id":"lookuppolicy-local-namespace-scoped","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lookuppolicy-local-namespace-scoped.json"},{"id":"lso-installs-openshift-local-storage-namespace","text":"The Local Storage Operator (LSO) installs into the `openshift-local-storage` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lso-installs-openshift-local-storage-namespace.json"},{"id":"lso-uses-localvolume-cr-static-provisioning","text":"LSO uses the `LocalVolume` CR (apiVersion `local.storage.openshift.io/v1`) and only supports static provisioning — not dynamic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lso-uses-localvolume-cr-static-provisioning.json"},{"id":"lvm-storage-only-local-dynamic-provisioning","text":"LVM Storage is the only local storage solution in OpenShift that supports dynamic provisioning, PVC expansion, volume snapshots, and volume clones.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lvm-storage-only-local-dynamic-provisioning.json"},{"id":"lvm-storage-uses-topolvm-csi","text":"LVM Storage uses the TopoLVM CSI driver for dynamic provisioning and topology awareness.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/lvm-storage-uses-topolvm-csi.json"},{"id":"machine-api-declarative-node-management","text":"Machine APIs are the declarative interface for managing compute node lifecycle (creation, scaling, deletion) in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-declarative-node-management.json"},{"id":"machine-api-group-v1beta1","text":"The Machine, MachineSet, and MachineHealthCheck resources use API group `machine.openshift.io/v1beta1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-group-v1beta1.json"},{"id":"machine-api-handles-post-install-provisioning","text":"The Machine API handles all node host provisioning after cluster installation (not during installation).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-handles-post-install-provisioning.json"},{"id":"machine-api-key-objects","text":"Key Machine API objects are: Machine, MachineSet, MachineHealthCheck, MachineAutoscaler, and ClusterAutoscaler","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-key-objects.json"},{"id":"machine-api-namespace","text":"Machine API objects reside in the `openshift-machine-api` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-namespace.json"},{"id":"machine-api-operator-five-resources","text":"The Machine API Operator provisions exactly five resources: MachineSet, Machine, ClusterAutoscaler, MachineAutoscaler, and MachineHealthCheck.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-operator-five-resources.json"},{"id":"machine-api-requires-cluster-admin","text":"Machine API operations require cluster-admin privileges.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-requires-cluster-admin.json"},{"id":"machine-api-requires-ipi","text":"The Machine API is only operational on installer-provisioned infrastructure (IPI); UPI installations do not have compute machine sets by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-requires-ipi.json"},{"id":"machine-api-scaling-hierarchy","text":"The Machine API scaling hierarchy is: ClusterAutoscaler → MachineAutoscaler → MachineSet → Machine → Node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-scaling-hierarchy.json"},{"id":"machine-api-two-api-groups","text":"Machine management uses two API groups: `machineconfiguration.openshift.io/v1` for node/OS-level configuration and `machine.openshift.io` (v1/v1beta1) for machine lifecycle.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-two-api-groups.json"},{"id":"machine-api-version-v1beta1","text":"Machine objects use API version `machine.openshift.io/v1beta1`, kind `Machine`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-api-version-v1beta1.json"},{"id":"machine-approver-worker-csrs","text":"The Cluster Machine Approver auto-approves CSRs for new worker nodes; the bootstrap node approves control plane CSRs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-approver-worker-csrs.json"},{"id":"machine-autoscaler-namespace","text":"MachineAutoscaler resources must be created in the `openshift-machine-api` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-autoscaler-namespace.json"},{"id":"machine-configs-applied-lexicographic-order","text":"Machine configs are applied in lexicographic order (00* through 99*); last file wins for conflicts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-configs-applied-lexicographic-order.json"},{"id":"machine-delete-annotation","text":"The annotation `machine.openshift.io/delete-machine=\"true\"` marks a machine for preferential deletion when scaling down a MachineSet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-delete-annotation.json"},{"id":"machine-deletion-order","text":"Machine deletion order is: preDrain hooks → drain node → preTerminate hooks → remove cloud instance → delete Node object.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-deletion-order.json"},{"id":"machine-error-fields-terminal-only","text":"Machine `errorMessage`/`errorReason` fields are set only for terminal (non-transient) problems requiring manual intervention","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-error-fields-terminal-only.json"},{"id":"machine-failed-phase-unrecoverable","text":"The Failed machine phase indicates an unrecoverable problem such as the cloud provider deleting the instance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-failed-phase-unrecoverable.json"},{"id":"machine-lifecycle-hooks-two-types","text":"Machine lifecycle hooks have two types: preDrain (blocks drain and termination) and preTerminate (blocks termination, runs after drain completes)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-lifecycle-hooks-two-types.json"},{"id":"machine-machineset-machinehealthcheck-v1beta1","text":"Machine, MachineSet, and MachineHealthCheck are `machine.openshift.io/v1beta1` (Compatibility Level 2), while ControlPlaneMachineSet is `machine.openshift.io/v1` (Compatibility Level 1).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-machineset-machinehealthcheck-v1beta1.json"},{"id":"machine-management-varies-by-install-type","text":"Machine management capabilities differ by installation type — IPI installations typically offer more automation than UPI","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-management-varies-by-install-type.json"},{"id":"machine-management-varies-by-installation-type","text":"Not all machine management tasks are available in all installation types; some features require IPI (Installer-Provisioned Infrastructure).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-management-varies-by-installation-type.json"},{"id":"machine-one-to-one-with-node","text":"Each Machine object has a 1:1 relationship with a Kubernetes Node, linked via `status.nodeRef` and `providerID`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-one-to-one-with-node.json"},{"id":"machine-phases","text":"Machine lifecycle phases are: Failed, Provisioning, Provisioned, Running, Deleting","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-phases.json"},{"id":"machine-phases-five-states","text":"Machines in OpenShift have five lifecycle phases: Provisioning, Provisioned, Running, Deleting, and Failed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-phases-five-states.json"},{"id":"machine-phases-lifecycle","text":"Machine phases progress through: Provisioning → Provisioned → Running → Deleting.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-phases-lifecycle.json"},{"id":"machine-providerid-autoscaler","text":"The providerID field on a Machine must match the Node's provider ID and is used by the cluster autoscaler to detect unregistered machines","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-providerid-autoscaler.json"},{"id":"machine-running-phase-noderef-populated","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-running-phase-noderef-populated.json"},{"id":"machine-skip-drain-annotation","text":"The annotation `machine.openshift.io/exclude-node-draining` on a Machine skips node draining during deletion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-skip-drain-annotation.json"},{"id":"machine-taints-additive-reconciled","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machine-taints-additive-reconciled.json"},{"id":"machineautoscaler-api-group","text":"MachineAutoscaler API group is `autoscaling.openshift.io/v1beta1` — an OpenShift-specific CR, not upstream Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-api-group.json"},{"id":"machineautoscaler-namespace-openshift-machine-api","text":"MachineAutoscaler is namespaced, typically deployed in `openshift-machine-api`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-namespace-openshift-machine-api.json"},{"id":"machineautoscaler-namespaced-per-machineset","text":"MachineAutoscaler is a namespaced resource tied to specific MachineSets, defining min/max replicas for those MachineSets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-namespaced-per-machineset.json"},{"id":"machineautoscaler-references-machineset","text":"MachineAutoscaler scales MachineSets to add or remove worker nodes and references a specific MachineSet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-references-machineset.json"},{"id":"machineautoscaler-required-fields","text":"MachineAutoscaler spec has three required fields: `minReplicas`, `maxReplicas`, and `scaleTargetRef`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-required-fields.json"},{"id":"machineautoscaler-requires-clusterautoscaler","text":"MachineAutoscaler requires the ClusterAutoscaler to be enabled in order to take effect","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-requires-clusterautoscaler.json"},{"id":"machineautoscaler-same-namespace-target","text":"MachineAutoscaler `scaleTargetRef` requires `kind` and `name` but not namespace — the target must be in the same namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-same-namespace-target.json"},{"id":"machineautoscaler-v1beta1","text":"MachineAutoscaler uses `autoscaling.openshift.io/v1beta1` (not yet GA), while ClusterAutoscaler is at `v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineautoscaler-v1beta1.json"},{"id":"machineconfig-crs-in-siteconfig-extramanifests","text":"Best practice is to put MachineConfig CRs in `SiteConfig` `extraManifests` so they are applied at install time rather than post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-crs-in-siteconfig-extramanifests.json"},{"id":"machineconfig-ignition-version-3-2-0","text":"MachineConfig objects use Ignition spec version 3.2.0 for defining systemd unit drop-ins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-ignition-version-3-2-0.json"},{"id":"machineconfig-targets-os-level","text":"MachineConfig targets OS-level settings including systemd units, files on disk, and kernel arguments on RHCOS nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-targets-os-level.json"},{"id":"machineconfig-three-cr-types","text":"Three distinct CR types control node configuration: MachineConfig (OS-level), KubeletConfig (kubelet), ContainerRuntimeConfig (CRI-O)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-three-cr-types.json"},{"id":"machineconfig-three-primary-crs","text":"MachineConfig, KubeletConfig, and ContainerRuntimeConfig are the three primary custom resources for node-level configuration in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-three-primary-crs.json"},{"id":"machineconfig-triggers-node-reboot","text":"Changes applied via MachineConfig trigger node reboots, rolled out by the MCO through MachineConfigPools","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-triggers-node-reboot.json"},{"id":"machineconfig-triggers-rolling-reboot","text":"Changes applied via MachineConfig typically trigger a rolling node reboot across the affected MachineConfigPool.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfig-triggers-rolling-reboot.json"},{"id":"machineconfigpool-groups-nodes","text":"MachineConfigPool groups nodes that share the same machine configuration (e.g., worker, master pools)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfigpool-groups-nodes.json"},{"id":"machineconfigpool-groups-nodes-by-role","text":"MachineConfigPools group nodes that share the same machine configuration, using role labels like `worker` or `master`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfigpool-groups-nodes-by-role.json"},{"id":"machineconfigpool-groups-nodes-for-rollout","text":"MachineConfigPool groups nodes that share the same MachineConfig and controls configuration rollout (e.g., `master` and `worker` pools).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineconfigpool-groups-nodes-for-rollout.json"},{"id":"machinehealthcheck-detects-deletes-replaces","text":"MachineHealthCheck detects unhealthy machines, deletes them, and provisions replacements on supported platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machinehealthcheck-detects-deletes-replaces.json"},{"id":"machineosconfig-one-per-pool","text":"A separate MachineOSConfig CR is needed for each machine config pool when using on-cluster image layering.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineosconfig-one-per-pool.json"},{"id":"machines-namespace-openshift-machine-api","text":"Machine and MachineSet resources managed by the Machine API live in the `openshift-machine-api` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machines-namespace-openshift-machine-api.json"},{"id":"machines-namespaced-openshift-machine-api","text":"Machine, MachineSet, and MachineHealthCheck are namespaced resources typically in the `openshift-machine-api` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machines-namespaced-openshift-machine-api.json"},{"id":"machineset-api-resource-name","text":"The full API resource name for machine sets is `machinesets.machine.openshift.io` (not just `machinesets`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-api-resource-name.json"},{"id":"machineset-changes-not-retroactive","text":"MachineSet CR changes only affect newly created machines; existing machines are not updated when the MachineSet is modified.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-changes-not-retroactive.json"},{"id":"machineset-default-replicas-1-deletepolicy-random","text":"MachineSet defaults: `replicas` is 1, `deletePolicy` is Random; valid delete policies are Random, Newest, Oldest","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-default-replicas-1-deletepolicy-random.json"},{"id":"machineset-deletion-policy-default-random","text":"MachineSet deletion policy defaults to Random; other options are Newest and Oldest.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-deletion-policy-default-random.json"},{"id":"machineset-has-scale-subresource","text":"MachineSet has a dedicated `/scale` sub-resource for scaling operations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-has-scale-subresource.json"},{"id":"machineset-namespace-openshift-machine-api","text":"All MachineSet and Machine resources live in the `openshift-machine-api` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-namespace-openshift-machine-api.json"},{"id":"machineset-rolling-replacement-pattern","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-rolling-replacement-pattern.json"},{"id":"machineset-scoped-single-availability-zone","text":"Each MachineSet is scoped to a single availability zone; the installer distributes MachineSets across zones automatically.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-scoped-single-availability-zone.json"},{"id":"machineset-selector-must-match-template","text":"MachineSet selector must match the machine template's labels — a mismatch will cause issues","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/machineset-selector-must-match-template.json"},{"id":"management-state-unmanaged-stops-reconciliation","text":"Setting managementState to Unmanaged on an operator.openshift.io/v1 resource stops the operator from reconciling changes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/management-state-unmanaged-stops-reconciliation.json"},{"id":"management-state-values","text":"The `managementState` field on OpenShift operator resources controls operator behavior with values: Managed (active), Unmanaged (hands-off), Removed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/management-state-values.json"},{"id":"managementstate-controls-operator-behavior","text":"The `managementState` field on operator.openshift.io/v1 resources controls whether the operator actively manages its component, with values: `Managed`, `Unmanaged`, `Removed`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/managementstate-controls-operator-behavior.json"},{"id":"manual-approval-affects-all-operators-in-namespace","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/manual-approval-affects-all-operators-in-namespace.json"},{"id":"manual-approval-all-operators-in-namespace","text":"Setting manual approval strategy applies to all Operators in the same namespace, not just the one being configured.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/manual-approval-all-operators-in-namespace.json"},{"id":"manual-approval-required-token-auth-clouds","text":"Token-based auth clusters (AWS STS, Azure Workload ID, GCP Workload Identity) require Manual approval strategy for operator Subscriptions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/manual-approval-required-token-auth-clouds.json"},{"id":"master-worker-label-selectors","text":"The label selector for control plane nodes is `node-role.kubernetes.io/master`; for workers it is `node-role.kubernetes.io/worker`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/master-worker-label-selectors.json"},{"id":"max-ebs-volumes-per-node-39","text":"The maximum number of EBS volumes per node is 39, with in-tree and CSI volumes counted separately.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/max-ebs-volumes-per-node-39.json"},{"id":"maxunavailable-default-one-for-mcp","text":"The `maxUnavailable` default is `1` for all machine config pools; Red Hat recommends never setting it to `3` for the control plane pool.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/maxunavailable-default-one-for-mcp.json"},{"id":"mcd-four-critical-metrics","text":"Four critical MCD metrics that can block updates and upgrades: mcd_drain_err, mcd_pivot_err, mcd_kubelet_state, and mcd_reboot_err.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-four-critical-metrics.json"},{"id":"mcd-kubelet-health-threshold-2","text":"The MCD kubelet health failure threshold is 2 — exceeding it signals a problem via the mcd_kubelet_state metric.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-kubelet-health-threshold-2.json"},{"id":"mcd-metrics-available-since-ocp43","text":"MCD metrics have been available since OpenShift Container Platform 4.3.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-metrics-available-since-ocp43.json"},{"id":"mcd-namespace-openshift-machine-config-operator","text":"MCD logs are in namespace openshift-machine-config-operator, container machine-config-daemon.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-namespace-openshift-machine-config-operator.json"},{"id":"mcd-runs-as-daemonset","text":"The Machine Config Daemon (MCD) runs as a DaemonSet with one instance per node in the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-runs-as-daemonset.json"},{"id":"mcd-three-states","text":"The Machine Config Daemon has exactly three states: Done, Working, and Degraded.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcd-three-states.json"},{"id":"mce-210-rhel9-base-image","text":"The `multicluster-operators-subscription` image uses RHEL 9 base starting with MCE 2.10 (RHACM 2.10+); earlier versions use RHEL 8.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mce-210-rhel9-base-image.json"},{"id":"mco-boot-images-only-machinesets","text":"The only valid apiGroup for managedBootImages machineManagers is machine.openshift.io and the only valid resource is machinesets","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-boot-images-only-machinesets.json"},{"id":"mco-default-revision-limit-five","text":"failedRevisionLimit and succeededRevisionLimit default to 5 when set to 0 or unset; -1 means unlimited","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-default-revision-limit-five.json"},{"id":"mco-disruption-action-types","text":"Valid node disruption action types are Reboot, Drain, Reload, Restart, DaemonReload, and None — Reboot and None cannot be combined with other actions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-disruption-action-types.json"},{"id":"mco-disruption-policy-limits","text":"nodeDisruptionPolicy supports a maximum of 50 file entries, 50 unit entries, and 10 actions per entry","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-disruption-policy-limits.json"},{"id":"mco-managed-boot-images-must-be-explicit","text":"managedBootImages must be explicitly configured in MachineConfiguration; when omitted, boot images are not updated during cluster upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-managed-boot-images-must-be-explicit.json"},{"id":"mco-manages-machineconfig-resources","text":"The Machine Config Operator (MCO) is the controller responsible for reconciling MachineConfig, KubeletConfig, and ContainerRuntimeConfig resources and applying changes to nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-manages-machineconfig-resources.json"},{"id":"mco-manages-os-config","text":"The Machine Config Operator (MCO) manages and applies OS-level configurations and updates between the kernel and kubelet layers","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-manages-os-config.json"},{"id":"mco-node-disruption-policy-no-effect-on-upgrades","text":"The nodeDisruptionPolicy in MachineConfiguration only affects day-2 MachineConfig changes, not cluster upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-node-disruption-policy-no-effect-on-upgrades.json"},{"id":"mco-node-update-order","text":"The MCO updates nodes alphabetically by zone (oldest first within a zone), cordons per `maxUnavailable`, then reboots.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-node-update-order.json"},{"id":"mco-reconciles-machineconfig","text":"The Machine Config Operator (MCO) reconciles MachineConfig objects and applies them to nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-reconciles-machineconfig.json"},{"id":"mco-restarts-crio-not-nodes","text":"The MCO does not restart nodes for registry configuration changes — it restarts CRI-O only (cordon, restart CRI-O, uncordon)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-restarts-crio-not-nodes.json"},{"id":"mco-rollout-process","text":"MCO rollout process for config changes: render new MC → cordon → drain → write config → apply image → reboot.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mco-rollout-process.json"},{"id":"mcp-api-group-v1-cluster-scoped","text":"MachineConfigPool uses API group `machineconfiguration.openshift.io/v1` and is cluster-scoped (no namespace)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-api-group-v1-cluster-scoped.json"},{"id":"mcp-default-pools-master-worker","text":"Default MachineConfigPools are `master` and `worker`; custom pools can be created for specialized node roles","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-default-pools-master-worker.json"},{"id":"mcp-degraded-vs-unavailable","text":"In MCP, a node is degraded when configuration application fails; unavailable when updating or NodeReady is false","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-degraded-vs-unavailable.json"},{"id":"mcp-maxunavailable-default-1-no-zero","text":"MachineConfigPool `maxUnavailable` defaults to 1 and cannot be set to 0; use `paused: true` to stop updates instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-maxunavailable-default-1-no-zero.json"},{"id":"mcp-paused-stops-generation-and-updates","text":"Setting `paused: true` on a MachineConfigPool stops both generating new desiredMachineConfig and updating machines","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-paused-stops-generation-and-updates.json"},{"id":"mcp-updates-respect-pdbs","text":"MachineConfigPool updates respect Pod Disruption Budgets even when maxUnavailable is greater than 1","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mcp-updates-respect-pdbs.json"},{"id":"metadata-apis-category-contents","text":"The Metadata APIs category in OpenShift 4.17 includes: APIRequestCount, Binding, ComponentStatus, ConfigMap, ControllerRevision, Event, Lease, and Namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metadata-apis-category-contents.json"},{"id":"metal3remediationtemplate-api-group-capi","text":"Metal3RemediationTemplate belongs to API group `infrastructure.cluster.x-k8s.io/v1beta1` (Cluster API infrastructure provider), not `metal3.io`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metal3remediationtemplate-api-group-capi.json"},{"id":"metal3remediationtemplate-strategy-fields","text":"Metal3RemediationTemplate remediation strategy is configured via `spec.template.spec.strategy` with fields: `type` (string), `retryLimit` (integer), and `timeout` (string for time between retries)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metal3remediationtemplate-strategy-fields.json"},{"id":"metal3remediationtemplate-used-by-machinehealthcheck","text":"MachineHealthCheck references a Metal3RemediationTemplate to define what remediation action to take when a bare-metal machine is unhealthy","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metal3remediationtemplate-used-by-machinehealthcheck.json"},{"id":"metallb-bare-metal-networking-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-bare-metal-networking-model.json"},{"id":"metallb-bgp-single-asn-requirement","text":"In OpenShift MetalLB, all BGP peers must share a single ASN (`spec.myASN`) and a single router ID — this differs from community MetalLB.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-bgp-single-asn-requirement.json"},{"id":"metallb-external-traffic-policy-local-vs-cluster","text":"MetalLB external traffic policy `local` preserves client IP but risks uneven distribution; `cluster` (default) obscures client IP but distributes evenly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-external-traffic-policy-local-vs-cluster.json"},{"id":"metallb-incompatible-with-ip-failover","text":"MetalLB and IP failover are incompatible; IP failover must be removed before installing MetalLB.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-incompatible-with-ip-failover.json"},{"id":"metallb-l2-failover-gratuitous-arp","text":"MetalLB Layer 2 failover uses gratuitous ARP with typical failover within 10 seconds.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-l2-failover-gratuitous-arp.json"},{"id":"metallb-l2-single-node-bottleneck","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-l2-single-node-bottleneck.json"},{"id":"metallb-one-cr-per-cluster","text":"Only one MetalLB CR instance is supported per cluster; deleting it removes MetalLB from the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-one-cr-per-cluster.json"},{"id":"metallb-operator-bare-metal-only","text":"The MetalLB Operator provides load balancing specifically for bare metal clusters, not cloud deployments","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-operator-bare-metal-only.json"},{"id":"metallb-six-custom-resources","text":"MetalLB uses six custom resources: `MetalLB`, `IPAddressPool`, `L2Advertisement`, `BGPAdvertisement`, `BGPPeer`, `BFDProfile`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-six-custom-resources.json"},{"id":"metallb-two-modes-l2-bgp","text":"MetalLB operates in two modes: Layer 2 (using ARP/NDP, single-node traffic) and BGP (router distributes traffic across nodes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metallb-two-modes-l2-bgp.json"},{"id":"metrics-api-group-v1beta1","text":"The Metrics API group is `metrics.k8s.io/v1beta1` and provides NodeMetrics and PodMetrics resources that back `oc top` commands and HPA decisions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metrics-api-group-v1beta1.json"},{"id":"metrics-memory-working-set","text":"Both NodeMetrics and PodMetrics report memory usage as the memory working set, not RSS or total allocated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metrics-memory-working-set.json"},{"id":"metrics-server-required-for-oc-top","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metrics-server-required-for-oc-top.json"},{"id":"metrics-timestamp-window","text":"NodeMetrics and PodMetrics use `timestamp` and `window` fields to define the collection interval: metrics were collected during `[Timestamp - Window, Timestamp]`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/metrics-timestamp-window.json"},{"id":"mhc-control-plane-max-unhealthy-1","text":"For control plane MachineHealthChecks, `maxUnhealthy` should be set to `1` to prevent action when multiple control plane nodes appear unhealthy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-control-plane-max-unhealthy-1.json"},{"id":"mhc-empty-selector-matches-all","text":"A MachineHealthCheck with an empty selector matches all machines","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-empty-selector-matches-all.json"},{"id":"mhc-failed-phase-immediate-remediation","text":"A machine with `Failed` phase is remediated immediately by MachineHealthCheck without waiting for timeout.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-failed-phase-immediate-remediation.json"},{"id":"mhc-max-unhealthy-default-100-percent","text":"MachineHealthCheck `maxUnhealthy` defaults to `100%` if not set, meaning remediation always proceeds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-max-unhealthy-default-100-percent.json"},{"id":"mhc-maxunhealthy-circuit-breaker","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-maxunhealthy-circuit-breaker.json"},{"id":"mhc-node-startup-timeout-zero-disables","text":"Setting MachineHealthCheck `nodeStartupTimeout` to \"0\" disables startup health checks (machines without nodes won't be remediated)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-node-startup-timeout-zero-disables.json"},{"id":"mhc-one-node-at-a-time","text":"MachineHealthCheck remediates only one node at a time (drains and deletes) to limit disruption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-one-node-at-a-time.json"},{"id":"mhc-pause-during-update","text":"MachineHealthCheck resources must be paused before cluster updates using annotation `cluster.x-k8s.io/paused=\"\"` in the `openshift-machine-api` namespace, and resumed after","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-pause-during-update.json"},{"id":"mhc-percentage-max-unhealthy-rounded-down","text":"Percentage-based `maxUnhealthy` values in MachineHealthCheck are rounded down.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-percentage-max-unhealthy-rounded-down.json"},{"id":"mhc-remediation-template-optional","text":"MachineHealthCheck `remediationTemplate` is optional; without it, default remediation (delete and recreate machine) is used","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-remediation-template-optional.json"},{"id":"mhc-unhealthy-conditions-ored","text":"MachineHealthCheck unhealthy conditions are OR'd — any single condition match triggers unhealthy status","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mhc-unhealthy-conditions-ored.json"},{"id":"mig-requires-ampere-max-7-instances","text":"Multi-Instance GPU (MIG) requires NVIDIA Ampere architecture or newer (A100, A30) and supports up to 7 independent GPU instances per physical GPU.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mig-requires-ampere-max-7-instances.json"},{"id":"minimum-cpu-allocation-10m","text":"The minimum CPU allocation per pod is 10 mCPU (10 millicores), even if less is requested.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/minimum-cpu-allocation-10m.json"},{"id":"minreadyseconds-available-vs-ready","text":"The `minReadySeconds` field controls when a pod counts as \"available\" (ready for at least that many seconds) versus merely \"ready\".","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/minreadyseconds-available-vs-ready.json"},{"id":"mirror-config-applied-via-mco-registries-conf","text":"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","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mirror-config-applied-via-mco-registries-conf.json"},{"id":"mirror-registries-auto-added-unauthenticated-ignore","text":"Mirror registries defined in `registries.conf` are automatically added to the unauthenticated ignore list — no need to list them under `spec.unauthenticatedRegistries` in AgentServiceConfig.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mirror-registries-auto-added-unauthenticated-ignore.json"},{"id":"mirror-registry-configmap-multicluster-engine-namespace","text":"The ConfigMap for mirror registry configuration must be in namespace `multicluster-engine` with label `app: assisted-service`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mirror-registry-configmap-multicluster-engine-namespace.json"},{"id":"mirror-registry-docker-v2-2-required","text":"Mirror registries must support Docker v2-2 manifest format.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mirror-registry-docker-v2-2-required.json"},{"id":"mixed-mtu-nodes-use-lowest","text":"When cluster nodes have different MTU values, the cluster network MTU must be set to the lowest node MTU minus the overlay overhead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mixed-mtu-nodes-use-lowest.json"},{"id":"monitoring-config-configmap","text":"Cluster Monitoring configuration is edited via the `cluster-monitoring-config` ConfigMap in the `openshift-monitoring` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-config-configmap.json"},{"id":"monitoring-from-collection-through-alerting","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-from-collection-through-alerting.json"},{"id":"monitoring-rbac-roles","text":"Access to monitoring APIs is governed by cluster roles including `cluster-monitoring-view`, `monitoring-edit`, and `monitoring-rules-edit`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-rbac-roles.json"},{"id":"monitoring-requires-explicit-enablement-beyond-platform","text":"Platform monitoring is automatic but both user workload monitoring and distributed tracing require explicit administrator action to enable, creating a two-tier observability model.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-requires-explicit-enablement-beyond-platform.json"},{"id":"monitoring-stack-layered-architecture","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-stack-layered-architecture.json"},{"id":"monitoring-two-api-groups","text":"OpenShift monitoring CRDs span two API groups: `monitoring.coreos.com` (upstream prometheus-operator) and `monitoring.openshift.io` (OpenShift-specific wrappers).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/monitoring-two-api-groups.json"},{"id":"mtc-custom-resources","text":"MTC uses MigCluster, MigStorage, MigPlan, and MigMigration custom resources for managing migrations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtc-custom-resources.json"},{"id":"mtc-for-stateful-workload-migration","text":"The Migration Toolkit for Containers (MTC) is the supported tool for migrating stateful application workloads between OCP 4 clusters","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtc-for-stateful-workload-migration.json"},{"id":"mtc-installed-via-operatorhub","text":"MTC is an Operator installed from OperatorHub — it is not a built-in platform feature","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtc-installed-via-operatorhub.json"},{"id":"mtc-pv-migration-strategies","text":"MTC supports two PV migration strategies: move (direct transfer) and copy (snapshot or filesystem copy)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtc-pv-migration-strategies.json"},{"id":"mtc-uses-velero-via-oadp","text":"MTC leverages Velero (via OADP — OpenShift API for Data Protection) under the hood for backup/restore operations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtc-uses-velero-via-oadp.json"},{"id":"mtu-migration-requires-two-reboots","text":"MTU migration on OpenShift requires at least two rolling reboots and is disruptive; rollback is not possible during migration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtu-migration-requires-two-reboots.json"},{"id":"mtu-migration-requires-two-rolling-reboots","text":"MTU migration requires at least two rolling reboots of all cluster nodes; MCO reboots one node per pool at a time by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtu-migration-requires-two-rolling-reboots.json"},{"id":"mtu-migration-three-phase-process","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtu-migration-three-phase-process.json"},{"id":"mtu-no-rollback-during-migration","text":"You cannot roll back MTU during an active migration; rollback is only possible after the migration completes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtu-no-rollback-during-migration.json"},{"id":"mtv-migration-toolkit-for-virtualization","text":"Migration Toolkit for Virtualization (MTV) is the official supported tool for migrating VMs at scale to OpenShift Virtualization from other platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mtv-migration-toolkit-for-virtualization.json"},{"id":"multi-attach-storage-rwx-vs-rwo","text":"Multi-attach storage errors are resolved by either using RWX (ReadWriteMany) volumes or recovering/deleting the failed node for RWO (ReadWriteOnce) volumes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multi-attach-storage-rwx-vs-rwo.json"},{"id":"multi-cni-network-architecture","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multi-cni-network-architecture.json"},{"id":"multi-level-autoscaling-architecture","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multi-level-autoscaling-architecture.json"},{"id":"multi-network-policy-enforcement-complete","text":"Network policy enforcement covers both primary networks (via AdminNetworkPolicy cluster-scoped rules with Allow/Deny/Pass actions) and secondary networks (via MultiNetworkPolicy with identical spec to NetworkPolicy), providing comprehensive traffic control across all network interfaces.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multi-network-policy-enforcement-complete.json"},{"id":"multicluster-engine-delivered-separately","text":"The multicluster engine for Kubernetes Operator is included with OCP subscription but delivered separately from the core payload and must be explicitly installed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multicluster-engine-delivered-separately.json"},{"id":"multicluster-engine-enabled-by-default-in-rhacm","text":"Multicluster engine is enabled by default when Red Hat Advanced Cluster Management (RHACM) is installed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multicluster-engine-enabled-by-default-in-rhacm.json"},{"id":"multicluster-engine-full-lifecycle-ocp-only","text":"Multicluster engine provides full lifecycle management for OCP clusters but only partial lifecycle management for non-OCP Kubernetes distributions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multicluster-engine-full-lifecycle-ocp-only.json"},{"id":"multinetworkpolicy-api-group","text":"MultiNetworkPolicy uses the API group `k8s.cni.cncf.io/v1beta1`, distinct from the native NetworkPolicy API group `networking.k8s.io/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multinetworkpolicy-api-group.json"},{"id":"multinetworkpolicy-applies-to-secondary-networks","text":"MultiNetworkPolicy applies network policy rules to secondary networks (additional interfaces attached via Multus CNI), not the primary pod network","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multinetworkpolicy-applies-to-secondary-networks.json"},{"id":"multinetworkpolicy-selectors-depend-on-subnets","text":"MultiNetworkPolicy selectors depend on `subnets` config: with subnets defined, podSelector/namespaceSelector/ipBlock are available; without subnets, only ipBlock is allowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multinetworkpolicy-selectors-depend-on-subnets.json"},{"id":"multinetworkpolicy-spec-identical-to-networkpolicy","text":"MultiNetworkPolicy spec is structurally identical to Kubernetes NetworkPolicy — same fields for podSelector, ingress, egress, and policyTypes","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multinetworkpolicy-spec-identical-to-networkpolicy.json"},{"id":"multiple-default-storageclass-alert","text":"Only one StorageClass should be default at any time; multiple defaults trigger a `MultipleDefaultStorageClasses` alert, and the most recently created default is used.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multiple-default-storageclass-alert.json"},{"id":"multiple-identities-per-user","text":"Multiple Identity objects can map to a single User object, enabling authentication from multiple identity providers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multiple-identities-per-user.json"},{"id":"multus-auto-names-interfaces-net1-net2","text":"Multus automatically names attached secondary interfaces as net1, net2, net3, etc., unless overridden with the @name suffix in the pod annotation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multus-auto-names-interfaces-net1-net2.json"},{"id":"multus-cni-enables-multiple-network-attachments","text":"Multus CNI is the meta-plugin that enables attaching multiple network interfaces to pods in OpenShift","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/multus-cni-enables-multiple-network-attachments.json"},{"id":"must-gather-audit-logs-not-default","text":"Audit logs are not collected by default with `oc adm must-gather`; they require explicit `-- /usr/bin/gather_audit_logs`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-audit-logs-not-default.json"},{"id":"must-gather-creates-pod-on-control-plane","text":"`oc adm must-gather` creates a temporary pod on a random control plane node to collect debugging data","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-creates-pod-on-control-plane.json"},{"id":"must-gather-default-plus-feature-image-stream","text":"To collect default data AND feature-specific data together, add `--image-stream=openshift/must-gather` alongside `--image`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-default-plus-feature-image-stream.json"},{"id":"must-gather-default-timeout-10min","text":"`oc adm must-gather` default timeout is 10 minutes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-default-timeout-10min.json"},{"id":"must-gather-diagnostic-data-collection","text":"The `oc adm must-gather` command is used to collect diagnostic data for submitting support cases to Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-diagnostic-data-collection.json"},{"id":"must-gather-disconnected-import-image","text":"In disconnected environments, import the must-gather image first with `oc import-image is/must-gather -n openshift`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-disconnected-import-image.json"},{"id":"must-gather-fallback-oc-adm-inspect","text":"`oc adm inspect` is the fallback when `oc adm must-gather` cannot schedule its pod","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-fallback-oc-adm-inspect.json"},{"id":"must-gather-multiple-images-one-command","text":"Multiple `--image` flags can be combined in a single `oc adm must-gather` command to collect data for multiple features","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-multiple-images-one-command.json"},{"id":"must-gather-network-logs-command","text":"Network logs require `-- gather_network_logs`; by default only OVN nbdb/sbdb databases are collected","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-network-logs-command.json"},{"id":"must-gather-primary-support-tool","text":"`oc adm must-gather` is the primary recommended tool for collecting cluster diagnostic data when opening a support case with Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-primary-support-tool.json"},{"id":"must-gather-requires-cluster-admin","text":"`oc adm must-gather` requires the cluster-admin role","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-requires-cluster-admin.json"},{"id":"must-gather-volume-percentage-default-30","text":"`oc adm must-gather` default `--volume-percentage` is 30%","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/must-gather-volume-percentage-default-30.json"},{"id":"mutating-webhook-api-group","text":"MutatingWebhookConfiguration belongs to API group `admissionregistration.k8s.io/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mutating-webhook-api-group.json"},{"id":"mutating-webhook-can-modify-objects","text":"MutatingWebhookConfiguration webhooks can accept, reject, or modify incoming objects, unlike ValidatingWebhookConfiguration which can only accept or reject","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mutating-webhook-can-modify-objects.json"},{"id":"mutating-webhooks-run-before-validating","text":"Mutating admission plugins run before validating admission plugins in the admission chain.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/mutating-webhooks-run-before-validating.json"},{"id":"nad-api-group-v1","text":"NetworkAttachmentDefinition uses API group `k8s.cni.cncf.io/v1` and is a namespace-scoped resource defined by the Network Plumbing Working Group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nad-api-group-v1.json"},{"id":"nad-config-is-json-string","text":"NetworkAttachmentDefinition `spec.config` field is a JSON string (not a nested object) containing the full CNI plugin configuration","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nad-config-is-json-string.json"},{"id":"nad-crd-defines-secondary-networks","text":"NetworkAttachmentDefinition (NAD) is the CRD used to define and configure secondary network attachments for pods","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nad-crd-defines-secondary-networks.json"},{"id":"nad-network-names-cluster-unique","text":"NetworkAttachmentDefinition (NAD) network names must be unique across the entire cluster; multiple NADs with different configs referencing the same network name is unsupported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nad-network-names-cluster-unique.json"},{"id":"nad-network-names-cross-namespace","text":"NAD network names are not namespaced — a network named identically in different namespace NADs enables cross-namespace pod communication on the same secondary network.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nad-network-names-cross-namespace.json"},{"id":"namespace-api-core-v1","text":"Namespace is a core v1 API resource in Kubernetes/OpenShift, served at `/api/v1/` (not under any API group)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespace-api-core-v1.json"},{"id":"namespace-finalize-endpoint-unstick","text":"The `/api/v1/namespaces/{name}/finalize` PUT endpoint is used to clear finalizers and resolve a namespace stuck in Terminating state","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespace-finalize-endpoint-unstick.json"},{"id":"namespace-finalizers-prevent-deletion","text":"Namespace finalizers are the mechanism that prevents premature deletion; a namespace stuck in Terminating typically has uncleared finalizers","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespace-finalizers-prevent-deletion.json"},{"id":"namespace-two-phases-active-terminating","text":"Namespaces have exactly two phases: Active and Terminating","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespace-two-phases-active-terminating.json"},{"id":"namespace-watch-endpoints-deprecated","text":"The dedicated `/api/v1/watch/namespaces` endpoints are deprecated; use the `watch` query parameter on list operations instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespace-watch-endpoints-deprecated.json"},{"id":"namespaces-not-for-cluster-wide-resources","text":"Namespaces scope deployments, services, and pods, but do NOT apply to cluster-wide resources such as storage classes, nodes, and persistent volumes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/namespaces-not-for-cluster-wide-resources.json"},{"id":"nbde-binds-encryption-to-network-presence","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nbde-binds-encryption-to-network-presence.json"},{"id":"nbde-must-enable-at-install-time","text":"NBDE must be enabled at OpenShift installation time, but disk encryption policy can be changed post-installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nbde-must-enable-at-install-time.json"},{"id":"nbde-node-no-tang-no-boot","text":"A node configured with NBDE that cannot reach its Tang servers at boot will retry indefinitely and cannot boot.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nbde-node-no-tang-no-boot.json"},{"id":"nbde-protects-entire-server-theft","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nbde-protects-entire-server-theft.json"},{"id":"netobserv-cli-capture-duration-limits","text":"Network Observability CLI default max capture time is 5 minutes for flows/packets and 1 hour for metrics; recommended max is 8-10 minutes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-cli-capture-duration-limits.json"},{"id":"netobserv-cli-feature-flags-not-packets","text":"Network Observability CLI feature options (`--enable_pkt_drop`, `--enable_rtt`, `--enable_dns`) work with `flows` and `metrics` commands but NOT with `packets`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-cli-feature-flags-not-packets.json"},{"id":"netobserv-cli-max-capture-bytes","text":"Network Observability CLI default maximum capture size is 50MB","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-cli-max-capture-bytes.json"},{"id":"netobserv-cli-output-formats","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-cli-output-formats.json"},{"id":"netobserv-cli-separate-from-operator","text":"The Network Observability CLI (`oc netobserv`) is installed separately from the Network Observability Operator — they are independent components","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-cli-separate-from-operator.json"},{"id":"netobserv-console-plugin-dual-registration","text":"Console plugin registration requires both `spec.consolePlugin.register: true` in the FlowCollector and `netobserv-plugin` listed in `console.operator.openshift.io`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-console-plugin-dual-registration.json"},{"id":"netobserv-conversation-logtypes","text":"FlowCollector `logTypes` values for conversation tracking: `Flows`, `All` (highest storage), `Conversations`, `EndedConversations` (lowest storage)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-conversation-logtypes.json"},{"id":"netobserv-default-enabled-metrics","text":"Network Observability default-enabled metrics are `namespace_flows_total`, `node_ingress_bytes_total`, and `workload_ingress_bytes_total`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-default-enabled-metrics.json"},{"id":"netobserv-flow-export-destinations","text":"Network flow data can be exported to Kafka, stored in Loki, and used for Prometheus metrics via FlowMetrics API","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-flow-export-destinations.json"},{"id":"netobserv-flow-filter-actions","text":"eBPF flow filter actions: Accept (cache in eBPF table) and Reject (drop, don't cache); unmatched flows are cached by default","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-flow-filter-actions.json"},{"id":"netobserv-loki-label-fields","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-loki-label-fields.json"},{"id":"netobserv-loki-recommended-backend","text":"Loki is the recommended storage backend for Network Observability flow logs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-loki-recommended-backend.json"},{"id":"netobserv-metrics-configured-in-includeList","text":"Network Observability metrics are configured via `spec.processor.metrics.includeList` in the FlowCollector custom resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-metrics-configured-in-includeList.json"},{"id":"netobserv-metrics-prefix","text":"All Network Observability Operator metrics are prefixed with `netobserv_` in Prometheus","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-metrics-prefix.json"},{"id":"netobserv-must-gather-image","text":"The must-gather image for Network Observability is `quay.io/netobserv/must-gather`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-must-gather-image.json"},{"id":"netobserv-operator-cluster-scoped","text":"Network Observability is a cluster-level capability, not namespace-scoped observation only","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-operator-cluster-scoped.json"},{"id":"netobserv-operator-memory-via-subscription","text":"Network Observability Operator memory limits are configured via the Subscription object's `spec.config.resources`, not the FlowCollector","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-operator-memory-via-subscription.json"},{"id":"netobserv-operator-not-default","text":"The Network Observability Operator is an optional, installable component — not enabled by default in OpenShift","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-operator-not-default.json"},{"id":"netobserv-packet-drop-types","text":"Network Observability packet drops are classified as host drops (prefixed `SKB_DROP`) and OVS drops (prefixed `OVS_DROP`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-packet-drop-types.json"},{"id":"netobserv-pktdrop-requires-privileged","text":"PacketDrop metrics require `privileged` mode enabled in `spec.agent.ebpf.features` of the FlowCollector CR","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-pktdrop-requires-privileged.json"},{"id":"netobserv-rtt-nanoseconds-divider","text":"Network Observability RTT values are provided in nanoseconds; use `divider: \"1000000000\"` to convert to seconds for Prometheus","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-rtt-nanoseconds-divider.json"},{"id":"netobserv-rtt-uses-srtt-hookpoint","text":"Network Observability RTT uses TCP smoothed RTT (sRTT) from the `fentry/tcp_rcv_established` eBPF hookpoint","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-rtt-uses-srtt-hookpoint.json"},{"id":"netobserv-three-console-views","text":"Network Observability provides three console views: Overview, Traffic Flows, and Topology — accessed under Observe → Network Traffic","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-three-console-views.json"},{"id":"netobserv-topology-default-layout-cola","text":"Network Observability Topology view default layout is Cola; other options are ColaNoForce, Concentric, Dagre, Force, Grid","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-topology-default-layout-cola.json"},{"id":"netobserv-uses-ebpf-collection","text":"The Network Observability Operator uses eBPF technology for efficient flow collection at the kernel level","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netobserv-uses-ebpf-collection.json"},{"id":"netpol-additive-union-semantics","text":"Multiple NetworkPolicy objects are additive — traffic allowed by any matching policy is permitted (union logic).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-additive-union-semantics.json"},{"id":"netpol-audit-log-location","text":"Network policy audit logs are stored at `/var/log/ovn/acl-audit-log.log` inside OVN-Kubernetes node pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-audit-log-location.json"},{"id":"netpol-audit-logging-annotation","text":"OVN-Kubernetes network policy audit logging is enabled via the `k8s.ovn.org/acl-logging` annotation on the namespace, with `deny`/`allow` severity keys.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-audit-logging-annotation.json"},{"id":"netpol-cannot-block-localhost-or-node-traffic","text":"NetworkPolicy cannot block traffic from localhost or from the pod's resident node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-cannot-block-localhost-or-node-traffic.json"},{"id":"netpol-default-all-pods-accessible","text":"All pods in a project are accessible from all other pods and network endpoints until a NetworkPolicy is applied.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-default-all-pods-accessible.json"},{"id":"netpol-default-policies-via-project-template","text":"Default network policies for new projects are injected by modifying the project request template in the `openshift-config` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-default-policies-via-project-template.json"},{"id":"netpol-deny-all-ingress-pattern","text":"A NetworkPolicy with `podSelector: {}` and empty `ingress: []` creates a deny-all-ingress policy; `ingress: [{}]` (empty rule) means allow-all-ingress.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-deny-all-ingress-pattern.json"},{"id":"netpol-from-entry-and-vs-or-logic","text":"Combined `namespaceSelector` + `podSelector` in a single `from` entry uses AND logic; separate `from` entries use OR logic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-from-entry-and-vs-or-logic.json"},{"id":"netpol-ingress-controller-namespace-label","text":"To allow traffic from the OpenShift Ingress Controller, match on namespace label `policy-group.network.openshift.io/ingress: \"\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-ingress-controller-namespace-label.json"},{"id":"netpol-multitenant-isolation-three-policies","text":"Multitenant isolation requires three policies per namespace: deny-by-default, allow-same-namespace, and allow-from-ingress.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-multitenant-isolation-three-policies.json"},{"id":"netpol-supported-protocols-tcp-udp-icmp-sctp","text":"NetworkPolicy only affects TCP, UDP, ICMP, and SCTP protocols — other protocols are unaffected.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-supported-protocols-tcp-udp-icmp-sctp.json"},{"id":"netpol-unselected-pods-remain-accessible","text":"A pod not selected by any NetworkPolicy remains fully accessible — it is not denied by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/netpol-unselected-pods-remain-accessible.json"},{"id":"network-architecture-layered-with-dual-stack-constraints","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-architecture-layered-with-dual-stack-constraints.json"},{"id":"network-config-singleton-named-cluster","text":"The Network resource (`config.openshift.io/v1`) is a cluster-scoped singleton with canonical name `cluster`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-config-singleton-named-cluster.json"},{"id":"network-connectivity-check-every-minute","text":"The CNO connectivity check controller runs TCP connection health checks every minute in parallel, storing results in `PodNetworkConnectivityCheck` objects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-connectivity-check-every-minute.json"},{"id":"network-diagnostics-configured-on-network-cr","text":"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`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-diagnostics-configured-on-network-cr.json"},{"id":"network-diagnostics-log-reasons","text":"Network connectivity check log reason values are: `TCPConnect`, `TCPConnectError`, `DNSResolve`, `DNSError`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-diagnostics-log-reasons.json"},{"id":"network-diagnostics-namespace","text":"All network connectivity diagnostic resources live in the `openshift-network-diagnostics` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-diagnostics-namespace.json"},{"id":"network-diagnostics-node-labels-before-config","text":"Node labels must be applied before updating the network diagnostics configuration — labels applied after are ignored.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-diagnostics-node-labels-before-config.json"},{"id":"network-diagnostics-source-deployment-target-daemonset","text":"The network diagnostics source pod is a Deployment (single replica) and target pods are a DaemonSet (runs on every node).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-diagnostics-source-deployment-target-daemonset.json"},{"id":"network-flow-export-ovn-only","text":"Network flow export (NetFlow, SFlow, IPFIX) is only supported on OVN-Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-flow-export-ovn-only.json"},{"id":"network-metrics-daemon-publishes-pod-network-name-info","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-metrics-daemon-publishes-pod-network-name-info.json"},{"id":"network-name-label-format-namespace-nad","text":"The `network_name` label in `pod_network_name_info` uses the format `<namespace>/<NetworkAttachmentDefinition name>`, derived from the Multus `k8s.v1.cni.cncf.io/network-status` annotation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-name-label-format-namespace-nad.json"},{"id":"network-observability-end-to-end","text":"Network observability pipeline is end-to-end operational: eBPF agent collects flows, FlowCollector (singleton named `cluster`) processes them, Loki stores them, and the console plugin provides visualization.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-observability-end-to-end.json"},{"id":"network-observability-operator-netobserv-dashboard","text":"The Network Observability Operator is optional and provides an additional Netobserv dashboard when installed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-observability-operator-netobserv-dashboard.json"},{"id":"network-plugin-selected-at-install-time","text":"The network plugin (OVN-Kubernetes or OpenShift SDN) is selected at cluster install time.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-plugin-selected-at-install-time.json"},{"id":"network-policies-are-additive","text":"When multiple NetworkPolicies select the same pod, the union of all their rules applies (policies are additive, not overriding).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-policies-are-additive.json"},{"id":"network-policies-operate-at-l3-l4","text":"Kubernetes NetworkPolicies operate at L3/L4 (IP address and port level) and do not support L7 filtering (e.g., HTTP path or header matching).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-policies-operate-at-l3-l4.json"},{"id":"network-policy-deny-by-default-when-selected","text":"When any NetworkPolicy selects a pod, all traffic not explicitly allowed by a policy is denied; pods with no selecting policy allow all traffic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-policy-deny-by-default-when-selected.json"},{"id":"network-policy-evaluation-order","text":"Network policy evaluation order is: AdminNetworkPolicy (by priority) → NetworkPolicy → BaselineAdminNetworkPolicy","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-policy-evaluation-order.json"},{"id":"network-policy-selectors","text":"NetworkPolicy rules use `podSelector`, `namespaceSelector`, and `ipBlock` to select traffic sources and destinations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-policy-selectors.json"},{"id":"network-read-status-not-spec","text":"Consumers should read `status` (not `spec`) on the Network config to see the currently deployed network configuration","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-read-status-not-spec.json"},{"id":"network-resource-singleton-cluster","text":"The Network operator resource (operator.openshift.io/v1) is always named \"cluster\" — exactly one per cluster","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-resource-singleton-cluster.json"},{"id":"network-security-two-mechanisms","text":"OpenShift network security is primarily implemented through two distinct mechanisms: network policies (pod/namespace-level ingress/egress) and egress firewalls (cluster-to-external traffic).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-security-two-mechanisms.json"},{"id":"network-type-ovnkubernetes","text":"The only currently supported `networkType` value is `OVNKubernetes`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/network-type-ovnkubernetes.json"},{"id":"networking-and-observability-integrated-stack","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networking-and-observability-integrated-stack.json"},{"id":"networking-fully-operational-with-observability","text":"The complete networking stack with integrated observability (DNS discovery + multi-CNI data plane + dual-stack addressing + eBPF flow collection) is fully operational only when eBPF Manager reaches GA and platform-specific dual-stack restrictions are resolved.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networking-fully-operational-with-observability.json"},{"id":"networkpolicy-empty-ingress-denies-all","text":"In both NetworkPolicy and MultiNetworkPolicy, an empty ingress array means deny all inbound traffic; an empty egress array means deny all outbound traffic","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-empty-ingress-denies-all.json"},{"id":"networkpolicy-endport-no-named-ports","text":"NetworkPolicy endPort field creates inclusive port ranges but cannot be used with named ports","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-endport-no-named-ports.json"},{"id":"networkpolicy-ipblock-mutually-exclusive-with-selectors","text":"In NetworkPolicy peers, ipBlock cannot be combined with podSelector or namespaceSelector in the same peer entry","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-ipblock-mutually-exclusive-with-selectors.json"},{"id":"networkpolicy-local-node-traffic-always-allowed","text":"Traffic from a pod's local node is always allowed for ingress, regardless of NetworkPolicy rules","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-local-node-traffic-always-allowed.json"},{"id":"networkpolicy-no-policy-means-all-allowed","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-no-policy-means-all-allowed.json"},{"id":"networkpolicy-podselector-only-required-field","text":"The only required field in a NetworkPolicy or MultiNetworkPolicy spec is podSelector; an empty podSelector `{}` matches all pods in the namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-podselector-only-required-field.json"},{"id":"networkpolicy-protocol-defaults-tcp","text":"In NetworkPolicy and MultiNetworkPolicy, the protocol field defaults to TCP when not specified","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-protocol-defaults-tcp.json"},{"id":"networkpolicy-rules-additive-across-policies","text":"Multiple NetworkPolicies selecting the same pod have their rules combined additively (union); you cannot use NetworkPolicy to deny traffic that another policy allows","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/networkpolicy-rules-additive-across-policies.json"},{"id":"never-scale-machineset-zero-with-router-pods","text":"Never scale a compute machine set to 0 without first relocating router pods, as they are needed for cluster access including the web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/never-scale-machineset-zero-with-router-pods.json"},{"id":"never-scale-workers-to-zero-without-router-relocation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/never-scale-workers-to-zero-without-router-relocation.json"},{"id":"nfd-detects-and-labels-hardware-features","text":"Node Feature Discovery (NFD) detects hardware features on nodes and labels them for scheduling purposes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nfd-detects-and-labels-hardware-features.json"},{"id":"nfd-prerequisite-for-gpu-operator","text":"The Node Feature Discovery (NFD) Operator must be installed before the GPU Operator; NFD detects GPU hardware so the GPU Operator can manage it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nfd-prerequisite-for-gpu-operator.json"},{"id":"nfd-required-alongside-gpu-operators","text":"Node Feature Discovery (NFD) is typically required alongside GPU operators to detect hardware capabilities on nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nfd-required-alongside-gpu-operators.json"},{"id":"nfs-supports-all-access-modes","text":"NFS supports all access modes (RWO, ROX, RWX). AWS EBS and Azure Disk only support RWO/RWOP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nfs-supports-all-access-modes.json"},{"id":"nmstate-all-enactments-fail-means-policy-issue","text":"If all NMState enactments fail, the problem is likely in the policy; if only some fail, the problem is likely node-specific.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-all-enactments-fail-means-policy-issue.json"},{"id":"nmstate-automatic-rollback-on-failure","text":"NMState automatically rolls back failed network configurations — triggered by: failed apply, lost default gateway connectivity, or lost API server connectivity.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-automatic-rollback-on-failure.json"},{"id":"nmstate-cannot-update-primary-nic","text":"The NMState Operator cannot update the primary NIC or `br-ex` bridge on most on-premise networks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-cannot-update-primary-nic.json"},{"id":"nmstate-config-path-on-nodes","text":"NMState bonding configuration is base64-encoded and delivered via MachineConfig to the path `/etc/nmstate/openshift/cluster.yml` on nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-config-path-on-nodes.json"},{"id":"nmstate-declarative-node-networking","text":"Kubernetes NMState provides declarative management of node network configuration (interfaces, bridges, bonds, VLANs, routes) via Kubernetes custom resources.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-declarative-node-networking.json"},{"id":"nmstate-disconnected-dns-root-servers-net","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-disconnected-dns-root-servers-net.json"},{"id":"nmstate-instance-singleton-named-nmstate","text":"The NMState CR instance is a cluster-wide singleton and must be named `nmstate`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-instance-singleton-named-nmstate.json"},{"id":"nmstate-namespace-openshift-nmstate","text":"The Kubernetes NMState Operator installs into the `openshift-nmstate` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-namespace-openshift-nmstate.json"},{"id":"nmstate-nnce-failing-jsonpath","text":"The jsonpath filter `'{.status.conditions[?(@.type==\"Failing\")].message}'` extracts the error message from an NMState enactment resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-nnce-failing-jsonpath.json"},{"id":"nmstate-olm-no-auto-delete-crds","text":"Uninstalling the NMState Operator via OLM does not automatically delete CRDs, CRs, or API Services — manual cleanup is required.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-olm-no-auto-delete-crds.json"},{"id":"nmstate-operator-not-enabled-by-default","text":"The NMState Operator must be installed separately from OperatorHub; it is not enabled by default in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-operator-not-enabled-by-default.json"},{"id":"nmstate-operator-required","text":"The Kubernetes NMState Operator must be installed before NMState features can be used.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-operator-required.json"},{"id":"nmstate-resource-shortnames","text":"NMState resource shortnames: `nncp` (NodeNetworkConfigurationPolicy), `nnce` (NodeNetworkConfigurationEnactment), `nns` (NodeNetworkState).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-resource-shortnames.json"},{"id":"nmstate-supported-platforms","text":"NMState is supported on bare-metal, IBM Power, IBM Z/LinuxONE, VMware vSphere, and RHOSP, with limited Azure support (DNS only).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-supported-platforms.json"},{"id":"nmstate-three-crds","text":"Kubernetes NMState uses three core CRDs: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-three-crds.json"},{"id":"nmstate-three-custom-resources","text":"Kubernetes NMState uses three key custom resources: NodeNetworkState (NNS), NodeNetworkConfigurationPolicy (NNCP), and NodeNetworkConfigurationEnactment (NNCE).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-three-custom-resources.json"},{"id":"nmstate-troubleshooting-flow","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nmstate-troubleshooting-flow.json"},{"id":"nnce-tracks-per-node-policy-status","text":"NodeNetworkConfigurationEnactment (NNCE) tracks per-node status of policy application (success/failure), named as `<node-name>.<policy-name>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nnce-tracks-per-node-policy-status.json"},{"id":"nncp-declares-desired-network-state","text":"NodeNetworkConfigurationPolicy (NNCP) is the resource administrators create to declare and apply desired network state across matching nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nncp-declares-desired-network-state.json"},{"id":"nns-read-only-per-node","text":"NodeNetworkState (NNS) is read-only and automatically created per node — it reports current network configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nns-read-only-per-node.json"},{"id":"no-direct-etcd-access","text":"All etcd operations must go through the API server or documented backup/restore procedures — direct etcd access is not supported.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/no-direct-etcd-access.json"},{"id":"no-privileged-ports-in-containers","text":"Container processes in OpenShift must not listen on privileged ports (below 1024) because they run as non-root","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/no-privileged-ports-in-containers.json"},{"id":"node-affinity-required-terms-ored-expressions-anded","text":"Node affinity `requiredDuringSchedulingIgnoredDuringExecution` terms are ORed; within each term, match expressions are ANDed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-affinity-required-terms-ored-expressions-anded.json"},{"id":"node-affinity-terms-ored-expressions-anded","text":"Node affinity `nodeSelectorTerms` are ORed; `matchExpressions` within a single term are ANDed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-affinity-terms-ored-expressions-anded.json"},{"id":"node-allocatable-defaults-to-capacity","text":"Node `.status.allocatable` defaults to `.status.capacity`; the difference represents resources reserved for system daemons.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-allocatable-defaults-to-capacity.json"},{"id":"node-api-group-core-v1","text":"The Node resource uses the core v1 API group (`/api/v1/nodes`) and is a cluster-scoped (not namespaced) Kubernetes resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-api-group-core-v1.json"},{"id":"node-belongs-one-mcp","text":"A node can only belong to one MCP; custom pools take priority over the worker pool based on node labels.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-belongs-one-mcp.json"},{"id":"node-cgroupmode-v1-or-v2","text":"`spec.cgroupMode` on the Node config controls whether nodes use cgroups v1 or v2; changing requires node reboots","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-cgroupmode-v1-or-v2.json"},{"id":"node-condition-status-values","text":"Node condition `.status` field accepts three values: True, False, or Unknown.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-condition-status-values.json"},{"id":"node-config-delivery-fully-validated","text":"Node configuration changes are both delivered and validated end-to-end through the immutable pipeline, with API-level validation catching invalid values before they reach nodes.","truth_value":"OUT","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-config-delivery-fully-validated.json"},{"id":"node-config-delivery-fully-validated-and-drift-protected","text":"Node configuration is both delivered through the immutable pipeline and protected against drift, with the MCO marking drifted nodes as Degraded — but only when API-level validation catches all invalid values before they reach nodes.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-config-delivery-fully-validated-and-drift-protected.json"},{"id":"node-config-immutable-delivery-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-config-immutable-delivery-pipeline.json"},{"id":"node-config-singleton-named-cluster","text":"The Node resource (`config.openshift.io/v1`) is a cluster-scoped singleton with canonical name `cluster`, distinct from core Kubernetes Node objects","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-config-singleton-named-cluster.json"},{"id":"node-cordon-sets-unschedulable","text":"`oc adm cordon` sets `unschedulable: true` on a node, which only prevents new pod scheduling and does not evict existing pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-cordon-sets-unschedulable.json"},{"id":"node-fleet-heterogeneous-runtime-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-fleet-heterogeneous-runtime-model.json"},{"id":"node-heartbeat-every-10-seconds","text":"Nodes send heartbeats every 10 seconds to the kube controller manager (node-status-update-frequency: 10s).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-heartbeat-every-10-seconds.json"},{"id":"node-maintenance-order-cordon-drain-uncordon","text":"Correct node maintenance order: cordon first, then drain, perform maintenance, then uncordon.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-maintenance-order-cordon-drain-uncordon.json"},{"id":"node-metrics-dashboard-location","text":"The Node Metrics Dashboard is accessed from the Administrator perspective under Observe → Dashboards → Node cluster filter.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-metrics-dashboard-location.json"},{"id":"node-metrics-kubelet-crio-threshold-50pct","text":"The Node Metrics Dashboard critical threshold for individual Kubelet and CRI-O reserved CPU and memory utilization is 50%.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-metrics-kubelet-crio-threshold-50pct.json"},{"id":"node-metrics-no-critical-data-means-no-anomalies","text":"No data appearing in the Node Metrics Dashboard Critical category means no anomalies were detected, not a dashboard malfunction.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-metrics-no-critical-data-means-no-anomalies.json"},{"id":"node-metrics-system-reserved-threshold-80pct","text":"The Node Metrics Dashboard critical threshold for overall system reserved CPU and memory utilization is 80%.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-metrics-system-reserved-threshold-80pct.json"},{"id":"node-monitor-grace-period-40s","text":"The default `node-monitor-grace-period` is 40 seconds; after this period without a heartbeat, node status becomes `Unknown`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-monitor-grace-period-40s.json"},{"id":"node-monitor-grace-period-40s-not-modifiable","text":"The node-monitor-grace-period is 40 seconds and cannot be modified; after this period without heartbeat the node is marked Unhealthy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-monitor-grace-period-40s-not-modifiable.json"},{"id":"node-phase-deprecated-use-conditions","text":"The Node `.status.phase` field is deprecated and never populated; `.status.conditions` should be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-phase-deprecated-use-conditions.json"},{"id":"node-podcidrs-dual-stack-limit","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-podcidrs-dual-stack-limit.json"},{"id":"node-reserved-memory-formula","text":"System reserved resources are calculated as total capacity minus allocatable (kube_node_status_capacity - kube_node_status_allocatable).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-reserved-memory-formula.json"},{"id":"node-selector-operators","text":"Valid node selector operators are `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, and `Lt`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-selector-operators.json"},{"id":"node-selector-operators-list","text":"Node selector operators are: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-selector-operators-list.json"},{"id":"node-statuses-tracks-per-node-deployment","text":"The `status.nodeStatuses[]` field on static pod operators tracks per-node deployment state including `currentRevision`, `targetRevision`, `lastFailedRevision`, and `lastFallbackCount`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-statuses-tracks-per-node-deployment.json"},{"id":"node-taint-effects-three","text":"Node taints support three effects: NoSchedule (hard block, existing pods stay), PreferNoSchedule (soft, scheduler tries to avoid), and NoExecute (evicts non-tolerating pods).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-taint-effects-three.json"},{"id":"node-tuning-operator-uses-tuned-one-per-node","text":"The Node Tuning Operator uses TuneD daemons for kernel tuning, running one per node across all nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/node-tuning-operator-uses-tuned-one-per-node.json"},{"id":"nodemetrics-read-only","text":"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}`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nodemetrics-read-only.json"},{"id":"nodename-bypasses-scheduler","text":"Setting `nodeName` on a Pod bypasses the scheduler entirely, directly assigning the Pod to the named node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nodename-bypasses-scheduler.json"},{"id":"nodenetworkstate-read-only","text":"NodeNetworkState (NNS) resources are read-only and report current node network state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nodenetworkstate-read-only.json"},{"id":"nodes-must-be-uncordoned-after-restart","text":"Nodes are cordoned during graceful shutdown and must be uncordoned during restart to become schedulable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nodes-must-be-uncordoned-after-restart.json"},{"id":"non-graceful-shutdown-causes","text":"Non-graceful node shutdown can be caused by hardware/system failures, missing Inhibitor Locks triggers, or misconfigured `shutdownGracePeriod`/`shutdownGracePeriodCriticalPods` settings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/non-graceful-shutdown-causes.json"},{"id":"nutanix-ahv-hypervisor","text":"Nutanix AHV is the hypervisor layer used for OCP installations on Nutanix; Prism Element manages individual clusters.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-ahv-hypervisor.json"},{"id":"nutanix-boot-type-legacy-417","text":"In OCP 4.17, the boot type for Nutanix VMs must be set to Legacy (options are Legacy, SecureBoot, UEFI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-boot-type-legacy-417.json"},{"id":"nutanix-cco-manual-mode-required","text":"The Cloud Credential Operator (CCO) must be set to manual mode for Nutanix installations — this is not optional.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-cco-manual-mode-required.json"},{"id":"nutanix-ccoctl-linux-only","text":"The `ccoctl` binary for CCO manual mode is Linux-only and must be run in a Linux environment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-ccoctl-linux-only.json"},{"id":"nutanix-csi-storage-integration","text":"Nutanix provides CSI-based persistent storage integration (Nutanix Volumes/Files) out of the box for OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-csi-storage-integration.json"},{"id":"nutanix-default-cni-ovnkubernetes","text":"The default (and only listed) network type for Nutanix OCP installations is OVNKubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-default-cni-ovnkubernetes.json"},{"id":"nutanix-default-replicas-3-3","text":"Default compute replicas for Nutanix OCP installations is 3; control plane replicas must be 3 (or 1 for SNO).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-default-replicas-3-3.json"},{"id":"nutanix-delete-machine-annotation","text":"The annotation `machine.openshift.io/delete-machine=\"true\"` marks machines for deletion during scale-down on Nutanix (and other platforms).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-delete-machine-annotation.json"},{"id":"nutanix-disk-reserved-indices","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-disk-reserved-indices.json"},{"id":"nutanix-dns-api-ingress-vips","text":"Nutanix OCP installations require DNS records for `api.<cluster>.<domain>` and `*.apps.<cluster>.<domain>`, resolvable both externally and from within the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-dns-api-ingress-vips.json"},{"id":"nutanix-failure-domain-same-network","text":"Machines across Nutanix Prism Element failure domains must reside on the same Ethernet network with subnets sharing the same CIDR containing cluster VIPs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-failure-domain-same-network.json"},{"id":"nutanix-failure-domain-three-recommended","text":"Three failure domains are recommended for high availability on Nutanix OpenShift clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-failure-domain-three-recommended.json"},{"id":"nutanix-failure-domains-ha","text":"Nutanix failure domains enable high availability by distributing VMs across different Prism Element clusters and subnets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-failure-domains-ha.json"},{"id":"nutanix-full-platform-integration","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-full-platform-integration.json"},{"id":"nutanix-gpu-passthrough-compute","text":"GPU passthrough is supported on Nutanix compute machines, identified by Name or DeviceID.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-gpu-passthrough-compute.json"},{"id":"nutanix-infrastructure-cr-before-machinesets","text":"The Infrastructure CR (infrastructures.config.openshift.io) must be configured with failure domains before updating control plane or compute machine sets to reference them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-infrastructure-cr-before-machinesets.json"},{"id":"nutanix-install-config-immutable","text":"Parameters in install-config.yaml (including networking) cannot be changed after OCP installation on Nutanix.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-install-config-immutable.json"},{"id":"nutanix-ipi-primary-install-method","text":"OCP on Nutanix uses installer-provisioned infrastructure (IPI) as the primary installation method.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-ipi-primary-install-method.json"},{"id":"nutanix-ipi-supported-from-ocp-411","text":"Nutanix is a supported IPI platform for OpenShift Container Platform, introduced in OCP 4.11.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-ipi-supported-from-ocp-411.json"},{"id":"nutanix-min-versions-aos-prism","text":"Nutanix minimum versions for OCP 4.17: AOS 6.5.2.7+ and Prism Central pc.2022.6+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-min-versions-aos-prism.json"},{"id":"nutanix-one-subnet-per-failure-domain","text":"Only one subnet per failure domain per OpenShift cluster is supported on Nutanix.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-one-subnet-per-failure-domain.json"},{"id":"nutanix-only-ipv4-supported","text":"Only IPv4 addresses are supported for Nutanix network configuration in OCP 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-only-ipv4-supported.json"},{"id":"nutanix-prism-central-management-plane","text":"Nutanix Prism Central is used as the management plane for OCP cluster provisioning on Nutanix.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-prism-central-management-plane.json"},{"id":"nutanix-requires-api-ingress-vips","text":"Nutanix platform configuration requires apiVIPs and ingressVIPs as mandatory parameters in install-config.yaml.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-requires-api-ingress-vips.json"},{"id":"nutanix-runs-on-ahv-integrates-prism-central","text":"OCP on Nutanix runs on the AHV hypervisor and integrates with Prism Central (not Prism Element directly) for IPI installations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-runs-on-ahv-integrates-prism-central.json"},{"id":"nutanix-single-prism-central-required","text":"All Nutanix Prism Element instances used as failure domains must be managed by a single Prism Central instance; multi-Prism-Central is unsupported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-single-prism-central-required.json"},{"id":"nutanix-single-prism-element","text":"Nutanix infrastructure configuration requires `prismCentral` and `prismElements`; currently only one Prism Element per cluster is supported","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-single-prism-element.json"},{"id":"nutanix-standard-cluster-resources","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-standard-cluster-resources.json"},{"id":"nutanix-supported-ocp-install-platform","text":"Nutanix is a supported installation platform for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-supported-ocp-install-platform.json"},{"id":"nutanix-supported-ocp-platform","text":"Nutanix is a supported installation platform for OpenShift Container Platform 4.17, running on Nutanix AHV (Acropolis Hypervisor).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-supported-ocp-platform.json"},{"id":"nutanix-supports-ipi-and-upi","text":"Nutanix supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods for OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-supports-ipi-and-upi.json"},{"id":"nutanix-upi-manual-cleanup-after-destroy","text":"UPI clusters on Nutanix may leave behind resources requiring manual cleanup after `openshift-install destroy cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-upi-manual-cleanup-after-destroy.json"},{"id":"nutanix-uses-prism-central-api","text":"Nutanix installations use Prism Central (not Prism Element) as the API endpoint for the OpenShift installer integration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nutanix-uses-prism-central-api.json"},{"id":"nvidia-gpu-operator-supported-by-nvidia-only","text":"The NVIDIA GPU Operator is supported only by NVIDIA, not by Red Hat.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/nvidia-gpu-operator-supported-by-nvidia-only.json"},{"id":"oadp-1-1-required-for-csi-on-ocp-4-11","text":"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+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-1-1-required-for-csi-on-ocp-4-11.json"},{"id":"oadp-1-4-supports-ocp-4-14-to-4-17","text":"OADP 1.4 supports OCP 4.14–4.17; OADP 1.3 supports OCP 4.12–4.15.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-1-4-supports-ocp-4-14-to-4-17.json"},{"id":"oadp-built-on-velero","text":"OADP (OpenShift API for Data Protection) is the supported method for application-level backup and restore and is built on Velero.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-built-on-velero.json"},{"id":"oadp-csi-plugin-builtin-1-4","text":"In OADP 1.4, the CSI plugin is built into Velero and no longer requires a separate init container.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-csi-plugin-builtin-1-4.json"},{"id":"oadp-data-mover-uses-kopia","text":"OADP Data Mover uses Kopia under the hood to move CSI snapshots to remote object storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-data-mover-uses-kopia.json"},{"id":"oadp-five-core-apis","text":"OADP provides five core APIs: Backup, Restore, Schedule, BackupStorageLocation, and VolumeSnapshotLocation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-five-core-apis.json"},{"id":"oadp-full-cluster-backup-not-supported","text":"Full cluster backup and restore is not supported by OADP — only workload namespaces and cluster-scoped resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-full-cluster-backup-not-supported.json"},{"id":"oadp-installs-in-openshift-adp-namespace","text":"OADP installs in the `openshift-adp` namespace by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-installs-in-openshift-adp-namespace.json"},{"id":"oadp-is-ocp-backup-solution","text":"OADP (OpenShift API for Data Protection) is the supported backup and restore solution for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-is-ocp-backup-solution.json"},{"id":"oadp-is-velero-based","text":"OADP (OpenShift API for Data Protection) is the Red Hat-supported solution for application backup and restore, built on Velero.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-is-velero-based.json"},{"id":"oadp-not-disaster-recovery","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-not-disaster-recovery.json"},{"id":"oadp-requires-cluster-admin-and-object-storage","text":"OADP requires the cluster-admin role and object storage (S3-compatible, AWS, Azure, GCP, ODF, IBM Cloud).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-requires-cluster-admin-and-object-storage.json"},{"id":"oadp-upgrade-sequential-only","text":"OADP upgrades must be sequential — never skip minor versions (e.g., 1.1→1.2→1.3→1.4).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oadp-upgrade-sequential-only.json"},{"id":"oauth-api-group","text":"OAuth API objects in OpenShift live in the `oauth.openshift.io` API group and are OpenShift-specific extensions (not part of upstream Kubernetes).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-api-group.json"},{"id":"oauth-api-group-version","text":"OAuth API resources in OpenShift belong to the `oauth.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-api-group-version.json"},{"id":"oauth-api-objects-openshift-specific","text":"OAuth API objects (OAuthClient, OAuthAuthorizeToken, OAuthAccessToken, UserOAuthAccessToken, OAuthClientAuthorization) are OpenShift-specific resources, not part of standard Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-api-objects-openshift-specific.json"},{"id":"oauth-authorize-token-dual-user-verification","text":"On OAuthAuthorizeToken, both `userName` and `userUID` must match for the token to be valid (dual verification).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-authorize-token-dual-user-verification.json"},{"id":"oauth-authorize-token-pkce-support","text":"OAuthAuthorizeToken supports PKCE (RFC 7636) via `codeChallenge` and `codeChallengeMethod` fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-authorize-token-pkce-support.json"},{"id":"oauth-compatibility-level-1","text":"All five OAuth API resources have Compatibility Level 1: stable within a major release for at least 12 months or 3 minor releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-compatibility-level-1.json"},{"id":"oauth-config-requires-integrated-oauth","text":"The OAuth resource configuration (`oauth.config.openshift.io`) is only honored when the Authentication resource has `type: IntegratedOAuth`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-config-requires-integrated-oauth.json"},{"id":"oauth-config-singleton-named-cluster","text":"The OAuth resource (`config.openshift.io/v1`) is a cluster-scoped singleton named `cluster` that configures the integrated OAuth server","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-config-singleton-named-cluster.json"},{"id":"oauth-delete-token-revokes-session","text":"Deleting an OAuthAccessToken object effectively revokes that user's session/token.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-delete-token-revokes-session.json"},{"id":"oauth-expiresin-seconds-from-creation","text":"The `expiresIn` field on OAuth tokens is measured in seconds from `CreationTimestamp`, defining absolute maximum token lifetime.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-expiresin-seconds-from-creation.json"},{"id":"oauth-five-api-resources","text":"The five OAuth API resources are: OAuthAccessToken, OAuthAuthorizeToken, OAuthClient, OAuthClientAuthorization, and UserOAuthAccessToken.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-five-api-resources.json"},{"id":"oauth-inactivity-timeout-sliding","text":"The `inactivityTimeoutSeconds` field on OAuthAccessToken is automatically incremented on token use, implementing sliding session expiry rather than fixed expiry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-inactivity-timeout-sliding.json"},{"id":"oauth-mapping-method-default-claim","text":"The `mappingMethod` for OAuth identity providers defaults to `\"claim\"`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-mapping-method-default-claim.json"},{"id":"oauth-metadata-external-in-openshift-config","text":"External OAuth metadata is stored in a ConfigMap in the `openshift-config` namespace; integrated OAuth metadata is in `openshift-config-managed`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-metadata-external-in-openshift-config.json"},{"id":"oauth-missing-secret-silently-ignored","text":"If a referenced secret/configmap for an OAuth identity provider is missing, the provider is silently not honored (no error)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-missing-secret-silently-ignored.json"},{"id":"oauth-requires-integratedoauth-type","text":"OAuth config is only honored when the Authentication config has `type` set to `IntegratedOAuth`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-requires-integratedoauth-type.json"},{"id":"oauth-resources-cluster-scoped","text":"OAuth API resources (OAuthAccessToken, OAuthAuthorizeToken, etc.) are cluster-scoped resources (no namespace in the API path).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-resources-cluster-scoped.json"},{"id":"oauth-secrets-configmaps-openshift-config","text":"All secrets and configmaps referenced by OAuth identity providers must reside in the `openshift-config` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-secrets-configmaps-openshift-config.json"},{"id":"oauth-server-route-namespace","text":"The OpenShift OAuth server is exposed via a route named `oauth-openshift` in the `openshift-authentication` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-server-route-namespace.json"},{"id":"oauth-session-lifecycle-management","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-session-lifecycle-management.json"},{"id":"oauth-supported-identity-providers","text":"Supported OAuth identity provider types: HTPasswd, LDAP, BasicAuth, RequestHeader, Keystone, GitHub, GitLab, Google, OpenID Connect","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-supported-identity-providers.json"},{"id":"oauth-token-inactivity-auto-increments","text":"OAuthAccessToken `inactivityTimeoutSeconds` auto-increments when the token is used, resetting the idle timeout.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-token-inactivity-auto-increments.json"},{"id":"oauth-token-sha256-prefix","text":"OAuth access token resource names use the format `sha256~<base64url-hash>`, derived by SHA-256 hashing the raw token and encoding with URL-safe unpadded base64 (RFC 4648).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-token-sha256-prefix.json"},{"id":"oauth-watch-endpoints-deprecated","text":"The dedicated `/watch/` endpoints for OAuth resources are deprecated; the `?watch=true` query parameter on list operations should be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauth-watch-endpoints-deprecated.json"},{"id":"oauthclient-additional-secrets-rotation","text":"OAuthClient `additionalSecrets` field enables secret rotation without downtime by supporting multiple valid secrets simultaneously.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-additional-secrets-rotation.json"},{"id":"oauthclient-cluster-scoped","text":"OAuthClient is a cluster-scoped resource (no namespace) in the `oauth.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-cluster-scoped.json"},{"id":"oauthclient-grant-method-auto-prompt","text":"OAuthClient `grantMethod` field accepts `auto` (auto-approve for trusted clients) or `prompt` (requires user approval for third-party clients).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-grant-method-auto-prompt.json"},{"id":"oauthclient-inactivity-timeout-not-retroactive","text":"Changing `accessTokenInactivityTimeoutSeconds` on an OAuthClient does NOT retroactively affect existing tokens — only newly issued tokens.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-inactivity-timeout-not-retroactive.json"},{"id":"oauthclient-respond-with-challenges","text":"OAuthClient `respondWithChallenges: true` returns WWW-Authenticate challenges instead of redirects, useful for CLI and non-browser clients.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-respond-with-challenges.json"},{"id":"oauthclient-scope-restriction-allowlist","text":"OAuthClient scope restrictions use an allowlist model: any matching restriction allows the scope; if no restriction matches, the scope is denied.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-scope-restriction-allowlist.json"},{"id":"oauthclient-token-inactivity-min-300","text":"OAuthClient `accessTokenInactivityTimeoutSeconds` minimum non-zero value is 300 (5 minutes); setting to 0 disables inactivity timeout entirely.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclient-token-inactivity-min-300.json"},{"id":"oauthclientauthorization-cluster-scoped","text":"OAuthClientAuthorization is a cluster-scoped resource in the `oauth.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclientauthorization-cluster-scoped.json"},{"id":"oauthclientauthorization-delete-revokes","text":"Deleting an OAuthClientAuthorization effectively revokes the user's authorization for that OAuth client.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclientauthorization-delete-revokes.json"},{"id":"oauthclientauthorization-username-and-uid-required","text":"Both `userName` AND `userUID` must match for an OAuthClientAuthorization to be valid — knowing just the username is insufficient.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oauthclientauthorization-username-and-uid-required.json"},{"id":"observability-follows-platform-enablement-pattern","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-follows-platform-enablement-pattern.json"},{"id":"observability-four-pillars","text":"Red Hat OpenShift Observability covers four signal types: metrics, logs, traces, and events.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-four-pillars.json"},{"id":"observability-integrated-platform-capability","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-integrated-platform-capability.json"},{"id":"observability-requires-layered-enablement","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-requires-layered-enablement.json"},{"id":"observability-stack-production-complete","text":"The full OpenShift observability stack (platform monitoring + user workload monitoring + network observability + power monitoring + distributed tracing) is production-complete only when all component-level tech preview restrictions are resolved.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-stack-production-complete.json"},{"id":"observability-subsystems","text":"OpenShift Observability encompasses monitoring (Prometheus/Thanos), logging (OpenShift Logging subsystem), distributed tracing (Jaeger/Tempo), and network observability (flow-based analysis).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observability-subsystems.json"},{"id":"observed-config-lives-in-spec","text":"The `observedConfig` field on OpenShift operator resources is stored in `.spec` (not `.status`) because it serves as input to the operator's reconciliation loop","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/observed-config-lives-in-spec.json"},{"id":"oc-adm-drain-cordon-uncordon","text":"`oc adm cordon` marks a node unschedulable; `oc adm uncordon` re-enables scheduling; `oc adm drain` evicts pods and marks the node unschedulable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-drain-cordon-uncordon.json"},{"id":"oc-adm-drain-cordon-uncordon-node-maintenance","text":"Node maintenance uses `oc adm cordon` (mark unschedulable), `oc adm drain` (evacuate pods), and `oc adm uncordon` (mark schedulable again).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-drain-cordon-uncordon-node-maintenance.json"},{"id":"oc-adm-drain-uses-eviction-api","text":"`oc adm drain` uses the Eviction API internally to safely remove pods from a node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-drain-uses-eviction-api.json"},{"id":"oc-adm-groups-command-family","text":"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`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-groups-command-family.json"},{"id":"oc-adm-groups-commands","text":"Groups are managed via `oc adm groups new`, `oc adm groups add-users`, and `oc adm groups remove-users` commands.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-groups-commands.json"},{"id":"oc-adm-groups-management-commands","text":"`oc adm groups new`, `oc adm groups add-users`, and `oc adm groups remove-users` are the standard commands for managing group membership","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-groups-management-commands.json"},{"id":"oc-adm-must-gather-for-support","text":"`oc adm must-gather` is the command to collect cluster data for Red Hat support cases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-must-gather-for-support.json"},{"id":"oc-adm-node-logs-by-role","text":"The command `oc adm node-logs --role <role> -u kubelet` gathers kubelet logs by node role without requiring SSH access.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-node-logs-by-role.json"},{"id":"oc-adm-node-logs-preferred-over-ssh","text":"`oc adm node-logs --role=master -u kubelet` is the preferred way to get node logs over SSH when the API is accessible.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-node-logs-preferred-over-ssh.json"},{"id":"oc-adm-policy-add-scc-to-user-command","text":"The command `oc adm policy add-scc-to-user <scc> <user>` grants an SCC to a user.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-policy-add-scc-to-user-command.json"},{"id":"oc-adm-policy-manages-role-assignments","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-policy-manages-role-assignments.json"},{"id":"oc-adm-policy-who-can-uses-resourceaccessreview","text":"The CLI command `oc adm policy who-can <verb> <resource> -n <namespace>` uses the LocalResourceAccessReview/ResourceAccessReview API under the hood.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-policy-who-can-uses-resourceaccessreview.json"},{"id":"oc-adm-policy-z-flag-service-account","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-policy-z-flag-service-account.json"},{"id":"oc-adm-release-mirror-command","text":"`oc adm release mirror` mirrors OCP release images to a local registry; its `imageContentSources` output must be added to `install-config.yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-release-mirror-command.json"},{"id":"oc-adm-top-requires-metrics-cluster-reader","text":"`oc adm top nodes/pods` requires both the metrics stack installed and `cluster-reader` permission.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-top-requires-metrics-cluster-reader.json"},{"id":"oc-adm-upgrade-include-not-recommended","text":"`oc adm upgrade --include-not-recommended` shows conditional updates with known risks that are not normally displayed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-upgrade-include-not-recommended.json"},{"id":"oc-adm-upgrade-primary-command","text":"`oc adm upgrade` is the primary CLI command for viewing and applying cluster updates; `--to-latest=true` applies the latest, `--to=<version>` targets a specific version","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-upgrade-primary-command.json"},{"id":"oc-adm-upgrade-status-tech-preview","text":"`oc adm upgrade status` is a Technology Preview command requiring `OC_ENABLE_CMD_UPGRADE_STATUS=true` environment variable; works on clusters 4.12+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-adm-upgrade-status-tech-preview.json"},{"id":"oc-api-resources-and-explain-for-discovery","text":"`oc api-resources` lists all available API resources including extensions; `oc explain <resource>` inspects API object schemas from the CLI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-api-resources-and-explain-for-discovery.json"},{"id":"oc-api-resources-config-group","text":"Config API resources can be listed with `oc api-resources --api-group=config.openshift.io`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-api-resources-config-group.json"},{"id":"oc-api-resources-discovers-apis","text":"Available API resources on an OpenShift cluster can be discovered using `oc api-resources` and explored with `oc explain <resource>`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-api-resources-discovers-apis.json"},{"id":"oc-api-resources-lists-all-api-objects","text":"The `oc api-resources` command lists all available API objects in the cluster, including their short names, API groups, and whether they are namespaced.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-api-resources-lists-all-api-objects.json"},{"id":"oc-api-resources-lists-extensions","text":"The command `oc api-resources` lists all available API resources on an OpenShift cluster, including extension APIs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-api-resources-lists-extensions.json"},{"id":"oc-auth-can-i-checks-permissions","text":"`oc auth can-i <verb> <resource>` is the CLI equivalent of creating SubjectAccessReview/SelfSubjectAccessReview resources for checking permissions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-auth-can-i-checks-permissions.json"},{"id":"oc-auth-can-i-wraps-sar","text":"The `oc auth can-i --as=<user>` command is the CLI equivalent of creating a SubjectAccessReview","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-auth-can-i-wraps-sar.json"},{"id":"oc-cli-primary-tool-admins-and-devs","text":"The `oc` CLI is the primary general-purpose OpenShift CLI tool, used by both administrators and developers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-cli-primary-tool-admins-and-devs.json"},{"id":"oc-compatible-with-kubectl","text":"The `oc` CLI is compatible with `kubectl` but provides additional OpenShift-specific features.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-compatible-with-kubectl.json"},{"id":"oc-create-token-for-service-account","text":"`oc create token <service-account-name>` creates a TokenRequest for a service account (bound token with audience/expiry).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-create-token-for-service-account.json"},{"id":"oc-debug-node-chroot-host","text":"`oc debug node/<node>` followed by `chroot /host` is the standard method to access a node's filesystem for troubleshooting.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-debug-node-chroot-host.json"},{"id":"oc-describe-clusterversion-detailed","text":"`oc describe clusterversion` provides detailed update history and available updates for the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-describe-clusterversion-detailed.json"},{"id":"oc-explain-config-resource","text":"`oc explain <resource>.config.openshift.io` shows the schema/documentation for a cluster config resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-explain-config-resource.json"},{"id":"oc-explain-from-cluster-api","text":"`oc explain <resource>` retrieves documentation directly from the cluster's API schema, useful for exploring resource fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-explain-from-cluster-api.json"},{"id":"oc-explain-inspects-api-schema","text":"The `oc explain <resource>` command inspects API object schemas directly from the cluster, with `oc explain <resource>.spec` drilling into spec fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-explain-inspects-api-schema.json"},{"id":"oc-explain-inspects-operator-api-schemas","text":"The `oc explain` command can be used to inspect Operator API object schemas directly from the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-explain-inspects-operator-api-schemas.json"},{"id":"oc-explain-shows-api-fields","text":"The `oc explain <resource>` command displays API field documentation for a resource directly from the CLI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-explain-shows-api-fields.json"},{"id":"oc-extends-kubectl","text":"The `oc` CLI extends `kubectl` with OpenShift-specific commands such as `oc new-project`, `oc new-app`, and others.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-extends-kubectl.json"},{"id":"oc-get-clusterversion-quick-status","text":"`oc get clusterversion` provides a quick summary of cluster version, availability, progressing status, and uptime.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-get-clusterversion-quick-status.json"},{"id":"oc-homebrew-formula-name","text":"The Homebrew formula for `oc` is `openshift-cli` (installed via `brew install openshift-cli`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-homebrew-formula-name.json"},{"id":"oc-idle-scales-to-zero","text":"The `oc idle <service>` command scales all scalable resources associated with a service to zero replicas to conserve resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-idle-scales-to-zero.json"},{"id":"oc-idle-single-project-scope","text":"The `oc idle` command is limited to a single project — it cannot idle resources across multiple projects in one invocation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-idle-single-project-scope.json"},{"id":"oc-import-image-cli-for-imagestreamimport","text":"The `oc import-image` command is the CLI interface to the ImageStreamImport API; use `--confirm` to actually import, `--all` to import an entire repository.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-import-image-cli-for-imagestreamimport.json"},{"id":"oc-in-pod-defaults-to-pod-namespace","text":"When `oc` runs inside a pod without a namespace specified, it defaults to the pod's namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-in-pod-defaults-to-pod-namespace.json"},{"id":"oc-login-creates-oauthaccesstoken","text":"The `oc login` flow creates OAuthAccessToken objects behind the scenes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-login-creates-oauthaccesstoken.json"},{"id":"oc-login-web-uses-http-localhost","text":"The `oc login --web` flag runs a localhost HTTP server (not HTTPS) for the callback — a security concern on shared workstations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-login-web-uses-http-localhost.json"},{"id":"oc-mirror-generates-idms","text":"The `oc-mirror` plugin generates IDMS manifests when mirroring content to a local registry","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-mirror-generates-idms.json"},{"id":"oc-must-match-cluster-version","text":"The `oc` CLI must match the cluster version — earlier versions of `oc` cannot complete all commands for the target OCP release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-must-match-cluster-version.json"},{"id":"oc-new-app-creates-resources-not-routes","text":"`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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-new-app-creates-resources-not-routes.json"},{"id":"oc-new-app-template-instantiation","text":"`oc new-app --template=<name>` can instantiate applications from templates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-new-app-template-instantiation.json"},{"id":"oc-new-app-tilde-syntax-creates-s2i","text":"The `oc new-app <builder-image>~<git-repo-url>` tilde syntax creates an S2I BuildConfig automatically.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-new-app-tilde-syntax-creates-s2i.json"},{"id":"oc-new-project-creates-and-switches","text":"`oc new-project` both creates a new project and switches the current context to that project.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-new-project-creates-and-switches.json"},{"id":"oc-new-project-uses-projectrequest","text":"`oc new-project` uses the ProjectRequest API, not direct Project creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-new-project-uses-projectrequest.json"},{"id":"oc-patch-pv-reclaim-policy","text":"The command `oc patch pv <name> -p '{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}'` changes the reclaim policy on an existing PV.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-patch-pv-reclaim-policy.json"},{"id":"oc-process-renders-template","text":"`oc process` renders a template into a resource list; `oc new-app --template=` can process and create resources in one step","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-process-renders-template.json"},{"id":"oc-proxy-env-vars","text":"The `oc` CLI respects `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables; authentication headers are only sent over HTTPS.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-proxy-env-vars.json"},{"id":"oc-rpm-not-supported-rhel9","text":"RPM installation of the `oc` CLI (`yum install openshift-clients`) is not supported on RHEL 9 — binary download must be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-rpm-not-supported-rhel9.json"},{"id":"oc-set-image-lookup-command","text":"`oc set image-lookup <imagestream>` enables image lookup on an image stream; `oc set image-lookup deploy/<name>` enables it on a specific resource; `--enabled=false` disables it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-set-image-lookup-command.json"},{"id":"oc-set-probe-syntax","text":"Health probes are set with `oc set probe deployment/<name> --liveness|--readiness --get-url=http://:port/path --initial-delay-seconds=N`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-set-probe-syntax.json"},{"id":"oc-set-triggers-deploy-syntax","text":"The command `oc set triggers deploy/<name> --from-image=<stream>:<tag> -c <container>` configures image stream change triggers on a Deployment by setting the `image.openshift.io/triggers` annotation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-set-triggers-deploy-syntax.json"},{"id":"oc-set-volume-default-emptydir","text":"The default volume type when using `oc set volume --add` is `emptyDir`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-set-volume-default-emptydir.json"},{"id":"oc-set-volume-overwrite-flag","text":"The `--overwrite` flag is required when updating an existing volume with `oc set volume`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-set-volume-overwrite-flag.json"},{"id":"oc-start-build-from-dir-binary-input","text":"The `oc start-build --from-dir` command uploads local content as binary input to a build.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-start-build-from-dir-binary-input.json"},{"id":"oc-tag-creates-permanent-tags-by-default","text":"The default `oc tag` behavior creates permanent tags (pinned to image ID); use `--alias=true` to create tracking tags.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-tag-creates-permanent-tags-by-default.json"},{"id":"oc-version-must-match-cluster","text":"The `oc` binary version must match the cluster version; earlier versions cannot complete all commands.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oc-version-must-match-cluster.json"},{"id":"oci-agent-based-installer","text":"OpenShift on OCI is installed using the Agent-based Installer, which provides Assisted Installation capabilities for both connected and disconnected environments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-agent-based-installer.json"},{"id":"oci-agent-iso-command","text":"The command `./openshift-install agent create image --log-level debug` generates the agent ISO image for OCI installations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-agent-iso-command.json"},{"id":"oci-cluster-topologies","text":"Supported cluster topologies on OCI are: single-node, HA (3 control plane + 2 compute minimum), and compact 3-node (3 control plane only).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-cluster-topologies.json"},{"id":"oci-disconnected-bootartifactsbaseurl","text":"Disconnected OCI installations require `bootArtifactsBaseURL` in `agent-config.yaml` and a separately hosted rootfs image.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-disconnected-bootartifactsbaseurl.json"},{"id":"oci-dns-a-records-required","text":"OCI installations require three DNS A records: `api.<cluster>.<domain>` and `api-int.<cluster>.<domain>` pointing to apiVIP, and `*.apps.<cluster>.<domain>` pointing to ingressVIP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-dns-a-records-required.json"},{"id":"oci-ovnkubernetes-default-network","text":"OVNKubernetes is the default network type used for OCI installations of OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-ovnkubernetes-default-network.json"},{"id":"oci-platform-type-external","text":"OCI is configured as `platform.external` with `platformName: oci` and `cloudControllerManager: External` in install-config.yaml — it is not a native integrated platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-platform-type-external.json"},{"id":"oci-rendezvousip-must-match-instance","text":"The `rendezvousIP` in agent-config.yaml must be an IPv4 address from the VCN CIDR that matches at least one booted instance's IP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-rendezvousip-must-match-instance.json"},{"id":"oci-supported-architectures","text":"OCI installations support 64-bit x86 (amd64) and 64-bit ARM (arm64) architectures.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-supported-architectures.json"},{"id":"oci-supported-platform-ocp-417","text":"Oracle Cloud Infrastructure (OCI) is a supported installation target for OpenShift Container Platform starting from version 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-supported-platform-ocp-417.json"},{"id":"oci-uefi-boot-required","text":"Custom images on OCI must be configured to boot in UEFI mode for OpenShift installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oci-uefi-boot-required.json"},{"id":"ocm-manages-rosa-aro-osd","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocm-manages-rosa-aro-osd.json"},{"id":"ocm-saas-at-console-redhat-com","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocm-saas-at-console-redhat-com.json"},{"id":"ocm-supports-three-cluster-types","text":"OCM supports three cluster types: OpenShift Container Platform (self-managed), Red Hat OpenShift Service on AWS (ROSA), and OpenShift Dedicated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocm-supports-three-cluster-types.json"},{"id":"ocm-update-strategy-automatic-or-manual","text":"OCM cluster update strategy can be set to automatic (scheduled day/time) or manual.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocm-update-strategy-automatic-or-manual.json"},{"id":"ocm-url-console-redhat","text":"OpenShift Cluster Manager (OCM) is accessible at `console.redhat.com/openshift` and requires a Red Hat account belonging to an OpenShift organization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocm-url-console-redhat.json"},{"id":"ocp-3x-to-4x-architectural-shift","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-3x-to-4x-architectural-shift.json"},{"id":"ocp-410-san-certificate-requirement","text":"Starting with OCP 4.10, HTTPS certificates must contain Subject Alternative Name (SAN) fields; certificates with only CommonName are rejected.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-410-san-certificate-requirement.json"},{"id":"ocp-417-favors-vector-lokistack","text":"OpenShift 4.17 favors Vector (collector) + LokiStack (store) over the legacy Fluentd + Elasticsearch logging stack.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-417-favors-vector-lokistack.json"},{"id":"ocp-417-follows-416","text":"OCP 4.17 follows OCP 4.16 in the continuous 4.x minor-version release cadence.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-417-follows-416.json"},{"id":"ocp-417-has-16-optional-capabilities","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-417-has-16-optional-capabilities.json"},{"id":"ocp-417-optional-cluster-capabilities","text":"OpenShift Container Platform 4.17 supports optional cluster capabilities that can be selectively enabled or disabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-417-optional-cluster-capabilities.json"},{"id":"ocp-417-uses-kubernetes-130","text":"OpenShift Container Platform 4.17 is built on Kubernetes 1.30 with CRI-O as the container runtime.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-417-uses-kubernetes-130.json"},{"id":"ocp-421-ai-workloads-section","text":"OpenShift Container Platform 4.21 has a dedicated documentation section for AI workloads, signaling first-class platform support for AI training.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-421-ai-workloads-section.json"},{"id":"ocp-421-current-release","text":"OCP 4.21 is the current documented release of OpenShift Container Platform","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-421-current-release.json"},{"id":"ocp-421-latest-version","text":"OpenShift Container Platform 4.21 is the latest version in the 4.x release line as of the current documentation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-421-latest-version.json"},{"id":"ocp-4x-kubernetes-based","text":"OpenShift Container Platform 4.x is built on Kubernetes for deploying and managing containerized applications at scale.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-4x-kubernetes-based.json"},{"id":"ocp-additional-default-clusterroles","text":"OpenShift adds additional default ClusterRoles beyond Kubernetes defaults, including `admin`, `edit`, `view`, `cluster-admin`, and `self-provisioner`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-additional-default-clusterroles.json"},{"id":"ocp-adds-enterprise-features","text":"OpenShift adds enterprise features that Kubernetes lacks at the platform level: authentication, networking, security, monitoring, and log management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-adds-enterprise-features.json"},{"id":"ocp-admin-ack-required-api-removal-gate","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-admin-ack-required-api-removal-gate.json"},{"id":"ocp-admin-can-disable-self-provisioning","text":"Cluster admins can prevent authenticated user groups from self-provisioning new projects in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-admin-can-disable-self-provisioning.json"},{"id":"ocp-admission-plugins-skip-privileged-projects","text":"Admission plugins (pod security admission, SCCs, cluster resource quotas, image reference resolution) do not work in highly privileged projects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-admission-plugins-skip-privileged-projects.json"},{"id":"ocp-agent-installer-available-412","text":"The Agent-based Installer is available starting from OCP 4.12.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-agent-installer-available-412.json"},{"id":"ocp-agent-installer-bootable-iso","text":"The Agent-based Installer generates a bootable ISO containing the cluster configuration, eliminating the need for a separate bootstrap machine.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-agent-installer-bootable-iso.json"},{"id":"ocp-agent-installer-disconnected","text":"The Agent-based Installer is the recommended method for disconnected/air-gapped on-premise OpenShift installations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-agent-installer-disconnected.json"},{"id":"ocp-ai-training-multi-node","text":"OpenShift AI workload support focuses on large-scale AI training workloads running reliably across multiple nodes (distributed training).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ai-training-multi-node.json"},{"id":"ocp-alertingrule-generates-prometheusrule","text":"Each AlertingRule generates a corresponding PrometheusRule in the openshift-monitoring namespace.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertingrule-generates-prometheusrule.json"},{"id":"ocp-alertingrule-no-recording-rules","text":"The AlertingRule resource only permits alerting rules; recording rules are explicitly prohibited.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertingrule-no-recording-rules.json"},{"id":"ocp-alertingrule-not-prometheusrule","text":"Cluster admins must use the AlertingRule resource (monitoring.openshift.io/v1) to create custom alerts on the platform monitoring stack — not PrometheusRule directly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertingrule-not-prometheusrule.json"},{"id":"ocp-alertmanagerconfig-api-v1beta1","text":"AlertmanagerConfig uses API version monitoring.coreos.com/v1beta1 (beta, not yet stable v1).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertmanagerconfig-api-v1beta1.json"},{"id":"ocp-alertmanagerconfig-namespace-scoped","text":"AlertmanagerConfig is namespace-scoped — it only applies to alerts whose namespace label matches the namespace where the resource is created, enforced by the operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertmanagerconfig-namespace-scoped.json"},{"id":"ocp-alertmanagerconfig-route-first-level","text":"The route defined in AlertmanagerConfig is added as a first-level route in the generated Alertmanager configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertmanagerconfig-route-first-level.json"},{"id":"ocp-alertmanagerconfig-secrets-same-namespace","text":"Secrets referenced by AlertmanagerConfig must be in the same namespace as the AlertmanagerConfig object.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertmanagerconfig-secrets-same-namespace.json"},{"id":"ocp-alertrelabelconfig-actions","text":"AlertRelabelConfig supports actions: Replace (default), Keep, Drop, HashMod, LabelMap, LabelDrop, LabelKeep.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertrelabelconfig-actions.json"},{"id":"ocp-alertrelabelconfig-before-alertmanager","text":"AlertRelabelConfig relabeling is applied after alerting rules fire but before alerts reach Alertmanager.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertrelabelconfig-before-alertmanager.json"},{"id":"ocp-alertrelabelconfig-openshift-specific","text":"AlertRelabelConfig is an OpenShift-specific CRD (monitoring.openshift.io/v1), not an upstream Prometheus/Kubernetes resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertrelabelconfig-openshift-specific.json"},{"id":"ocp-alertrelabelconfig-sequential-evaluation","text":"AlertRelabelConfig spec.configs array is evaluated sequentially — order matters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-alertrelabelconfig-sequential-evaluation.json"},{"id":"ocp-api-driven-all-ops-via-api","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-api-driven-all-ops-via-api.json"},{"id":"ocp-api-groups-examples","text":"OpenShift-specific API resources live in their own API groups, e.g. `apps.openshift.io/v1` and `route.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-api-groups-examples.json"},{"id":"ocp-api-lb-ports","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-api-lb-ports.json"},{"id":"ocp-apiserver-cr-name-cluster","text":"The APIServer custom resource is named `cluster` and is edited with `oc edit APIServer cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-apiserver-cr-name-cluster.json"},{"id":"ocp-apiserver-tls-propagation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-apiserver-tls-propagation.json"},{"id":"ocp-arbitrary-uid-security","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-arbitrary-uid-security.json"},{"id":"ocp-auth-operator-api-group","text":"The Authentication operator resource is at API group `operator.openshift.io/v1`, distinct from the cluster-level auth config at `config.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-auth-operator-api-group.json"},{"id":"ocp-auth-operator-manages-oauth-apiserver","text":"The Authentication operator manages the OAuth API server and authentication-related components in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-auth-operator-manages-oauth-apiserver.json"},{"id":"ocp-authorization-api-governs-rbac","text":"The OpenShift Authorization API is a key API group that governs RBAC and access control, using common shared object structures across API groups.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-authorization-api-governs-rbac.json"},{"id":"ocp-authorization-api-objects","text":"OpenShift Authorization API objects include Role, ClusterRole, RoleBinding, ClusterRoleBinding, SubjectAccessReview, LocalSubjectAccessReview, SelfSubjectAccessReview, and SelfSubjectRulesReview.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-authorization-api-objects.json"},{"id":"ocp-authz-compat-level-1","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-authz-compat-level-1.json"},{"id":"ocp-auto-image-pruner-daily-midnight-cronjob","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-auto-image-pruner-daily-midnight-cronjob.json"},{"id":"ocp-automatic-vs-manual-machine-management","text":"OCP distinguishes between automatic (Machine API-driven) and manual machine management approaches","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-automatic-vs-manual-machine-management.json"},{"id":"ocp-autoscaling-two-levels","text":"OpenShift autoscaling operates at two levels: pod-level (HPA/VPA) and cluster/node-level (ClusterAutoscaler + MachineAutoscaler).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-autoscaling-two-levels.json"},{"id":"ocp-aws-first-class-install-target","text":"OpenShift Container Platform supports AWS as a first-class installation target with dedicated documentation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-aws-first-class-install-target.json"},{"id":"ocp-aws-ipi-nodes-private-subnets","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-aws-ipi-nodes-private-subnets.json"},{"id":"ocp-azure-arm-templates-for-upi","text":"Azure Resource Manager (ARM) templates are the mechanism provided for UPI installations on Azure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-arm-templates-for-upi.json"},{"id":"ocp-azure-default-compute-replicas-3","text":"Default compute (worker) configuration on Azure is 3 replicas with `premium_LRS` disk type and 128 GB OS disk.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-default-compute-replicas-3.json"},{"id":"ocp-azure-government-regions-supported","text":"Microsoft Azure Government (MAG) regions are explicitly supported for OpenShift installations handling US government workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-government-regions-supported.json"},{"id":"ocp-azure-ha-requires-3-azs","text":"Azure regions need at least 3 Availability Zones for proper HA distribution of the control plane.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-ha-requires-3-azs.json"},{"id":"ocp-azure-ipi-default-upi-manual","text":"IPI (installer-provisioned infrastructure) is the default installation method for Azure; UPI requires the administrator to manage infrastructure manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-ipi-default-upi-manual.json"},{"id":"ocp-azure-only-ipv4-supported","text":"Only IPv4 is supported for OpenShift installations on Azure.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-only-ipv4-supported.json"},{"id":"ocp-azure-resource-group-must-be-empty","text":"When using an existing Azure resource group (`platform.azure.resourceGroupName`), the group must be empty and used exclusively for the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-resource-group-must-be-empty.json"},{"id":"ocp-azure-stack-hub-supported","text":"OpenShift Container Platform supports Azure Stack Hub (on-premises Azure) as a separate installation platform from public Azure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-stack-hub-supported.json"},{"id":"ocp-azure-supported-install-target","text":"Microsoft Azure is a supported installation target for OpenShift Container Platform, with both IPI and UPI installation methods available","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-supported-install-target.json"},{"id":"ocp-azure-upi-network-topology","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-upi-network-topology.json"},{"id":"ocp-azure-upi-requires-44-vcpus","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-azure-upi-requires-44-vcpus.json"},{"id":"ocp-backup-centers-on-etcd-snapshots","text":"OpenShift cluster backup strategy centers on etcd snapshots for preserving cluster state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-backup-centers-on-etcd-snapshots.json"},{"id":"ocp-bare-metal-install-supported","text":"OpenShift Container Platform supports bare metal (direct physical server) installation as a first-class target.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-bare-metal-install-supported.json"},{"id":"ocp-bootstrap-process-temporary","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-bootstrap-process-temporary.json"},{"id":"ocp-build-types-s2i-docker-custom","text":"OpenShift's built-in build system supports Source-to-Image (S2I), Docker, and Custom build strategies.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-build-types-s2i-docker-custom.json"},{"id":"ocp-buildconfigs-not-in-upstream-k8s","text":"Builds and BuildConfigs are OpenShift-native resources not present in upstream Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-buildconfigs-not-in-upstream-k8s.json"},{"id":"ocp-built-on-kubernetes","text":"OpenShift Container Platform is built on Kubernetes and its API is 100% Kubernetes-compatible — applications run identically on both with no changes required.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-built-on-kubernetes.json"},{"id":"ocp-builtin-oauth-server","text":"OpenShift includes a built-in OAuth server, which is a key differentiator from vanilla Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-builtin-oauth-server.json"},{"id":"ocp-canary-updates-custom-machineconfigpools","text":"Canary rollout updates use custom MachineConfigPools with a pause/unpause workflow to update worker nodes in stages","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-canary-updates-custom-machineconfigpools.json"},{"id":"ocp-capabilities-cannot-be-disabled-once-enabled","text":"Once a cluster capability is enabled in OpenShift Container Platform, it cannot be disabled — enabling is a one-way operation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-capabilities-cannot-be-disabled-once-enabled.json"},{"id":"ocp-capability-dependency-baremetal-requires-machineapi","text":"The `baremetal` capability depends on `MachineAPI`; it cannot be enabled without `MachineAPI` also being enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-capability-dependency-baremetal-requires-machineapi.json"},{"id":"ocp-capability-dependency-marketplace-requires-olm","text":"The `marketplace` capability depends on `OperatorLifecycleManager`; it cannot be enabled without OLM also being enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-capability-dependency-marketplace-requires-olm.json"},{"id":"ocp-cco-credential-modes","text":"The Cloud Credential Operator supports Mint, Passthrough, Manual, or empty string credential modes (not all modes supported on all providers).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cco-credential-modes.json"},{"id":"ocp-ccoctl-azure-delete-oidc-cleanup","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ccoctl-azure-delete-oidc-cleanup.json"},{"id":"ocp-cicd-multiple-solutions","text":"OpenShift Container Platform provides multiple CI/CD solutions: OpenShift Pipelines (Tekton), OpenShift GitOps (Argo CD), Builds/BuildConfigs, and Jenkins (legacy).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cicd-multiple-solutions.json"},{"id":"ocp-cluster-dns-format","text":"OpenShift cluster FQDN follows the format `<metadata.name>.<baseDomain>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-dns-format.json"},{"id":"ocp-cluster-monitoring-default-user-workload-explicit","text":"Cluster monitoring is enabled by default in OpenShift, while user workload monitoring must be explicitly enabled.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-monitoring-default-user-workload-explicit.json"},{"id":"ocp-cluster-monitoring-operator-manages-stack","text":"The Cluster Monitoring Operator (CMO) deploys and manages the monitoring stack, which includes Prometheus, Alertmanager, Thanos Querier, and Telemeter Client.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-monitoring-operator-manages-stack.json"},{"id":"ocp-cluster-observability-operator-separate","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-observability-operator-separate.json"},{"id":"ocp-cluster-resource-quota-no-even-distribution","text":"ClusterResourceQuota does not guarantee even distribution across projects — one project could consume the entire cluster quota budget.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-resource-quota-no-even-distribution.json"},{"id":"ocp-cluster-resource-quota-selector-types","text":"ClusterResourceQuota can select projects by annotation (`openshift.io/requester`) or by label, but cannot use both simultaneously.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-resource-quota-selector-types.json"},{"id":"ocp-cluster-update-methods","text":"OpenShift cluster updates can be performed via the web console, CLI, or OpenShift Update Service (for disconnected environments).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-update-methods.json"},{"id":"ocp-cluster-updates-non-disruptive","text":"OCP cluster updates are non-disruptive — the cluster remains online during the update process (in-place, zero-downtime upgrade model)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-updates-non-disruptive.json"},{"id":"ocp-cluster-wide-proxy-affects-all-components","text":"Cluster-wide proxy settings in OpenShift affect how all cluster components reach external resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cluster-wide-proxy-affects-all-components.json"},{"id":"ocp-cno-deploys-cni-plugin","text":"The Cluster Network Operator (CNO) is responsible for deploying and managing the CNI plugin selected at install time.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cno-deploys-cni-plugin.json"},{"id":"ocp-compatibility-level-1-stability","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-compatibility-level-1-stability.json"},{"id":"ocp-config-apis-cluster-scoped","text":"Config API objects in OpenShift are cluster-scoped resources that define platform-wide behavior (networking, authentication, scheduling, etc.)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-config-apis-cluster-scoped.json"},{"id":"ocp-console-branding-resource","text":"The resource to edit for console branding (logo, product name) is `consoles.operator.openshift.io cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-console-branding-resource.json"},{"id":"ocp-console-cli-api-clients","text":"Both the OpenShift web console and the `oc` CLI are clients of the API; the API is the authoritative interface.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-console-cli-api-clients.json"},{"id":"ocp-console-config-resource-edit-command","text":"The web console is configured by editing the cluster-scoped resource with `oc edit console.config.openshift.io cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-console-config-resource-edit-command.json"},{"id":"ocp-console-crds-list","text":"Console customization CRDs include: `ConsoleLink`, `ConsoleNotification`, `ConsoleExternalLogLink`, `ConsoleCLIDownload`, `ConsoleYAMLSample`, and `ConsoleQuickStart`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-console-crds-list.json"},{"id":"ocp-console-logout-redirect-enables-slo","text":"Setting `spec.authentication.logoutRedirect` on `console.config.openshift.io` controls the post-logout URL and enables single logout (SLO) through the identity provider.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-console-logout-redirect-enables-slo.json"},{"id":"ocp-consolelink-location-values","text":"ConsoleLink CRD `location` valid values are: `HelpMenu`, `UserMenu`, `ApplicationMenu`, `NamespaceDashboard`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-consolelink-location-values.json"},{"id":"ocp-consolenotification-location-values","text":"ConsoleNotification CRD `location` valid values are: `BannerTop`, `BannerBottom`, `BannerTopBottom`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-consolenotification-location-values.json"},{"id":"ocp-container-engine-crio","text":"CRI-O is the container engine in OpenShift Container Platform (not Docker); it runs as a systemd service on each node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-container-engine-crio.json"},{"id":"ocp-container-runtime-crio","text":"OCP uses CRI-O as the container runtime, not Docker","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-container-runtime-crio.json"},{"id":"ocp-control-plane-minimum-resources","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-minimum-resources.json"},{"id":"ocp-control-plane-must-run-rhcos","text":"Control plane nodes must run RHCOS; compute nodes can run RHCOS or RHEL 8.6+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-must-run-rhcos.json"},{"id":"ocp-control-plane-no-tls13","text":"The OpenShift control plane does not support TLS 1.3 or the Modern TLS security profile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-no-tls13.json"},{"id":"ocp-control-plane-only-update-even-minor-versions","text":"Control Plane Only updates (formerly \"EUS-to-EUS\") in OpenShift are only viable between even-numbered minor versions (e.g., 4.14 → 4.16).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-only-update-even-minor-versions.json"},{"id":"ocp-control-plane-pool-name-master","text":"The control plane machine pool name must be \"master\" and the compute pool name must be \"worker\" in install-config.yaml.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-pool-name-master.json"},{"id":"ocp-control-plane-requires-rhcos","text":"All control plane nodes must run RHCOS; compute nodes can optionally run RHEL but only with UPI installations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-control-plane-requires-rhcos.json"},{"id":"ocp-credentialsrequest-default-token-path","text":"The default `cloudTokenPath` for CredentialsRequest is `/var/run/secrets/openshift/serviceaccount/token`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-credentialsrequest-default-token-path.json"},{"id":"ocp-credentialsrequest-namespaced","text":"CredentialsRequest (`cloudcredential.openshift.io/v1`) is a namespaced resource managed by the Cloud Credential Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-credentialsrequest-namespaced.json"},{"id":"ocp-credentialsrequest-secretref-required","text":"Every CredentialsRequest must specify `spec.secretRef` to define where generated cloud credentials will be stored as a Secret.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-credentialsrequest-secretref-required.json"},{"id":"ocp-crio-provides-fips-awareness","text":"CRI-O is the container runtime that ensures containers are aware they run on a FIPS-enabled host.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-crio-provides-fips-awareness.json"},{"id":"ocp-crio-runtime-rhcos-containerd-windows","text":"OpenShift uses CRI-O as the container runtime on RHCOS nodes and containerd on Windows nodes (via WMCO).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-crio-runtime-rhcos-containerd-windows.json"},{"id":"ocp-current-version-421","text":"OpenShift Container Platform documentation covers version 4.21, with versions ranging from 3.0 through 4.21.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-current-version-421.json"},{"id":"ocp-custom-console-route-via-ingress-config","text":"Custom console routes are configured via `ingress.config.openshift.io cluster` using `spec.componentRoutes`, not via the console operator (deprecated method).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-custom-console-route-via-ingress-config.json"},{"id":"ocp-custom-error-template-redirect-idps-only","text":"Custom login error templates only work with redirect-based identity providers (request header, OIDC), not direct auth providers (LDAP, htpasswd).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-custom-error-template-redirect-idps-only.json"},{"id":"ocp-custom-logo-configmap-openshift-config","text":"Custom console logos are stored in a ConfigMap in the `openshift-config` namespace, with max-height 60px and max size 1 MB.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-custom-logo-configmap-openshift-config.json"},{"id":"ocp-custom-metrics-autoscaler-based-on-keda","text":"The Custom Metrics Autoscaler Operator in OCP is based on KEDA.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-custom-metrics-autoscaler-based-on-keda.json"},{"id":"ocp-custom-project-template-in-openshift-config","text":"Custom project templates must be created in the `openshift-config` namespace and referenced via `project.config.openshift.io/cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-custom-project-template-in-openshift-config.json"},{"id":"ocp-cvo-checks-osus-for-updates","text":"The Cluster Version Operator (CVO) checks the OpenShift Update Service (OSUS) for valid updates and uses release images to perform upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cvo-checks-osus-for-updates.json"},{"id":"ocp-cvo-overrides-block-upgrades","text":"CVO spec.overrides with unmanaged: true blocks cluster upgrades and renders the cluster unsupported","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-cvo-overrides-block-upgrades.json"},{"id":"ocp-day2-ops-postinstall-config","text":"Day 2 operations in OpenShift correspond to postinstallation configuration","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-day2-ops-postinstall-config.json"},{"id":"ocp-day2-postinstallation-operations","text":"Postinstallation configuration in OpenShift is referred to as \"Day 2 operations,\" distinct from Day 0 (planning) and Day 1 (installation) activities.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-day2-postinstallation-operations.json"},{"id":"ocp-day2-tasks-include-idp-storage-networking-scaling","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-day2-tasks-include-idp-storage-networking-scaling.json"},{"id":"ocp-default-baseline-capability-set-vcurrent","text":"The default `baselineCapabilitySet` value is `vCurrent`, which enables all optional capabilities including any new ones added in future releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-baseline-capability-set-vcurrent.json"},{"id":"ocp-default-cluster-network-cidr","text":"Default OpenShift cluster network CIDR is 10.128.0.0/14 with /23 host prefix, providing 510 pod IPs per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-cluster-network-cidr.json"},{"id":"ocp-default-cluster-roles","text":"Key default cluster roles in OpenShift are: `cluster-admin`, `admin`, `edit`, `view`, and `self-provisioner`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-cluster-roles.json"},{"id":"ocp-default-cni-shifted-to-ovn-kubernetes","text":"OpenShift 4.x default CNI plugin shifted from OpenShift SDN to OVN-Kubernetes in later 4.x releases.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-cni-shifted-to-ovn-kubernetes.json"},{"id":"ocp-default-compute-replicas-3","text":"Default compute (worker) replicas in OpenShift is 3; control plane replicas must be 3 (or 1 for single-node OpenShift).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-compute-replicas-3.json"},{"id":"ocp-default-host-prefix-23","text":"The default host prefix is `/23`, giving 510 usable pod IPs per node","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-host-prefix-23.json"},{"id":"ocp-default-ingress-controller-haproxy","text":"The default Ingress Controller in OpenShift Container Platform uses HAProxy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-ingress-controller-haproxy.json"},{"id":"ocp-default-machine-cidr","text":"The default Machine CIDR in OpenShift is `10.0.0.0/16` and cannot be changed after cluster installation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-machine-cidr.json"},{"id":"ocp-default-network-cidrs","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-network-cidrs.json"},{"id":"ocp-default-network-plugin-ovnkubernetes","text":"OVNKubernetes is the default (and only listed) CNI network plugin for OpenShift 4.17, supporting Linux and hybrid Linux/Windows nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-network-plugin-ovnkubernetes.json"},{"id":"ocp-default-pod-cidr","text":"The default Pod CIDR (clusterNetwork CIDR) in OpenShift is `10.128.0.0/14` and can be expanded post-installation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-pod-cidr.json"},{"id":"ocp-default-replica-counts","text":"Default compute node replicas: 3 (minimum 2); control plane replicas: 3 (or 1 for single-node OpenShift).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-replica-counts.json"},{"id":"ocp-default-runtime-runc","text":"The default container runtime in OCP 4.17 is runC; crun is the alternative (C-based, by Red Hat).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-runtime-runc.json"},{"id":"ocp-default-service-cidr","text":"The default Service CIDR in OpenShift is `172.30.0.0/16`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-service-cidr.json"},{"id":"ocp-default-service-network-cidr","text":"Default OpenShift service network CIDR is 172.30.0.0/16.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-default-service-network-cidr.json"},{"id":"ocp-delete-app-removes-all-components","text":"Deleting an application in OpenShift's Developer perspective Topology view removes the application and all associated components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-delete-app-removes-all-components.json"},{"id":"ocp-delete-app-requires-name-confirmation","text":"Deleting an application in the OpenShift web console requires typing the application name to confirm deletion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-delete-app-requires-name-confirmation.json"},{"id":"ocp-delete-imagestreamtag-removes-spec-and-status","text":"Deleting an ImageStreamTag removes both the spec and status entries for that tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-delete-imagestreamtag-removes-spec-and-status.json"},{"id":"ocp-deployment-and-deploymentconfig-types","text":"`Deployment` and `DeploymentConfig` are the two object types for deploying applications in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-deployment-and-deploymentconfig-types.json"},{"id":"ocp-destroy-cluster-command","text":"The primary command for removing an IPI cluster from AWS is `openshift-install destroy cluster --dir <installation_directory> --log-level info`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-destroy-cluster-command.json"},{"id":"ocp-destroy-cluster-requires-metadata-json","text":"The `openshift-install destroy cluster` command requires the original installation directory containing `metadata.json` — without it, the cluster cannot be programmatically removed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-destroy-cluster-requires-metadata-json.json"},{"id":"ocp-destroy-requires-metadata-json","text":"The `openshift-install destroy cluster` command requires the `metadata.json` file in the installation directory to identify and delete cluster resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-destroy-requires-metadata-json.json"},{"id":"ocp-disable-console-management-state-removed","text":"To disable the web console, set `spec.managementState: Removed` on `consoles.operator.openshift.io cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-disable-console-management-state-removed.json"},{"id":"ocp-disable-self-provisioning-two-steps","text":"To disable self-provisioning: remove subjects from the `self-provisioners` binding AND set annotation `rbac.authorization.kubernetes.io/autoupdate: \"false\"` to prevent automatic reset.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-disable-self-provisioning-two-steps.json"},{"id":"ocp-disabling-nodetuning-limits-scalability","text":"Disabling the `NodeTuning` capability can limit cluster scalability beyond 900 nodes or 900 routes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-disabling-nodetuning-limits-scalability.json"},{"id":"ocp-disconnected-install-requires-image-mirroring","text":"Disconnected/restricted network OpenShift installations require mirroring installation images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-disconnected-install-requires-image-mirroring.json"},{"id":"ocp-distributed-tracing-store-analyze-visualize","text":"Distributed tracing in OpenShift Container Platform is used to store, analyze, and visualize microservices transactions in distributed systems.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-distributed-tracing-store-analyze-visualize.json"},{"id":"ocp-distributed-tracing-uses-tempo","text":"OpenShift distributed tracing uses the Tempo architecture as the backend for storing and visualizing requests across microservices.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-distributed-tracing-uses-tempo.json"},{"id":"ocp-dns-naming-convention","text":"The cluster's full DNS name follows the pattern `<metadata.name>.<baseDomain>`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-dns-naming-convention.json"},{"id":"ocp-dns-operator-deploys-coredns","text":"The DNS Operator deploys and manages CoreDNS for pod name resolution in OpenShift (not kube-dns).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-dns-operator-deploys-coredns.json"},{"id":"ocp-dns-preferred-over-env-vars","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-dns-preferred-over-env-vars.json"},{"id":"ocp-dual-stack-same-nic-consistent-order","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-dual-stack-same-nic-consistent-order.json"},{"id":"ocp-enable-capability-post-install-patch","text":"Capabilities can be enabled post-install using `oc patch clusterversion/version --type merge -p '{\"spec\":{\"capabilities\":{\"additionalEnabledCapabilities\":[\"<capability>\"]}}}'`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-enable-capability-post-install-patch.json"},{"id":"ocp-etcd-fsync-requirement","text":"etcd requires 10 ms p99 fsync duration; faster storage is strongly recommended for control plane nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-etcd-fsync-requirement.json"},{"id":"ocp-etcd-network-encryption-options","text":"OCP supports etcd encryption for data at rest and network encryption via IPsec or WireGuard with OVN-Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-etcd-network-encryption-options.json"},{"id":"ocp-etcd-standalone-config-topic","text":"etcd is broken out as its own configuration topic in OpenShift, reflecting its criticality to cluster state (backup, restore, encryption)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-etcd-standalone-config-topic.json"},{"id":"ocp-eus-available-even-numbered-minor-releases","text":"Extended Update Support (EUS) is available on all even-numbered minor OpenShift releases (e.g., 4.14, 4.16).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-eus-available-even-numbered-minor-releases.json"},{"id":"ocp-eus-stable-channel-45-90-days-after-ga","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-eus-stable-channel-45-90-days-after-ga.json"},{"id":"ocp-every-pod-gets-unique-ip-no-nat","text":"Every pod in OpenShift receives a unique IP address from the cluster network CIDR with no NAT between pods","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-every-pod-gets-unique-ip-no-nat.json"},{"id":"ocp-extended-resources-no-overcommit","text":"Extended resources (e.g., GPUs) only support the `requests.` prefix in quotas — overcommitment is not allowed.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-extended-resources-no-overcommit.json"},{"id":"ocp-extends-k8s-api-with-crds","text":"OpenShift extends the Kubernetes API with custom resource definitions (CRDs) for platform-specific functionality.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-extends-k8s-api-with-crds.json"},{"id":"ocp-extends-kubernetes-api","text":"OpenShift Container Platform extends the upstream Kubernetes API with additional resource types including Routes, BuildConfigs, DeploymentConfigs, and ImageStreams.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-extends-kubernetes-api.json"},{"id":"ocp-extends-kubernetes-api-with-crds","text":"OpenShift-specific APIs (e.g., Route, BuildConfig, DeploymentConfig, ClusterVersion, MachineSet) are implemented as Custom Resource Definitions (CRDs) on top of Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-extends-kubernetes-api-with-crds.json"},{"id":"ocp-fips-azure-file-incompatible","text":"Azure File storage is incompatible with OpenShift FIPS mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-azure-file-incompatible.json"},{"id":"ocp-fips-etcd-encryption-aes-cbc","text":"In FIPS mode, etcd data-at-rest encryption uses the AES CBC algorithm and is applied after cluster installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-etcd-encryption-aes-cbc.json"},{"id":"ocp-fips-incompatible-azure-file-storage","text":"FIPS mode and Azure File storage are incompatible — Azure File storage cannot be used when FIPS is enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-incompatible-azure-file-storage.json"},{"id":"ocp-fips-install-config-setting","text":"FIPS mode is enabled by setting `fips: true` in `install-config.yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-install-config-setting.json"},{"id":"ocp-fips-installer-binary-name","text":"The FIPS-capable OpenShift installer binary is named `openshift-install-fips`, distinct from the standard `openshift-install`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-installer-binary-name.json"},{"id":"ocp-fips-mode-install-time-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-mode-install-time-only.json"},{"id":"ocp-fips-mode-install-time-option","text":"FIPS mode in OpenShift is an installation-time option (cannot be enabled post-install).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-mode-install-time-option.json"},{"id":"ocp-fips-must-be-enabled-at-install-time","text":"FIPS mode must be enabled at OpenShift cluster install time — it cannot be enabled after deployment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-must-be-enabled-at-install-time.json"},{"id":"ocp-fips-not-supported-aarch64","text":"OpenShift Container Platform FIPS support is available on x86_64, ppc64le, and s390x architectures only — aarch64 is NOT supported for FIPS.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-not-supported-aarch64.json"},{"id":"ocp-fips-requires-fips-enabled-rhel","text":"FIPS mode requires running the OpenShift installer from a FIPS-enabled RHEL machine.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-requires-fips-enabled-rhel.json"},{"id":"ocp-fips-requires-rhel9-host-in-fips-mode","text":"The FIPS-capable OpenShift installer must be run from a RHEL 9 machine that is already running in FIPS mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-requires-rhel9-host-in-fips-mode.json"},{"id":"ocp-fips-requires-rsa-or-ecdsa-not-ed25519","text":"For FIPS mode, SSH keys must use RSA or ECDSA algorithms — ed25519 is not supported.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-requires-rsa-or-ecdsa-not-ed25519.json"},{"id":"ocp-fips-ssh-key-types","text":"When FIPS mode is enabled, SSH keys must use RSA or ECDSA (ed25519 is not allowed)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-ssh-key-types.json"},{"id":"ocp-fips-supported-architectures","text":"FIPS mode in OpenShift is supported only on x86_64, ppc64le, and s390x architectures (not aarch64).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-fips-supported-architectures.json"},{"id":"ocp-firmware-updates-not-part-of-ocp-updates","text":"Firmware updates are NOT part of the OpenShift Container Platform update process — they are the customer's responsibility.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-firmware-updates-not-part-of-ocp-updates.json"},{"id":"ocp-five-primary-cli-tools","text":"OCP provides five primary CLI tools: `oc` (OpenShift CLI), `kn` (Knative CLI), `tkn` (Pipelines CLI), `opm` (Operator catalog CLI), and Operator SDK (`operator-sdk`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-five-primary-cli-tools.json"},{"id":"ocp-four-accelerator-types","text":"OpenShift Container Platform supports four types of hardware accelerators: GPUs, NPUs (Neural Processing Units), ASICs (Application-Specific Integrated Circuits), and DPUs (Data Processing Units).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-four-accelerator-types.json"},{"id":"ocp-four-cicd-solutions","text":"OpenShift Container Platform provides four CI/CD solutions: OpenShift Builds, OpenShift Pipelines, OpenShift GitOps, and Jenkins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-four-cicd-solutions.json"},{"id":"ocp-four-installation-methods","text":"OpenShift Container Platform 4.17 provides four installation methods: Assisted Installer, Agent-based Installer, installer-provisioned infrastructure (IPI), and user-provisioned infrastructure (UPI)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-four-installation-methods.json"},{"id":"ocp-gcp-supported-install-target","text":"OpenShift Container Platform supports installation on Google Cloud Platform (GCP) as a first-class cloud provider.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-gcp-supported-install-target.json"},{"id":"ocp-gitops-based-on-argocd","text":"OpenShift GitOps is based on Argo CD and provides declarative CD for managing cluster and application state via Git.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-gitops-based-on-argocd.json"},{"id":"ocp-groups-cluster-scoped","text":"Groups in OpenShift are cluster-scoped and can be referenced in both ClusterRoleBindings and namespace-scoped RoleBindings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-groups-cluster-scoped.json"},{"id":"ocp-highly-privileged-projects-list","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-highly-privileged-projects-list.json"},{"id":"ocp-host-network-spec","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-host-network-spec.json"},{"id":"ocp-hosted-control-planes-different-cidrs","text":"Hosted control planes use different default CIDRs than standard clusters: pod `10.132.0.0/14`, service `172.31.0.0/16`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-hosted-control-planes-different-cidrs.json"},{"id":"ocp-hosted-control-planes-platforms","text":"Hosted control planes (HCP) can be deployed on OpenShift Virtualization, AWS, bare metal, IBM Z, and IBM Power, including in disconnected environments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-hosted-control-planes-platforms.json"},{"id":"ocp-hosted-control-planes-supported","text":"Hosted control planes (HyperShift) is a supported cluster management model where control planes run as pods on a management cluster","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-hosted-control-planes-supported.json"},{"id":"ocp-identity-provider-types","text":"OpenShift supports these identity providers: HTPasswd, LDAP, GitHub, GitLab, Google, OpenID Connect, Keystone, Basic Authentication, and Request Header.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-identity-provider-types.json"},{"id":"ocp-image-apis-group-v1","text":"All OpenShift Image APIs are in the `image.openshift.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-image-apis-group-v1.json"},{"id":"ocp-image-namespace-flag-only-imagestreams","text":"The `--namespace` flag on `oc adm prune images` only removes image streams, not images, because images are cluster-scoped resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-image-namespace-flag-only-imagestreams.json"},{"id":"ocp-image-pruning-requires-image-pruner-role","text":"Image pruning requires the `system:image-pruner` cluster role or `cluster-admin` privileges.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-image-pruning-requires-image-pruner-role.json"},{"id":"ocp-image-pruning-requires-registry-restart","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-image-pruning-requires-registry-restart.json"},{"id":"ocp-image-registry-cannot-be-mirror-target","text":"The OpenShift image registry cannot be used as a mirror target because it does not support pushing without a tag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-image-registry-cannot-be-mirror-target.json"},{"id":"ocp-imagestreamimage-name-format","text":"ImageStreamImage resources are accessed using the name format `<STREAM>@<DIGEST>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-imagestreamimage-name-format.json"},{"id":"ocp-imagestreamimport-preview-before-tagging","text":"ImageStreamImport allows users to find, preview metadata, and import images from external registries before actually tagging them in an ImageStream.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-imagestreamimport-preview-before-tagging.json"},{"id":"ocp-imagestreammapping-privileged-only","text":"ImageStreamMapping is for privileged integrators only; creating a mapping exposes the image to anyone who can view the stream.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-imagestreammapping-privileged-only.json"},{"id":"ocp-includes-builtin-container-registry","text":"OpenShift Container Platform includes a built-in private container registry installed with the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-includes-builtin-container-registry.json"},{"id":"ocp-ingress-capability-must-be-enabled","text":"The Ingress capability must always be enabled — OpenShift cluster installation fails without it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-capability-must-be-enabled.json"},{"id":"ocp-ingress-controller-runs-as-pod","text":"The Ingress Controller runs as a scalable pod inside the cluster, not as a separate infrastructure component.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-controller-runs-as-pod.json"},{"id":"ocp-ingress-controller-uses-haproxy","text":"OpenShift uses HAProxy as the underlying technology for Ingress Controllers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-controller-uses-haproxy.json"},{"id":"ocp-ingress-converts-tls10-to-tls11","text":"The Ingress Controller converts TLS 1.0 to TLS 1.1 when using Old or Custom TLS profiles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-converts-tls10-to-tls11.json"},{"id":"ocp-ingress-inherits-apiserver-tls","text":"The Ingress Controller's TLS profile defaults to the API server's TLS profile setting if not explicitly configured.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-inherits-apiserver-tls.json"},{"id":"ocp-ingress-metrics-top10-filters","text":"Ingress dashboard metrics can be filtered by Top 10 Per Route, Top 10 Per Namespace, and Top 10 Per Shard.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-metrics-top10-filters.json"},{"id":"ocp-ingress-operator-namespace","text":"The Ingress Controller is managed in the `openshift-ingress-operator` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-operator-namespace.json"},{"id":"ocp-ingress-translates-to-routes","text":"Kubernetes Ingress resources are automatically translated into Route objects by OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ingress-translates-to-routes.json"},{"id":"ocp-inhibit-rules-source-target-matching","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-inhibit-rules-source-target-matching.json"},{"id":"ocp-install-config-declarative","text":"OCP installation configuration is declarative, defined in `install-config.yaml` before the installer runs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-config-declarative.json"},{"id":"ocp-install-config-immutable-after-install","text":"The install-config.yaml parameters are immutable after OpenShift cluster installation — networking, capabilities, FIPS, and workload partitioning cannot be changed post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-config-immutable-after-install.json"},{"id":"ocp-install-docs-organized-per-platform","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-docs-organized-per-platform.json"},{"id":"ocp-install-existing-vpc-vnet-supported","text":"OpenShift supports installation into existing VPC (AWS, GCP) or existing VNet (Azure).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-existing-vpc-vnet-supported.json"},{"id":"ocp-install-methods-ipi-and-upi","text":"OpenShift Container Platform offers two primary installation approaches: Installer-Provisioned Infrastructure (IPI) and User-Provisioned Infrastructure (UPI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-methods-ipi-and-upi.json"},{"id":"ocp-install-time-vs-day2-config","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-install-time-vs-day2-config.json"},{"id":"ocp-installation-12-stages","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-installation-12-stages.json"},{"id":"ocp-installation-validation-troubleshooting-phase","text":"OCP has a dedicated validation and troubleshooting workflow as a post-installation phase in the cluster lifecycle","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-installation-validation-troubleshooting-phase.json"},{"id":"ocp-integrated-registry-managed-by-operator","text":"OpenShift Container Platform ships with an integrated container image registry managed by the Image Registry Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-integrated-registry-managed-by-operator.json"},{"id":"ocp-integrated-registry-pull-requires-layers-permission","text":"Pulling from the integrated container registry requires `get imagestreams/layers` permission on the image stream.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-integrated-registry-pull-requires-layers-permission.json"},{"id":"ocp-internal-oauth-server","text":"OpenShift runs an internal OAuth server for authentication; identity providers are configured on this OAuth server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-internal-oauth-server.json"},{"id":"ocp-ip-failover-uses-vrrp","text":"OpenShift IP failover provides high availability for external-facing IP addresses using VRRP (Virtual Router Redundancy Protocol)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ip-failover-uses-vrrp.json"},{"id":"ocp-ipi-default-installation-method","text":"Installer-provisioned infrastructure (IPI) is the default installation method for OpenShift; UPI requires manual creation of infrastructure resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ipi-default-installation-method.json"},{"id":"ocp-jenkins-legacy-cicd","text":"Jenkins is the legacy CI/CD option in OpenShift, being de-emphasized in favor of Tekton-based Pipelines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-jenkins-legacy-cicd.json"},{"id":"ocp-jenkins-legacy-deprecated","text":"Jenkins on OpenShift is a legacy approach; the platform has shifted toward Pipelines (Tekton) and GitOps (Argo CD).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-jenkins-legacy-deprecated.json"},{"id":"ocp-key-cluster-scoped-resources","text":"Key cluster-level API resources in OpenShift include: ClusterVersion, Infrastructure, OAuth, DNS, Network, Ingress, Proxy, Scheduler, FeatureGate, Image, Build, and Project.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-key-cluster-scoped-resources.json"},{"id":"ocp-kubeadmin-default-account","text":"After installation, OpenShift uses a temporary `kubeadmin` admin account; a real identity provider must be configured for production and kubeadmin should then be removed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-kubeadmin-default-account.json"},{"id":"ocp-kubelet-tls-change-triggers-reboot","text":"Changing kubelet TLS settings via KubeletConfig triggers node reboots, applied by the Machine Config Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-kubelet-tls-change-triggers-reboot.json"},{"id":"ocp-kubelet-tls-verify-path","text":"Kubelet TLS settings can be verified by checking `/etc/kubernetes/kubelet.conf` on the node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-kubelet-tls-verify-path.json"},{"id":"ocp-kuryr-deprecated-414-removed-416","text":"Kuryr network plugin was deprecated as of OCP 4.14 and removed in OCP 4.16.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-kuryr-deprecated-414-removed-416.json"},{"id":"ocp-latest-tag-no-auto-update","text":"The OpenShift `latest` tracking tag does not automatically update to the newest version — it must be manually updated, unlike Docker's `latest` behavior.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-latest-tag-no-auto-update.json"},{"id":"ocp-ldap-group-sync","text":"Groups can be synced from external LDAP directories using `oc adm groups sync`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ldap-group-sync.json"},{"id":"ocp-link-local-not-reachable-from-pod-network","text":"The link-local CIDR 169.254.0.0/16 is not reachable from the pod network; pods must use hostNetwork to access it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-link-local-not-reachable-from-pod-network.json"},{"id":"ocp-logging-cluster-admin-responsibility","text":"Deploying and managing the OpenShift logging stack is a cluster administrator responsibility.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-cluster-admin-responsibility.json"},{"id":"ocp-logging-distinct-from-monitoring","text":"OpenShift Logging is a distinct subsystem from OpenShift monitoring (Prometheus/Alertmanager) — they serve different observability purposes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-distinct-from-monitoring.json"},{"id":"ocp-logging-four-functions","text":"OpenShift Logging serves four primary functions: collect, visualize, forward, and store log data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-four-functions.json"},{"id":"ocp-logging-not-installed-by-default","text":"OpenShift Logging is not installed by default — it requires installing the Cluster Logging Operator (and typically a log store operator like Loki Operator).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-not-installed-by-default.json"},{"id":"ocp-logging-separate-documentation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-separate-documentation.json"},{"id":"ocp-logging-separate-release-cadence","text":"OpenShift Logging releases on a separate cadence from OpenShift Container Platform itself and is versioned independently.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-separate-release-cadence.json"},{"id":"ocp-logging-three-log-types","text":"OpenShift Logging collects three distinct log types: node system audit logs, application container logs, and infrastructure logs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-logging-three-log-types.json"},{"id":"ocp-login-templates-stored-in-secrets","text":"Custom login page templates (login, provider selection, error) are stored in Secrets in the `openshift-config` namespace, not ConfigMaps.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-login-templates-stored-in-secrets.json"},{"id":"ocp-lokistack-alerts-require-logging-5-7","text":"LokiStack-based customized alerts and recorded metrics require Logging version 5.7 or later.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-lokistack-alerts-require-logging-5-7.json"},{"id":"ocp-machine-sets-compute-and-control-plane","text":"Machine sets are used to manage both compute and control plane machines in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-machine-sets-compute-and-control-plane.json"},{"id":"ocp-machineapi-only-disableable-with-upi","text":"The `MachineAPI` capability can only be disabled when using user-provisioned infrastructure (UPI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-machineapi-only-disableable-with-upi.json"},{"id":"ocp-managed-image-annotation-required","text":"An image must have the `openshift.io/image.managed` annotation to be eligible for pruning by the image pruner.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-managed-image-annotation-required.json"},{"id":"ocp-management-state-unmanaged-stops-reconciliation","text":"Setting an operator's `managementState` to `Unmanaged` stops the operator from reconciling its managed component.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-management-state-unmanaged-stops-reconciliation.json"},{"id":"ocp-management-state-values-managed-unmanaged-removed","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-management-state-values-managed-unmanaged-removed.json"},{"id":"ocp-mco-maxunavailable-default-1","text":"The Machine Config Operator (MCO) maxUnavailable defaults to 1 during cluster updates, controlling how many nodes are cordoned simultaneously","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-mco-maxunavailable-default-1.json"},{"id":"ocp-mcp-groups-8-10-nodes-staged-rollout","text":"Worker nodes should be divided into MachineConfigPool groups of approximately 8-10 nodes for staged rolling updates in telco CNF environments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-mcp-groups-8-10-nodes-staged-rollout.json"},{"id":"ocp-mcp-pausing-controls-worker-reboot","text":"MachineConfigPool pausing (`spec.paused: true/false`) is the mechanism to control when worker nodes reboot during OpenShift updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-mcp-pausing-controls-worker-reboot.json"},{"id":"ocp-metadata-name-max-14-chars","text":"The metadata.name field in install-config.yaml must be 14 characters or fewer, using only lowercase letters, hyphens, and periods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-metadata-name-max-14-chars.json"},{"id":"ocp-metallb-loadbalancer-bare-metal","text":"The MetalLB Operator provides external IP addresses for LoadBalancer-type services on bare metal clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-metallb-loadbalancer-bare-metal.json"},{"id":"ocp-min-node-topologies","text":"OpenShift supports minimum node topologies: SNO (1 node), TNO (2 nodes), and standard HA (3 control plane + workers).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-min-node-topologies.json"},{"id":"ocp-monitoring-api-objects-include-servicemonitor-prometheusrule","text":"OpenShift monitoring API objects include `AlertingRule`, `AlertRelabelConfig`, `PrometheusRule`, `ServiceMonitor`, and `PodMonitor` custom resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-api-objects-include-servicemonitor-prometheusrule.json"},{"id":"ocp-monitoring-apis-separate-api-group","text":"OpenShift Container Platform exposes dedicated Monitoring API objects as Custom Resource Definitions, separate from core Kubernetes APIs and operator APIs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-apis-separate-api-group.json"},{"id":"ocp-monitoring-apis-separate-from-k8s","text":"OpenShift Container Platform has dedicated monitoring API objects (PrometheusRule, ServiceMonitor, PodMonitor, AlertmanagerConfig, etc.) beyond what upstream Kubernetes provides","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-apis-separate-from-k8s.json"},{"id":"ocp-monitoring-config-via-configmap","text":"Monitoring configuration is done via ConfigMap objects in the `openshift-monitoring` and `openshift-user-workload-monitoring` namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-config-via-configmap.json"},{"id":"ocp-monitoring-deployed-by-default","text":"Monitoring is the only observability component deployed by default in every OpenShift Container Platform installation; all other observability components must be installed separately.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-deployed-by-default.json"},{"id":"ocp-monitoring-stack-based-on-prometheus","text":"The OpenShift monitoring stack is based on the Prometheus ecosystem (Prometheus, Alertmanager, Thanos).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-based-on-prometheus.json"},{"id":"ocp-monitoring-stack-builtin","text":"The OpenShift Container Platform monitoring stack is built-in and ships pre-configured — it is not an optional add-on.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-builtin.json"},{"id":"ocp-monitoring-stack-components","text":"The OpenShift monitoring stack is based on Prometheus (metrics collection), Alertmanager (alert routing), and Thanos Querier (federated querying).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-components.json"},{"id":"ocp-monitoring-stack-enabled-by-default","text":"The OpenShift monitoring stack is pre-configured and deployed by default on OpenShift clusters — no installation required.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-enabled-by-default.json"},{"id":"ocp-monitoring-stack-preinstalled","text":"OpenShift Container Platform ships with a preconfigured, preinstalled, and self-updating monitoring stack for core platform components","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-preinstalled.json"},{"id":"ocp-monitoring-stack-self-updating","text":"The OCP monitoring stack is self-updating as part of the platform — no manual operator installation is needed for platform monitoring","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-monitoring-stack-self-updating.json"},{"id":"ocp-mtc-migration-tool","text":"Migration Toolkit for Containers (MTC) is the tool for migrating workloads between clusters or from v3 to v4","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-mtc-migration-tool.json"},{"id":"ocp-multus-cni-enables-multiple-network-interfaces","text":"The Multus CNI meta-plugin enables attaching multiple network interfaces to pods in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-multus-cni-enables-multiple-network-interfaces.json"},{"id":"ocp-multus-cni-multiple-interfaces","text":"Multus CNI enables multiple network interfaces on pods, connecting to SR-IOV, Macvlan, and other additional network types","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-multus-cni-multiple-interfaces.json"},{"id":"ocp-namespace-project-equivalence","text":"OpenShift maps Kubernetes Namespaces to Projects — the terms are related but Project adds additional features","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-namespace-project-equivalence.json"},{"id":"ocp-network-apis-managed-by-cno-and-ingress-operator","text":"Network APIs are managed by the Cluster Network Operator and the Ingress Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-network-apis-managed-by-cno-and-ingress-operator.json"},{"id":"ocp-network-observability-operator-not-default","text":"The Network Observability Operator is a separate installation — it is not enabled by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-network-observability-operator-not-default.json"},{"id":"ocp-network-observability-stores-in-loki","text":"The Network Observability Operator stores flow logs in a Loki instance for querying, with optional Kafka as an intermediate message broker.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-network-observability-stores-in-loki.json"},{"id":"ocp-network-observability-uses-ebpf","text":"The Network Observability Operator uses eBPF agents on nodes to capture network flow data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-network-observability-uses-ebpf.json"},{"id":"ocp-network-policies-namespace-scoped","text":"Network policies in OpenShift are namespace-scoped and use label selectors to define allowed traffic","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-network-policies-namespace-scoped.json"},{"id":"ocp-networking-dashboards-path","text":"OpenShift networking dashboards are accessed via Observe → Dashboards in the web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-dashboards-path.json"},{"id":"ocp-networking-managed-by-operators","text":"OpenShift manages networking components through Operators (e.g., Cluster Network Operator, DNS Operator, Ingress Operator) rather than static configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-managed-by-operators.json"},{"id":"ocp-networking-multiple-specialized-operators","text":"OpenShift Container Platform networking is managed through multiple specialized Operators (Ingress, DNS, CNO, MetalLB, SR-IOV, PTP, NMState), not a single monolithic component.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-multiple-specialized-operators.json"},{"id":"ocp-networking-operators-cno-default","text":"The Cluster Network Operator (CNO) is installed by default in OpenShift and manages the pod network (SDN/OVN-Kubernetes)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-operators-cno-default.json"},{"id":"ocp-networking-operators-dns-default","text":"The DNS Operator is installed by default in OpenShift and runs CoreDNS pods for cluster DNS resolution","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-operators-dns-default.json"},{"id":"ocp-networking-operators-ingress-default","text":"The Ingress Operator is installed by default in OpenShift and manages HAProxy-based IngressControllers for route/ingress traffic","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-networking-operators-ingress-default.json"},{"id":"ocp-node-apis-distinct-category","text":"OpenShift organizes its APIs into distinct categories, with Node APIs being a specific category governing how nodes are defined, configured, and managed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-node-apis-distinct-category.json"},{"id":"ocp-nodes-run-rhcos","text":"OpenShift Container Platform nodes run Red Hat Enterprise Linux CoreOS (RHCOS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-nodes-run-rhcos.json"},{"id":"ocp-nodes-run-rhcos-or-rhel","text":"OpenShift Container Platform nodes run as RHCOS (Red Hat Enterprise Linux CoreOS) or RHEL.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-nodes-run-rhcos-or-rhel.json"},{"id":"ocp-oauth-apiserver-revision-based-deployments","text":"The OAuth API server uses revision-based deployments tracked by `latestAvailableRevision`; new revisions trigger pod redeployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-oauth-apiserver-revision-based-deployments.json"},{"id":"ocp-observability-components-separate-release-cycles","text":"All observability components except Monitoring follow separate release cycles from core OpenShift Container Platform releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-observability-components-separate-release-cycles.json"},{"id":"ocp-observability-stack-components","text":"The OCP observability stack includes Monitoring, Logging, Network Observability, Distributed Tracing, OpenTelemetry, Power Monitoring, and Cluster Observability Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-observability-stack-components.json"},{"id":"ocp-oc-cli-distinct-from-kubectl","text":"OpenShift has its own CLI (`oc`) that is distinct from but compatible with `kubectl`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-oc-cli-distinct-from-kubectl.json"},{"id":"ocp-oc-explain-inspects-api-schemas","text":"The `oc explain <resource>` command is used to inspect API object schemas at runtime, and `oc api-resources` lists available API resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-oc-explain-inspects-api-schemas.json"},{"id":"ocp-oc-expose-creates-route","text":"`oc expose svc/<service-name>` is the quickest way to create a non-TLS route from an existing service.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-oc-expose-creates-route.json"},{"id":"ocp-odd-releases-18-month-support","text":"Odd-numbered OpenShift Container Platform releases (e.g., 4.17) receive 18-month support; even-numbered releases are Extended Update Support (EUS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-odd-releases-18-month-support.json"},{"id":"ocp-olm-v1-current","text":"OLM v1 (Operator Lifecycle Manager) is the current extension mechanism in OCP 4.21","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-olm-v1-current.json"},{"id":"ocp-onprem-installers-assisted-and-agent","text":"Two on-premise installation methods exist: Assisted Installer and Agent-based Installer","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-onprem-installers-assisted-and-agent.json"},{"id":"ocp-open-service-broker-api-provisioning","text":"OpenShift Container Platform references the Open Service Broker API as a mechanism for provisioning and managing service instances.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-open-service-broker-api-provisioning.json"},{"id":"ocp-operator-loglevel-values","text":"Operator logLevel valid values are `Normal` (default), `Debug`, `Trace`, and `TraceAll`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-operator-loglevel-values.json"},{"id":"ocp-operators-primary-extension-mechanism","text":"Operators are the primary extension mechanism for OCP; most additional components (networking, security, observability, CI/CD, etc.) are delivered as Operators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-operators-primary-extension-mechanism.json"},{"id":"ocp-optional-networking-operators-via-operatorhub","text":"MetalLB, External DNS, and Ingress Node Firewall operators are optional and installed via OperatorHub","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-optional-networking-operators-via-operatorhub.json"},{"id":"ocp-ovn-kubernetes-default-network-plugin","text":"OVN-Kubernetes is the default/primary network plugin for OpenShift Container Platform","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ovn-kubernetes-default-network-plugin.json"},{"id":"ocp-perspective-ids-admin-dev","text":"The two default web console perspective IDs are `admin` and `dev`, with visibility states `Enabled`, `Disabled`, or `AccessReview`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-perspective-ids-admin-dev.json"},{"id":"ocp-pipelines-based-on-tekton","text":"OpenShift Pipelines is based on Tekton, a cloud-native Kubernetes-native CI/CD pipeline framework.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-pipelines-based-on-tekton.json"},{"id":"ocp-pipelines-based-on-tekton-kubernetes-resources","text":"Red Hat OpenShift Pipelines is a cloud-native CI/CD solution based on Kubernetes resources (Tekton).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-pipelines-based-on-tekton-kubernetes-resources.json"},{"id":"ocp-pipelines-gitops-installed-as-operators","text":"Both OpenShift Pipelines and OpenShift GitOps are installed as Operators from OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-pipelines-gitops-installed-as-operators.json"},{"id":"ocp-poddisruptionbudget-is-policy-api","text":"PodDisruptionBudget and Eviction are Policy API objects in OpenShift, controlling voluntary pod disruptions and eviction requests respectively.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-poddisruptionbudget-is-policy-api.json"},{"id":"ocp-podtemplate-is-core-v1-not-openshift","text":"PodTemplate is a core Kubernetes `v1` resource, not an OpenShift-specific extension — unlike Template, TemplateInstance, and BrokerTemplateInstance which are `template.openshift.io/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-podtemplate-is-core-v1-not-openshift.json"},{"id":"ocp-policy-apis-distinct-group","text":"OpenShift Container Platform organizes its APIs into distinct groups, with Policy APIs being one such group covering access control, authorization, and policy enforcement.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-policy-apis-distinct-group.json"},{"id":"ocp-port-6443-api-22623-mcs","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-port-6443-api-22623-mcs.json"},{"id":"ocp-power-monitoring-container-level-per-namespace","text":"The Power Monitoring Operator tracks power consumption metrics (CPU, DRAM) at the container level and reports per namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-power-monitoring-container-level-per-namespace.json"},{"id":"ocp-power-monitoring-cpu-dram-container-level","text":"Power Monitoring in OpenShift tracks CPU and DRAM power consumption at container-level granularity and must be explicitly configured (not enabled by default).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-power-monitoring-cpu-dram-container-level.json"},{"id":"ocp-power-monitoring-kepler-prometheus","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-power-monitoring-kepler-prometheus.json"},{"id":"ocp-power-monitoring-tech-preview","text":"Power Monitoring in OpenShift is a Technology Preview feature.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-power-monitoring-tech-preview.json"},{"id":"ocp-primary-ex280-certification-target","text":"Red Hat OpenShift Container Platform is the core self-managed product and the primary target of the EX280/DO280 certification track.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-primary-ex280-certification-target.json"},{"id":"ocp-project-api-group","text":"The API group for OpenShift project resources is `project.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-project-api-group.json"},{"id":"ocp-project-deletion-active-terminating-removed","text":"Project deletion transitions through states: Active → Terminating → removed; no new content can be added during Terminating.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-project-deletion-active-terminating-removed.json"},{"id":"ocp-project-extends-namespace","text":"OpenShift Projects extend Kubernetes namespaces with additional metadata including display name, description, and requesting user annotations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-project-extends-namespace.json"},{"id":"ocp-project-required-before-app-creation","text":"A project (or access to one with appropriate roles) is required before creating an application in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-project-required-before-app-creation.json"},{"id":"ocp-project-self-provisioning-cli","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-project-self-provisioning-cli.json"},{"id":"ocp-projects-extend-k8s-namespaces","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-projects-extend-k8s-namespaces.json"},{"id":"ocp-projects-wrap-namespaces","text":"OpenShift projects are OpenShift's abstraction over Kubernetes namespaces, serving as the organizational boundary for applications.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-projects-wrap-namespaces.json"},{"id":"ocp-prometheus-default-evaluation-interval-30s","text":"The default Prometheus evaluation interval is 30 seconds unless overridden per rule group.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-prometheus-default-evaluation-interval-30s.json"},{"id":"ocp-provides-multiple-cicd-solutions","text":"OpenShift Container Platform provides multiple CI/CD solutions, not a single integrated pipeline.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-provides-multiple-cicd-solutions.json"},{"id":"ocp-provisioning-apis-bare-metal-metal3-ironic","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-provisioning-apis-bare-metal-metal3-ironic.json"},{"id":"ocp-provisioning-vs-machine-api-distinction","text":"Provisioning APIs handle lower-level infrastructure provisioning while Machine APIs manage the OpenShift-level machine lifecycle; these are separate API groups in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-provisioning-vs-machine-api-distinction.json"},{"id":"ocp-prune-commands-default-dry-run","text":"All `oc adm prune` commands default to dry-run mode; the `--confirm` flag is required to actually delete objects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-prune-commands-default-dry-run.json"},{"id":"ocp-prune-default-retention-values","text":"Default pruning retention values: `--keep-complete=5`, `--keep-failed=1`, `--keep-younger-than=60m`, `--keep-tag-revisions=3`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-prune-default-retention-values.json"},{"id":"ocp-prune-over-size-limit-exclusive","text":"The `--prune-over-size-limit` flag cannot be combined with `--keep-tag-revisions` or `--keep-younger-than`; they are mutually exclusive strategies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-prune-over-size-limit-exclusive.json"},{"id":"ocp-publish-internal-private-cluster","text":"Setting `publish: Internal` in install-config.yaml creates a private cluster inaccessible from the internet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-publish-internal-private-cluster.json"},{"id":"ocp-pull-secret-no-drain-since-474","text":"As of OCP 4.7.4, changes to the global pull secret no longer trigger node drains or reboots","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-pull-secret-no-drain-since-474.json"},{"id":"ocp-quickstart-access-review-resources-rbac","text":"The `accessReviewResources` field on `ConsoleQuickStart` controls which users can see a quick start based on RBAC permissions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quickstart-access-review-resources-rbac.json"},{"id":"ocp-quickstart-cr-api-group","text":"Quick starts are defined by the `ConsoleQuickStart` custom resource in API group `console.openshift.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quickstart-cr-api-group.json"},{"id":"ocp-quickstart-next-references-cr-name","text":"The `nextQuickStart` field references other quick starts by their CR metadata `name`, not their `displayName`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quickstart-next-references-cr-name.json"},{"id":"ocp-quota-besteffort-scope-pods-only","text":"The `BestEffort` quota scope can only restrict the `pods` count (not CPU or memory).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quota-besteffort-scope-pods-only.json"},{"id":"ocp-quota-cpu-requests-cpu-interchangeable","text":"In ResourceQuota, `cpu` and `requests.cpu` are interchangeable; same for `memory`/`requests.memory` and `ephemeral-storage`/`requests.ephemeral-storage`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quota-cpu-requests-cpu-interchangeable.json"},{"id":"ocp-quota-forces-explicit-resource-specs","text":"When a quota specifies `requests.cpu` or `limits.memory`, every incoming container must explicitly declare those values or creation is rejected.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quota-forces-explicit-resource-specs.json"},{"id":"ocp-quota-object-count-syntax","text":"Object count quotas use the `count/<resource>.<group>` syntax (e.g., `count/deployments.apps`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quota-object-count-syntax.json"},{"id":"ocp-quota-storage-class-zero-prevents-use","text":"Setting a storage class quota value to `\"0\"` prevents any use of that storage class in the project.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-quota-storage-class-zero-prevents-use.json"},{"id":"ocp-rbac-subject-types","text":"The four types of subjects in OpenShift RBAC are: Users, Groups, Service Accounts, and system identities.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rbac-subject-types.json"},{"id":"ocp-rbac-two-levels","text":"RBAC in OpenShift operates at two levels: cluster roles (cluster-wide) and local/project roles (namespace-scoped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rbac-two-levels.json"},{"id":"ocp-requesting-user-gets-admin-role","text":"The user who creates a project is automatically assigned the admin role for that project (via the default project template).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-requesting-user-gets-admin-role.json"},{"id":"ocp-required-dns-records","text":"Required DNS records for OCP: `api.<cluster>.<domain>` (public+private), `api-int.<cluster>.<domain>` (private only), `*.apps.<cluster>.<domain>` (public+private), plus etcd A records and `_etcd-server-ssl._tcp` SRV records","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-required-dns-records.json"},{"id":"ocp-reserved-project-prefixes-require-adm","text":"Projects starting with `openshift-` or `kube-` cannot be created with `oc new-project`; they require `oc adm new-project`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-reserved-project-prefixes-require-adm.json"},{"id":"ocp-restricted-network-requires-local-osus","text":"Restricted/disconnected network clusters require a locally installed OpenShift Update Service (OSUS) instance and mirrored images","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-restricted-network-requires-local-osus.json"},{"id":"ocp-restricted-network-requires-mirror-registry","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-restricted-network-requires-mirror-registry.json"},{"id":"ocp-rhcos-ssh-core-user","text":"SSH access to RHCOS nodes uses the `core` user; the SSH key is injected via Ignition config","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhcos-ssh-core-user.json"},{"id":"ocp-rhdh-uses-janus-idp-backstage","text":"Red Hat Developer Hub (RHDH) is based on the Janus IDP platform (upstream Backstage) and provides a centralized software catalog.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhdh-uses-janus-idp-backstage.json"},{"id":"ocp-rhel-workers-api-before-kubelet","text":"RHEL worker nodes require the OpenShift API to be updated before the kubelet during cluster upgrades","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhel-workers-api-before-kubelet.json"},{"id":"ocp-rhosp-upi-dns-manual-cleanup","text":"DNS records must be manually cleaned up after running the RHOSP UPI teardown playbooks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhosp-upi-dns-manual-cleanup.json"},{"id":"ocp-rhosp-upi-requires-nova-neutron-secgroups","text":"For UPI on RHOSP, you must manually create Nova servers, Neutron ports, and security groups.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhosp-upi-requires-nova-neutron-secgroups.json"},{"id":"ocp-rhosp-upi-teardown-order","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhosp-upi-teardown-order.json"},{"id":"ocp-rhosp-upi-uninstall-uses-ansible-playbooks","text":"UPI cluster removal on RHOSP uses Ansible playbooks prefixed with \"down-\", not the openshift-install binary (which is used for IPI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rhosp-upi-uninstall-uses-ansible-playbooks.json"},{"id":"ocp-rollback-not-supported","text":"Rolling back an OCP cluster to a previous version is not supported — only forward updates are allowed.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-rollback-not-supported.json"},{"id":"ocp-route-is-openshift-specific-not-core-k8s","text":"The `Route` API object is an OpenShift-specific resource, not a core Kubernetes resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-route-is-openshift-specific-not-core-k8s.json"},{"id":"ocp-route-lb-strategies","text":"Load balancing strategy can be configured per-route with options: roundrobin, leastconn, source.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-route-lb-strategies.json"},{"id":"ocp-route-tls-termination-types","text":"OpenShift Routes support three TLS termination types: edge, passthrough, and re-encrypt.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-route-tls-termination-types.json"},{"id":"ocp-routes-openshift-specific-resource","text":"Routes are an OpenShift-specific resource for exposing services externally; Ingress is the upstream Kubernetes equivalent — OCP supports both","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-routes-openshift-specific-resource.json"},{"id":"ocp-routes-vs-ingress-features","text":"OpenShift Routes support TLS re-encryption, TLS passthrough, and blue-green traffic splitting — features not available in standard Kubernetes Ingress resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-routes-vs-ingress-features.json"},{"id":"ocp-runs-fsck-before-mount","text":"OpenShift automatically runs `fsck` on volumes before mounting them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-runs-fsck-before-mount.json"},{"id":"ocp-runs-on-rhcos","text":"OpenShift Container Platform runs on Red Hat Enterprise Linux CoreOS (RHCOS) and uses kdump for kernel crash analysis.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-runs-on-rhcos.json"},{"id":"ocp-scalability-performance-top-level-section","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-scalability-performance-top-level-section.json"},{"id":"ocp-scc-distinct-from-rbac","text":"Security Context Constraints (SCCs) are an authorization mechanism for pod-level security that is related to but distinct from RBAC.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-scc-distinct-from-rbac.json"},{"id":"ocp-scc-unique-to-openshift","text":"SecurityContextConstraints (SCCs) are unique to OpenShift and not present in vanilla Kubernetes, available via the `security.openshift.io` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-scc-unique-to-openshift.json"},{"id":"ocp-secondary-network-types-sriov-macvlan-bridge-ipvlan","text":"Supported secondary network types in OpenShift include SR-IOV, Macvlan, Bridge, and IPVLAN.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-secondary-network-types-sriov-macvlan-bridge-ipvlan.json"},{"id":"ocp-secondary-networks-defined-by-nad","text":"Secondary network configurations are defined using NetworkAttachmentDefinition (NAD) custom resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-secondary-networks-defined-by-nad.json"},{"id":"ocp-security-fips-install-time-only","text":"FIPS compliance mode in OpenShift Container Platform must be enabled at install time and cannot be enabled post-install.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-security-fips-install-time-only.json"},{"id":"ocp-security-three-domains","text":"OpenShift security documentation spans three domains: container security, certificate configuration, and encryption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-security-three-domains.json"},{"id":"ocp-self-provisioner-bound-to-authenticated-oauth","text":"The `self-provisioner` cluster role is bound to `system:authenticated:oauth` by default via the `self-provisioners` cluster role binding.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-self-provisioner-bound-to-authenticated-oauth.json"},{"id":"ocp-separate-subscription-rhacm-acs-odf-quay","text":"RHACM, ACS, ODF, and Red Hat Quay require separate subscriptions regardless of whether you have OKE or OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-separate-subscription-rhacm-acs-odf-quay.json"},{"id":"ocp-serverless-based-on-knative","text":"OpenShift Serverless is built on Knative and provides Kubernetes-native building blocks for serverless, event-driven applications on OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-serverless-based-on-knative.json"},{"id":"ocp-serverless-operator-changes-default-resource","text":"When the OpenShift Serverless Operator is installed, the default resource type for new applications changes to Serverless Deployment","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-serverless-operator-changes-default-resource.json"},{"id":"ocp-serverless-optional-install","text":"OpenShift Serverless is an optional component, not enabled by default, installed via the OpenShift Serverless Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-serverless-optional-install.json"},{"id":"ocp-service-mesh-built-on-istio","text":"OpenShift Service Mesh is built on Istio and deployed via the OpenShift Service Mesh Operator along with dependent operators like Kiali and Jaeger/Tempo.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-service-mesh-built-on-istio.json"},{"id":"ocp-service-mesh-two-active-versions","text":"OpenShift Service Mesh has two active major versions (2.x and 3.x); 3.x was in tech preview as of OCP 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-service-mesh-two-active-versions.json"},{"id":"ocp-service-mesh-under-integration","text":"Service Mesh is categorized under Integration in OpenShift documentation, not under Networking","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-service-mesh-under-integration.json"},{"id":"ocp-seven-observability-tools","text":"OpenShift Observability encompasses seven tools: Monitoring, Network Observability, Logging, OpenTelemetry, Distributed Tracing, Insights, and Power Monitoring.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-seven-observability-tools.json"},{"id":"ocp-six-observability-components","text":"OpenShift Observability has six core components: Monitoring, Logging, Distributed Tracing, Red Hat build of OpenTelemetry, Network Observability, and Power Monitoring.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-six-observability-components.json"},{"id":"ocp-sno-and-two-node-topologies","text":"Single Node OpenShift (SNO) and Two Node OpenShift are supported deployment topologies","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-sno-and-two-node-topologies.json"},{"id":"ocp-specialized-cli-tools","text":"OpenShift provides multiple specialized CLI tools beyond `oc`: `kn` (Serverless), `tkn` (Pipelines), `helm` (charts), `oc-mirror` (disconnected image mirroring), `odo` (developer), `argocd` (GitOps).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-specialized-cli-tools.json"},{"id":"ocp-ssh-access-disaster-recovery-only","text":"Direct SSH access to OpenShift nodes should only be used for disaster recovery; when the Kubernetes API is responsive, use privileged pods instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-ssh-access-disaster-recovery-only.json"},{"id":"ocp-storage-model-pv-pvc-storageclass","text":"OpenShift uses persistent volumes (PVs), persistent volume claims (PVCs), and StorageClasses as its core storage model with support for dynamic provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-storage-model-pv-pvc-storageclass.json"},{"id":"ocp-storage-uses-csi-plugin-architecture","text":"OpenShift 4.x uses the Container Storage Interface (CSI) as its standard plugin architecture for storage backends.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-storage-uses-csi-plugin-architecture.json"},{"id":"ocp-supported-accelerator-hardware","text":"Three specific hardware accelerators are supported by OCP: NVIDIA GPU, AMD Instinct GPU, and Intel Gaudi.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supported-accelerator-hardware.json"},{"id":"ocp-supported-architectures-x86-ppc64le-s390x","text":"OpenShift Container Platform supports multiple CPU architectures: x86_64 (amd64), ppc64le (IBM Power), and s390x (IBM Z).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supported-architectures-x86-ppc64le-s390x.json"},{"id":"ocp-supported-cloud-platforms-list","text":"The primary supported cloud/infrastructure installation targets for OCP include AWS, Azure, Azure Stack Hub, GCP, bare metal, and vSphere.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supported-cloud-platforms-list.json"},{"id":"ocp-supported-install-platforms","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supported-install-platforms.json"},{"id":"ocp-supports-dual-stack-ipv4-ipv6","text":"OpenShift Container Platform supports IPv4, IPv6, and dual-stack (IPv4 + IPv6) addressing","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-dual-stack-ipv4-ipv6.json"},{"id":"ocp-supports-ibm-cloud-bare-metal-classic","text":"OpenShift Container Platform supports installation on IBM Cloud Bare Metal (Classic) infrastructure as of OCP 4.21.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ibm-cloud-bare-metal-classic.json"},{"id":"ocp-supports-ibm-power-ppc64le","text":"OpenShift Container Platform supports installation on IBM Power systems using the ppc64le architecture.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ibm-power-ppc64le.json"},{"id":"ocp-supports-ibm-power-virtual-server","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ibm-power-virtual-server.json"},{"id":"ocp-supports-ibm-powervc","text":"OpenShift Container Platform supports installation on IBM PowerVC as a distinct platform option from other IBM Power deployment methods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ibm-powervc.json"},{"id":"ocp-supports-ibm-z-s390x","text":"OpenShift Container Platform supports installation on IBM Z and IBM LinuxONE using the s390x architecture.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ibm-z-s390x.json"},{"id":"ocp-supports-multi-arch-clusters","text":"OCP 4.17 supports heterogeneous multi-architecture clusters that can include Power nodes alongside other architectures.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-multi-arch-clusters.json"},{"id":"ocp-supports-ptp-hardware-time-sync","text":"OpenShift Container Platform supports PTP (Precision Time Protocol) hardware for time synchronization in latency-sensitive workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-ptp-hardware-time-sync.json"},{"id":"ocp-supports-sctp","text":"OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as an advanced networking feature beyond TCP/UDP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-sctp.json"},{"id":"ocp-supports-sctp-transport-protocol","text":"OpenShift Container Platform supports SCTP (Stream Control Transmission Protocol) as a transport-layer protocol, relevant for telecom workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-supports-sctp-transport-protocol.json"},{"id":"ocp-telemeter-client-sends-data-to-redhat","text":"The Telemeter Client sends a subset of platform Prometheus data to Red Hat for Remote Health Monitoring.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-telemeter-client-sends-data-to-redhat.json"},{"id":"ocp-template-hardcoded-namespace-removed","text":"Hardcoded namespace values in Template objects are removed during instantiation; only `${PARAMETER_REFERENCE}` namespace values are preserved","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-hardcoded-namespace-removed.json"},{"id":"ocp-template-instantiate-via-processedtemplates","text":"To process/instantiate a template via the API, POST to the `processedtemplates` endpoint (`/apis/template.openshift.io/v1/namespaces/{namespace}/processedtemplates`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-instantiate-via-processedtemplates.json"},{"id":"ocp-template-objects-only-required-field","text":"The only required field in an OpenShift Template is `objects` — the array of resources to include","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-objects-only-required-field.json"},{"id":"ocp-template-only-generator-expression","text":"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}`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-only-generator-expression.json"},{"id":"ocp-template-param-value-overrides-generator","text":"A Template parameter's `value` field takes precedence over the `generate`/`from` generator — if `value` is set, the generator is ignored","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-param-value-overrides-generator.json"},{"id":"ocp-template-parameter-syntax-dollar-brace","text":"Template parameters are referenced using `${PARAMETER_NAME}` syntax (not `{{}}` or other formats)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-parameter-syntax-dollar-brace.json"},{"id":"ocp-template-process-command","text":"`oc process` is the CLI command to process a template into a list of resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-process-command.json"},{"id":"ocp-template-vs-templateinstance-distinction","text":"A Template is the definition with parameters; a TemplateInstance is the record of an instantiation of that template","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-template-vs-templateinstance-distinction.json"},{"id":"ocp-templates-cluster-wide-via-openshift-namespace","text":"Templates can be stored in a project namespace or in the `openshift` namespace for cluster-wide availability","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-templates-cluster-wide-via-openshift-namespace.json"},{"id":"ocp-templates-openshift-specific-not-upstream","text":"Templates are an OpenShift-specific resource type (API group `template.openshift.io/v1`), not available in vanilla Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-templates-openshift-specific-not-upstream.json"},{"id":"ocp-three-networking-dashboard-categories","text":"OCP provides three networking dashboard categories: Networking/Linux Subsystem Stats (utilisation, saturation, errors), Networking/Infrastructure (OVN-Kubernetes metrics), and Networking/Ingress (Ingress Operator metrics).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-three-networking-dashboard-categories.json"},{"id":"ocp-three-observability-pillars","text":"The three pillars of observability in OpenShift are monitoring (metrics via Prometheus/Alertmanager), logging (Loki/Vector), and distributed tracing.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-three-observability-pillars.json"},{"id":"ocp-three-oracle-install-targets","text":"OCP supports three distinct Oracle installation targets: Oracle Cloud Infrastructure (OCI), Oracle Distributed Cloud, and Oracle Edge Cloud.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-three-oracle-install-targets.json"},{"id":"ocp-tls-default-profile-intermediate","text":"The default TLS security profile for all OpenShift components (Ingress Controller, control plane, kubelet) is Intermediate, with minimum TLS 1.2.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tls-default-profile-intermediate.json"},{"id":"ocp-tls-four-profile-types","text":"OpenShift supports four TLS security profile types: Old, Intermediate, Modern, and Custom, based on Mozilla recommended configurations.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tls-four-profile-types.json"},{"id":"ocp-tls-version-format","text":"TLS version values in OpenShift use the format `VersionTLS11`, `VersionTLS12`, `VersionTLS13`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tls-version-format.json"},{"id":"ocp-topology-view-in-developer-perspective","text":"The Topology view is in the Developer perspective (not Administrator) and is the primary UI for managing application lifecycle.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-topology-view-in-developer-perspective.json"},{"id":"ocp-tracing-jaeger-deprecated-for-tempo","text":"Jaeger has been deprecated in favor of Tempo as the tracing backend in recent OpenShift Container Platform versions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tracing-jaeger-deprecated-for-tempo.json"},{"id":"ocp-tracing-operator-managed-olm","text":"Distributed tracing components in OpenShift are installed and managed via OLM Operators (OpenTelemetry Operator and Tempo Operator).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tracing-operator-managed-olm.json"},{"id":"ocp-tracing-two-components-otel-tempo","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-tracing-two-components-otel-tempo.json"},{"id":"ocp-two-authorization-api-groups","text":"OpenShift has two parallel authorization API groups: `authorization.openshift.io/v1` (6 resources) and `authorization.k8s.io/v1` (4 resources).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-two-authorization-api-groups.json"},{"id":"ocp-two-build-systems","text":"OCP has two build systems: the traditional BuildConfig-based system (available since OpenShift 3.x) and the newer Shipwright-based Builds system.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-two-build-systems.json"},{"id":"ocp-two-build-systems-shipwright-buildconfig","text":"OpenShift has two coexisting build systems: Shipwright (newer, extensible) and BuildConfig (legacy)","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-two-build-systems-shipwright-buildconfig.json"},{"id":"ocp-two-console-resources-different-api-groups","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-two-console-resources-different-api-groups.json"},{"id":"ocp-two-node-topology-421","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-two-node-topology-421.json"},{"id":"ocp-unsupported-config-overrides-blocks-upgrades","text":"The `unsupportedConfigOverrides` field on operator resources is unsupported by Red Hat and blocks cluster upgrades; it must be removed before upgrading.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-unsupported-config-overrides-blocks-upgrades.json"},{"id":"ocp-update-channels-progression","text":"OpenShift update channel stability progression is: `candidate` → `fast` → `stable` → `eus`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-update-channels-progression.json"},{"id":"ocp-update-non-disruptive","text":"OCP cluster updates are non-disruptive — the cluster remains online during the update process (except single-node OpenShift which requires downtime)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-update-non-disruptive.json"},{"id":"ocp-update-rollback-not-supported","text":"Rolling back a failed OCP cluster update is not supported — contact Red Hat support instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-update-rollback-not-supported.json"},{"id":"ocp-update-upgrade-interchangeable","text":"The terms \"updating\" and \"upgrading\" are used interchangeably in OCP documentation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-update-upgrade-interchangeable.json"},{"id":"ocp-updates-zero-downtime","text":"OCP cluster updates are designed to be performed without taking the cluster offline (in-place, zero-downtime model).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-updates-zero-downtime.json"},{"id":"ocp-upi-csr-manual-approval","text":"In UPI installations, kubelet serving certificate CSRs must be manually approved because the machine-approver cannot validate them automatically","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-upi-csr-manual-approval.json"},{"id":"ocp-upi-minimum-machines","text":"UPI installation requires a minimum of 1 temporary bootstrap machine, 3 control plane machines, and 2 compute (worker) machines","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-upi-minimum-machines.json"},{"id":"ocp-upi-orphaned-resources-risk","text":"UPI clusters may leave orphaned Azure resources that require manual cleanup since the installer didn't create all of them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-upi-orphaned-resources-risk.json"},{"id":"ocp-user-group-apis-not-native-k8s","text":"OpenShift extends Kubernetes with its own User and Group custom resource types that are not native to upstream Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-user-group-apis-not-native-k8s.json"},{"id":"ocp-user-workload-monitoring-requires-explicit-enable","text":"User workload monitoring must be explicitly enabled; it is not active by default even though cluster monitoring is.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-user-workload-monitoring-requires-explicit-enable.json"},{"id":"ocp-users-cluster-scoped","text":"User objects in OpenShift are cluster-scoped resources (not namespaced).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-users-cluster-scoped.json"},{"id":"ocp-v411-baseline-capabilities","text":"The `v4.11` baselineCapabilitySet includes only: `baremetal`, `MachineAPI`, `marketplace`, and `openshift-samples`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-v411-baseline-capabilities.json"},{"id":"ocp-version-format","text":"OCP release versioning format: in `4.13.2`, 4 = major, 13 = minor, 2 = z-stream.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-version-format.json"},{"id":"ocp-versioning-major-minor-scheme","text":"OpenShift Container Platform versioning follows a major.minor scheme (e.g., 4.17).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-versioning-major-minor-scheme.json"},{"id":"ocp-view-capabilities-command","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-view-capabilities-command.json"},{"id":"ocp-virt-417-requires-ocp-417","text":"OpenShift Virtualization 4.17 requires OCP 4.17 — version alignment is mandatory.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-417-requires-ocp-417.json"},{"id":"ocp-virt-aws-ebs-gp3-no-live-migration","text":"On AWS, EBS gp3 storage does not support live migration or cloning; EFS does not support cloning or snapshots.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-aws-ebs-gp3-no-live-migration.json"},{"id":"ocp-virt-bandwidth-per-migration-zero-unlimited","text":"In OpenShift Virtualization, `bandwidthPerMigration: 0` means unlimited bandwidth (this is the default).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-bandwidth-per-migration-zero-unlimited.json"},{"id":"ocp-virt-boot-sources-namespace","text":"Boot source images are stored in the `openshift-virtualization-os-images` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-boot-sources-namespace.json"},{"id":"ocp-virt-cannot-run-single-stack-ipv6","text":"OpenShift Virtualization cannot run on single-stack IPv6 clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-cannot-run-single-stack-ipv6.json"},{"id":"ocp-virt-cdi-scratch-space","text":"CDI requires scratch space (a temporary PVC equal to the destination DataVolume size) during import and upload operations.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-cdi-scratch-space.json"},{"id":"ocp-virt-checkup-framework-tech-preview","text":"The cluster checkup framework for OpenShift Virtualization is Technology Preview in OCP 4.17 and includes three types: latency, DPDK, and storage checkups.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-checkup-framework-tech-preview.json"},{"id":"ocp-virt-checkup-results-in-configmap","text":"Cluster checkup results are stored in the same ConfigMap used for input (status fields are appended).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-checkup-results-in-configmap.json"},{"id":"ocp-virt-cloning-strategies","text":"Three cloning strategies for VM disks: `snapshot` (default when snapshots available), `csi-clone` (must be explicitly configured), and `copy` (host-assisted, least efficient).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-cloning-strategies.json"},{"id":"ocp-virt-components-openshift-cnv-namespace","text":"All OpenShift Virtualization components run in the `openshift-cnv` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-components-openshift-cnv-namespace.json"},{"id":"ocp-virt-dedicated-multus-network-recommended","text":"A dedicated Multus network for live migration traffic is highly recommended to avoid saturating tenant workload networks.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-dedicated-multus-network-recommended.json"},{"id":"ocp-virt-default-fs-overhead-5-5-percent","text":"Default file system overhead for VM PVCs is 5.5% of PVC space.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-default-fs-overhead-5-5-percent.json"},{"id":"ocp-virt-default-mincpu-penryn","text":"The default `minCPU` model for CPU feature labeling in OpenShift Virtualization is Penryn.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-default-mincpu-penryn.json"},{"id":"ocp-virt-default-parallel-migrations-5","text":"The default parallel migration limit in OpenShift Virtualization is 5 cluster-wide and 2 outbound per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-default-parallel-migrations-5.json"},{"id":"ocp-virt-default-pod-network-interrupted-live-migration","text":"Traffic on the default pod network is interrupted during live migration of VMs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-default-pod-network-interrupted-live-migration.json"},{"id":"ocp-virt-default-storage-class-annotation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-default-storage-class-annotation.json"},{"id":"ocp-virt-dpdk-checkup-zero-packet-loss","text":"The DPDK checkup verifies that VMs can run Data Plane Development Kit workloads with zero packet loss, and requires SR-IOV networking.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-dpdk-checkup-zero-packet-loss.json"},{"id":"ocp-virt-enable-common-boot-image-import-feature-gate","text":"The `enableCommonBootImageImport` feature gate in HyperConverged CR controls automatic updates for Red Hat boot sources; custom boot sources are not affected by this gate.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-enable-common-boot-image-import-feature-gate.json"},{"id":"ocp-virt-eviction-livemigrate-default-multinode","text":"The default VM eviction strategy is `LiveMigrate` for multi-node clusters and `None` for single-node OpenShift (SNO).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-eviction-livemigrate-default-multinode.json"},{"id":"ocp-virt-failed-node-drain-force","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-failed-node-drain-force.json"},{"id":"ocp-virt-hotplug-memory-cpu-ga-417","text":"Hot-plug memory and CPU from the web console are GA in OpenShift Virtualization 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-hotplug-memory-cpu-ga-417.json"},{"id":"ocp-virt-hpp-same-nodes-requirement","text":"HostPathProvisioner (HPP) pods must run on the same nodes as OpenShift Virtualization components — this is a hard requirement.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-hpp-same-nodes-requirement.json"},{"id":"ocp-virt-hyperconverged-cr-required","text":"After installing the OpenShift Virtualization operator, a `HyperConverged` custom resource must be created to deploy the virtualization platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-hyperconverged-cr-required.json"},{"id":"ocp-virt-hyperconverged-separate-infra-workloads","text":"The HyperConverged CR has separate `spec.infra.nodePlacement` and `spec.workloads.nodePlacement` sections for placing infrastructure vs workload components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-hyperconverged-separate-infra-workloads.json"},{"id":"ocp-virt-initiate-migration-vmim-object","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-initiate-migration-vmim-object.json"},{"id":"ocp-virt-integrated-feature","text":"OpenShift Virtualization is an integrated feature of OpenShift Container Platform that allows running and managing virtual machines alongside containers, not a separate product.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-integrated-feature.json"},{"id":"ocp-virt-ipam-not-supported-vm-nad","text":"IPAM is not supported in Network Attachment Definitions (NADs) for virtual machines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-ipam-not-supported-vm-nad.json"},{"id":"ocp-virt-kubemacpool-unique-mac","text":"KubeMacPool allocates unique MAC addresses from a shared pool for VMs; addresses persist across reboots.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-kubemacpool-unique-mac.json"},{"id":"ocp-virt-latency-checkup-requirements","text":"The latency checkup requires a bridge interface on cluster nodes, at least two worker nodes, and a configured `NetworkAttachmentDefinition`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-latency-checkup-requirements.json"},{"id":"ocp-virt-live-migration-defaults","text":"Default live migration settings: completionTimeoutPerGiB=800, parallelMigrationsPerCluster=5, parallelOutboundMigrationsPerNode=2, progressTimeout=150.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-live-migration-defaults.json"},{"id":"ocp-virt-live-migration-nad-openshift-cnv-namespace","text":"The live migration network NAD must be created in the `openshift-cnv` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-live-migration-nad-openshift-cnv-namespace.json"},{"id":"ocp-virt-live-migration-pre-copy-default","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-live-migration-pre-copy-default.json"},{"id":"ocp-virt-live-migration-requires-rwx","text":"Live migration requires ReadWriteMany (RWX) shared storage as a hard requirement.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-live-migration-requires-rwx.json"},{"id":"ocp-virt-localnet-requires-nncp-layer2-does-not","text":"OVN-Kubernetes localnet requires OVS bridge configuration via NNCP before creating the NAD; layer2 topology does not require NNCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-localnet-requires-nncp-layer2-does-not.json"},{"id":"ocp-virt-localnet-supports-netpol-not-trunk","text":"OVN-Kubernetes localnet supports network policies but not trunk access; Linux bridge supports trunk access but not network policies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-localnet-supports-netpol-not-trunk.json"},{"id":"ocp-virt-masquerade-default-pod-network","text":"Masquerade mode is the required binding mode for connecting VMs to the default pod network; it uses NAT via a Linux bridge.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-masquerade-default-pod-network.json"},{"id":"ocp-virt-mellanox-reboot-on-vf-increase","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-mellanox-reboot-on-vf-increase.json"},{"id":"ocp-virt-migration-config-in-hyperconverged","text":"Live migration cluster-wide settings are configured in the `HyperConverged` CR under `spec.liveMigrationConfig` in the `openshift-cnv` namespace.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-migration-config-in-hyperconverged.json"},{"id":"ocp-virt-migration-policy-label-selectors","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-migration-policy-label-selectors.json"},{"id":"ocp-virt-migration-tls-encrypted-default","text":"Live migration traffic in OpenShift Virtualization is encrypted with TLS by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-migration-tls-encrypted-default.json"},{"id":"ocp-virt-multus-enables-multiple-networks","text":"Multus is a meta CNI plugin that enables pods and VMs to connect to multiple network interfaces using other CNI plugins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-multus-enables-multiple-networks.json"},{"id":"ocp-virt-namespace-openshift-cnv","text":"OpenShift Virtualization must be installed into the `openshift-cnv` namespace; installing to any other namespace causes failure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-namespace-openshift-cnv.json"},{"id":"ocp-virt-nmo-standalone-operator","text":"The Node Maintenance Operator (NMO) is a standalone Operator deployed from OperatorHub — it is no longer shipped with OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-nmo-standalone-operator.json"},{"id":"ocp-virt-no-single-stack-ipv6","text":"OpenShift Virtualization cannot run on single-stack IPv6 clusters.","truth_value":"IN","justification_count":0,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-no-single-stack-ipv6.json"},{"id":"ocp-virt-node-exporter-daemonset-in-vm","text":"Custom VM metrics in OpenShift Virtualization are exposed via `node-exporter` running as a DaemonSet inside the VM, not on the host.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-node-exporter-daemonset-in-vm.json"},{"id":"ocp-virt-nonmigratable-livemigrate-blocks-upgrades","text":"Non-migratable VMs with `LiveMigrate` eviction strategy will block node drains and cluster upgrades; use `LiveMigrateIfPossible` or `None` instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-nonmigratable-livemigrate-blocks-upgrades.json"},{"id":"ocp-virt-odf-best-practice-rbd-block","text":"ODF best practice for OpenShift Virtualization: use `ocs-storagecluster-ceph-rbd` storage class with `VolumeMode: Block` for best performance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-odf-best-practice-rbd-block.json"},{"id":"ocp-virt-odf-dedicated-storage-windows","text":"OpenShift Data Foundation deployments require a dedicated storage class for Windows VM disks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-odf-dedicated-storage-windows.json"},{"id":"ocp-virt-operator-name","text":"The OpenShift Virtualization operator is called `kubevirt-hyperconverged` and is installed via OLM from the `redhat-operators` catalog source.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-operator-name.json"},{"id":"ocp-virt-ovn-kubernetes-required-cni","text":"OVN-Kubernetes is the supported (required) network provider for OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-ovn-kubernetes-required-cni.json"},{"id":"ocp-virt-ovn-localnet-recommended-underlay","text":"OVN-Kubernetes localnet is the recommended method to expose VMs to the underlying physical network (preferred over Linux bridge).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-ovn-localnet-recommended-underlay.json"},{"id":"ocp-virt-ports-49152-49153-reserved","text":"Ports 49152 and 49153 are reserved by the libvirt platform and incoming traffic to these ports is dropped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-ports-49152-49153-reserved.json"},{"id":"ocp-virt-postcopy-live-migration-ga-417","text":"Post-copy live migration is GA in OpenShift Virtualization 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-postcopy-live-migration-ga-417.json"},{"id":"ocp-virt-run-strategies","text":"VM run strategies are: `Always` (same as running:true), `RerunOnFailure`, `Manual`, and `Halted` (same as running:false).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-run-strategies.json"},{"id":"ocp-virt-runstrategy-running-mutually-exclusive","text":"`spec.runStrategy` and `spec.running` are mutually exclusive in a VirtualMachine spec — using both is invalid.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-runstrategy-running-mutually-exclusive.json"},{"id":"ocp-virt-rwo-no-live-migrate","text":"VMs with RWO storage or passthrough devices (GPUs) cannot live migrate; they require `evictionStrategy: None`.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-rwo-no-live-migrate.json"},{"id":"ocp-virt-rwx-block-best-practice","text":"ReadWriteMany (RWX) access mode and Block volume mode are the recommended best practice for VM disks in OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-rwx-block-best-practice.json"},{"id":"ocp-virt-rwx-pvc-required-live-migration","text":"VMs require RWX (ReadWriteMany) PVCs to be live migrated during node maintenance.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-rwx-pvc-required-live-migration.json"},{"id":"ocp-virt-sno-no-live-migration","text":"Single-node OpenShift (SNO) does not support live migration, HA, pod disruption budgets, or eviction strategies for OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-sno-no-live-migration.json"},{"id":"ocp-virt-sriov-setup-order","text":"SR-IOV setup order for VMs: SriovNetworkNodePolicy → SriovNetwork → VM config.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-sriov-setup-order.json"},{"id":"ocp-virt-storage-checkup-cluster-reader","text":"The storage checkup service account requires a `cluster-reader` ClusterRoleBinding (cluster-scoped, not namespace-scoped).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-storage-checkup-cluster-reader.json"},{"id":"ocp-virt-storage-profile-per-storage-class","text":"One StorageProfile is automatically created per StorageClass; if CDI does not recognize the provisioner, manual configuration is required (empty `status` section indicates this).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-storage-profile-per-storage-class.json"},{"id":"ocp-virt-subscription-channel-stable","text":"The OpenShift Virtualization operator subscription channel must be set to `stable`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-subscription-channel-stable.json"},{"id":"ocp-virt-subscription-no-affinity","text":"The `Subscription` object for OpenShift Virtualization node placement supports only `nodeSelector` and `tolerations` — it does not support `affinity`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-subscription-no-affinity.json"},{"id":"ocp-virt-supported-platforms-bare-metal","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-supported-platforms-bare-metal.json"},{"id":"ocp-virt-underlay-not-supported-rosa","text":"Connecting VMs directly to the underlay network is not supported on ROSA (Red Hat OpenShift Service on AWS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-underlay-not-supported-rosa.json"},{"id":"ocp-virt-virt-default-storage-class-overrides","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-virt-default-storage-class-overrides.json"},{"id":"ocp-virt-vm-name-max-47-chars","text":"VM name must not exceed 47 characters or live migration will fail.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-vm-name-max-47-chars.json"},{"id":"ocp-virt-vms-must-dhcp-masquerade","text":"VMs must use DHCP to acquire IPv4 addresses when using masquerade mode on the default pod network.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-vms-must-dhcp-masquerade.json"},{"id":"ocp-virt-vtpm-data-ephemeral","text":"vTPM data is ephemeral in OpenShift Virtualization — lost on migration or restart (affects BitLocker).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-vtpm-data-ephemeral.json"},{"id":"ocp-virt-wasp-agent-memory-overcommit","text":"Memory overcommit in OpenShift Virtualization uses `wasp-agent` which assigns swap to worker nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-wasp-agent-memory-overcommit.json"},{"id":"ocp-virt-watchdog-device-i6300esb","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-watchdog-device-i6300esb.json"},{"id":"ocp-virt-workers-must-be-rhcos","text":"OpenShift Virtualization worker nodes must run RHCOS; RHEL worker nodes are not supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-virt-workers-must-be-rhcos.json"},{"id":"ocp-vrf-supported-for-network-segmentation","text":"Virtual Routing and Forwarding (VRF) is supported in OpenShift for network segmentation, allowing multiple independent routing tables on the same node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-vrf-supported-for-network-segmentation.json"},{"id":"ocp-web-console-and-cli-first-class","text":"OpenShift Container Platform provides both a web console and CLI (oc) as first-class interfaces for cluster interaction","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-and-cli-first-class.json"},{"id":"ocp-web-console-built-in-customizable","text":"The OpenShift web console is a built-in, customizable web-based UI component of OpenShift Container Platform (not a separate install).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-built-in-customizable.json"},{"id":"ocp-web-console-capabilities-installed-via-operatorhub","text":"Optional web console capabilities (Pipelines, Serverless, Web Terminal) are installed as Operators through OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-capabilities-installed-via-operatorhub.json"},{"id":"ocp-web-console-prefs-in-masthead","text":"Web console user preferences are accessed from the masthead (top navigation bar) under the user profile","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-prefs-in-masthead.json"},{"id":"ocp-web-console-two-perspectives","text":"The OpenShift web console has two perspectives: Administrator and Developer; the default can be set in user preferences","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-two-perspectives.json"},{"id":"ocp-web-console-user-prefs-auto-saved","text":"OpenShift web console user preferences are automatically saved — no explicit save action is needed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-console-user-prefs-auto-saved.json"},{"id":"ocp-web-terminal-operator-provides-browser-cli","text":"The Web Terminal Operator provides a browser-based terminal with common CLI tools for interacting with the cluster from the web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-web-terminal-operator-provides-browser-cli.json"},{"id":"ocp-worker-wait-times","text":"When troubleshooting worker nodes, minimum wait times are 60 minutes for bare metal and 40 minutes for other platforms","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-worker-wait-times.json"},{"id":"ocp-workload-partitioning-install-time-only","text":"Workload partitioning (`cpuPartitioningMode: AllNodes`) can only be enabled at install time and cannot be disabled after installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-workload-partitioning-install-time-only.json"},{"id":"ocp-workloads-api-includes-deploymentconfig-build","text":"OpenShift workload APIs extend upstream Kubernetes with additional objects like DeploymentConfig and Build","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp-workloads-api-includes-deploymentconfig-build.json"},{"id":"ocp3-to-4-migration-not-upgrade","text":"OCP 3 to 4 is a migration, not an in-place upgrade — the architectures are fundamentally different","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp3-to-4-migration-not-upgrade.json"},{"id":"ocp4-built-on-operators","text":"OpenShift Container Platform 4.x is fundamentally built on Operators — cluster Operators manage core platform components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-built-on-operators.json"},{"id":"ocp4-core-components-managed-as-operators","text":"In OpenShift Container Platform 4.x, core platform components are managed as Operators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-core-components-managed-as-operators.json"},{"id":"ocp4-install-methods-ipi-upi","text":"OCP 4.x has two primary installation approaches: Installer-Provisioned Infrastructure (IPI, automated/opinionated) and User-Provisioned Infrastructure (UPI, manual/flexible).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-install-methods-ipi-upi.json"},{"id":"ocp4-operator-based-architecture","text":"OCP 4.x uses a fundamentally different architecture than 3.x, based on operators and immutable infrastructure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-operator-based-architecture.json"},{"id":"ocp4-rhcos-for-control-plane","text":"OCP 4 uses RHCOS (Red Hat Enterprise Linux CoreOS) for control plane nodes, replacing the traditional RHEL-based masters in OCP 3","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-rhcos-for-control-plane.json"},{"id":"ocp4-uses-openshift-install-binary","text":"OCP 4.x uses the `openshift-install` binary for installation, replacing the Ansible playbook approach used in OCP 3.x.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp4-uses-openshift-install-binary.json"},{"id":"ocp410-default-ebs-type-gp3","text":"The default EBS storage type for OpenShift Container Platform 4.10+ is gp3, provisioned via the AWS EBS CSI driver.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp410-default-ebs-type-gp3.json"},{"id":"ocp417-csi-spec-v160","text":"OpenShift Container Platform 4.17 supports CSI specification v1.6.0.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp417-csi-spec-v160.json"},{"id":"ocp417-default-scc-restricted-v2","text":"In OCP 4.17, the `restricted-v2` SCC is applied to all newly created pods by default, which enforces the `runtime/default` seccomp profile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp417-default-scc-restricted-v2.json"},{"id":"ocp417-infraenv-kernel-args-append-only","text":"In OCP 4.17, InfraEnv kernel arguments support only the `append` operation (no replace or delete).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp417-infraenv-kernel-args-append-only.json"},{"id":"ocp417-requires-ovn-kubernetes-migration","text":"OpenShift SDN is no longer supported in OCP 4.17; clusters must migrate to OVN-Kubernetes before upgrading to 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocp417-requires-ovn-kubernetes-migration.json"},{"id":"ocpvirt-arm64-linux-only-no-live-migration","text":"ARM64 OpenShift Virtualization supports Linux guests only with no live migration and no hotplug.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-arm64-linux-only-no-live-migration.json"},{"id":"ocpvirt-aws-no-sriov-no-bridge-cni","text":"AWS bare metal OpenShift Virtualization does not support SR-IOV or bridge CNI; OVN-Kubernetes secondary overlay networks must be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-aws-no-sriov-no-bridge-cni.json"},{"id":"ocpvirt-cnv-bridge-to-bridge-before-upgrade","text":"NetworkAttachmentDefinition spec.config.type must be changed from `cnv-bridge` to `bridge` before upgrading from OCP 4.12 or live migration will fail.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-cnv-bridge-to-bridge-before-upgrade.json"},{"id":"ocpvirt-dedicated-multus-migration-network-recommended","text":"A dedicated Multus network for live migration is highly recommended to avoid network saturation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-dedicated-multus-migration-network-recommended.json"},{"id":"ocpvirt-default-parallel-migrations-5","text":"The default maximum number of parallel live migrations per cluster is 5 in OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-default-parallel-migrations-5.json"},{"id":"ocpvirt-default-virt-storage-class-annotation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-default-virt-storage-class-annotation.json"},{"id":"ocpvirt-google-cloud-tech-preview","text":"Google Cloud support for OpenShift Virtualization is Technology Preview only (as of 4.21).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-google-cloud-tech-preview.json"},{"id":"ocpvirt-gpu-passthrough-no-live-migration","text":"VMs with GPU passthrough cannot be live migrated and must set `evictionStrategy: None`.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-gpu-passthrough-no-live-migration.json"},{"id":"ocpvirt-hotplug-feature-gate","text":"Hot plugging volumes on running VMs requires enabling the `HotplugVolumes` feature gate on the HyperConverged CR in the `openshift-cnv` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-hotplug-feature-gate.json"},{"id":"ocpvirt-hyperconverged-cr-entrypoint","text":"The HyperConverged CR is the single entrypoint for configuring OpenShift Virtualization and creates CRs for all sub-operators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-hyperconverged-cr-entrypoint.json"},{"id":"ocpvirt-ibmz-default-cpu-gen15b","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-ibmz-default-cpu-gen15b.json"},{"id":"ocpvirt-infra-cpu-overhead-4-cores","text":"OpenShift Virtualization infrastructure nodes require 4 additional CPU cores total; each worker node needs 2 additional cores for virtualization management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-infra-cpu-overhead-4-cores.json"},{"id":"ocpvirt-integrated-ocp-feature","text":"OpenShift Virtualization is an integrated feature of OpenShift Container Platform (not a separate product), enabling VMs to run alongside containers on the same platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-integrated-ocp-feature.json"},{"id":"ocpvirt-layer2-udn-preserves-ip-live-migration","text":"Layer2 topology User-Defined Networks (UDNs) preserve VM IP addresses during live migration without NAT.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-layer2-udn-preserves-ip-live-migration.json"},{"id":"ocpvirt-libvirt-session-mode-nonroot","text":"virt-launcher pods run libvirt in session mode as non-root (unprivileged), adhering to the `restricted` Kubernetes pod security standards profile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-libvirt-session-mode-nonroot.json"},{"id":"ocpvirt-live-migration-defaults","text":"Default live migration limits: 2 outbound migrations per node, 5 concurrent migrations per cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-live-migration-defaults.json"},{"id":"ocpvirt-localnet-supports-network-policies-bridge-does-not","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-localnet-supports-network-policies-bridge-does-not.json"},{"id":"ocpvirt-masquerade-default-binding-mode","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-masquerade-default-binding-mode.json"},{"id":"ocpvirt-memory-dump-pvc-sizing","text":"Memory dump PVC must use FileSystem volume mode and be sized as (VMMemorySize + 100Mi) × FileSystemOverhead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-memory-dump-pvc-sizing.json"},{"id":"ocpvirt-memory-overhead-formula","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-memory-overhead-formula.json"},{"id":"ocpvirt-mtv-separate-from-ocpvirt","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-mtv-separate-from-ocpvirt.json"},{"id":"ocpvirt-multus-meta-cni-plugin","text":"Multus is a meta CNI plugin that enables pods and VMs to attach to multiple network interfaces via other CNI plugins using NetworkAttachmentDefinition CRDs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-multus-meta-cni-plugin.json"},{"id":"ocpvirt-node-labels-not-removed-on-uninstall","text":"Node labels (`feature.node.kubevirt.io`) are not automatically removed when uninstalling OpenShift Virtualization and must be cleaned up manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-node-labels-not-removed-on-uninstall.json"},{"id":"ocpvirt-oadp-requires-1-3-x","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-oadp-requires-1-3-x.json"},{"id":"ocpvirt-online-snapshot-5min-deadline","text":"Online VM snapshots have a default 5-minute failure deadline, configurable via `FailureDeadline` in the snapshot spec.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-online-snapshot-5min-deadline.json"},{"id":"ocpvirt-ossm-compatibility-321","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-ossm-compatibility-321.json"},{"id":"ocpvirt-ports-49152-49153-reserved-libvirt","text":"Ports 49152 and 49153 are reserved by the libvirt platform in OpenShift Virtualization; incoming traffic to these ports is dropped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-ports-49152-49153-reserved-libvirt.json"},{"id":"ocpvirt-public-clouds-use-layer2-udn","text":"Public clouds (AWS, Azure, GCP, OCI) cannot connect VMs directly to the underlay; layer2 topology UDNs must be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-public-clouds-use-layer2-udn.json"},{"id":"ocpvirt-qemu-guest-agent-consistent-snapshots","text":"The QEMU guest agent is required for application-consistent (quiesced) online snapshots; without it, only best-effort snapshots are taken.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-qemu-guest-agent-consistent-snapshots.json"},{"id":"ocpvirt-rwo-blocks-live-migration","text":"VMs with ReadWriteOnce (RWO) storage cannot live migrate and must set evictionStrategy: None.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-rwo-blocks-live-migration.json"},{"id":"ocpvirt-rwx-block-recommended","text":"The recommended storage configuration for OpenShift Virtualization VMs is ReadWriteMany (RWX) access mode with Block volume mode.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-rwx-block-recommended.json"},{"id":"ocpvirt-rwx-block-recommended-storage","text":"ReadWriteMany (RWX) access mode with Block volume mode is the recommended storage configuration for OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-rwx-block-recommended-storage.json"},{"id":"ocpvirt-rwx-required-live-migration","text":"RWX access mode is required for live migration of VMs; VMs with RWO access mode cannot be live migrated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-rwx-required-live-migration.json"},{"id":"ocpvirt-service-account-tokens-invalid-after-migration","text":"Service account tokens become invalid after VM migration because they are bound to the original pod; user accounts should be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-service-account-tokens-invalid-after-migration.json"},{"id":"ocpvirt-single-stack-ipv6-tech-preview","text":"Single-stack IPv6 support in OpenShift Virtualization is Technology Preview only, limited to OVN-Kubernetes localnet and Linux bridge CNI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-single-stack-ipv6-tech-preview.json"},{"id":"ocpvirt-snapshot-feature-gate","text":"The Snapshot feature gate must be enabled in the `kubevirt` CR under `spec.developerConfiguration.featureGates` for VM snapshots to work.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-snapshot-feature-gate.json"},{"id":"ocpvirt-snapshot-three-crds","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-snapshot-three-crds.json"},{"id":"ocpvirt-sno-no-ha-no-livemigration","text":"Single-node OpenShift (SNO) does not support high availability, pod disruption, live migration, or eviction strategies for VMs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-sno-no-ha-no-livemigration.json"},{"id":"ocpvirt-sno-no-live-migration-ha","text":"Single-node OpenShift (SNO) does not support live migration, high availability, pod disruption budgets, or eviction strategies for OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-sno-no-live-migration-ha.json"},{"id":"ocpvirt-sriov-requires-bare-metal-or-rhosp","text":"SR-IOV in OpenShift Virtualization requires bare metal or RHOSP — it is not available on public clouds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-sriov-requires-bare-metal-or-rhosp.json"},{"id":"ocpvirt-storage-overhead-10gib-per-node","text":"OpenShift Virtualization installation requires approximately 10 GiB storage overhead per node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-storage-overhead-10gib-per-node.json"},{"id":"ocpvirt-svvp-certified-rhcos-intel-amd","text":"OpenShift Virtualization is SVVP-certified for Windows Server workloads on RHCOS workers with Intel/AMD CPUs only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-svvp-certified-rhcos-intel-amd.json"},{"id":"ocpvirt-tested-limits","text":"OpenShift Virtualization tested maximums: 216 vCPUs per VM, 6 TB RAM per VM, 500 hosts per cluster, 10,000 defined VMs per cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-tested-limits.json"},{"id":"ocpvirt-tls-rotation-cadence","text":"TLS certificate rotation cadence: KubeVirt rotates daily, CDI every 15 days, MAC pool yearly — all automatic with no disruption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-tls-rotation-cadence.json"},{"id":"ocpvirt-udn-namespace-label-required","text":"Namespaces using a primary User-Defined Network must have the label `k8s.ovn.org/primary-user-defined-network`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-udn-namespace-label-required.json"},{"id":"ocpvirt-virtctl-ssh-explicit-prefix-required","text":"Legacy `virtctl ssh` syntax (`type/name.namespace`) is removed; must use explicit `vmi/<name>` or `vm/<name>` format.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-virtctl-ssh-explicit-prefix-required.json"},{"id":"ocpvirt-vm-disk-migration-native-no-mtc","text":"VM disk storage class migration is now native to OpenShift Virtualization (no longer requires Migration Toolkit for Containers) and supports cross-namespace bulk migration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-vm-disk-migration-native-no-mtc.json"},{"id":"ocpvirt-vm-name-limit-47-chars","text":"Live migration fails if the VM name exceeds 47 characters in OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-vm-name-limit-47-chars.json"},{"id":"ocpvirt-vms-pod-network-default","text":"VMs connect to the pod network by default; secondary networks (Linux bridge, OVN-Kubernetes, SR-IOV) require explicit configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-vms-pod-network-default.json"},{"id":"ocpvirt-vtpm-no-snapshot-clone","text":"VMs with vTPM devices cannot be cloned or created from snapshots.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-vtpm-no-snapshot-clone.json"},{"id":"ocpvirt-windows-odf-dedicated-storageclass","text":"Windows VMs on OpenShift Data Foundation require a dedicated storage class, with Ceph RBD preferred over CephFS.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-windows-odf-dedicated-storageclass.json"},{"id":"ocpvirt-windows-vm-manual-mtu-config","text":"Windows VMs require manual MTU configuration with `netsh` because the Windows DHCP client does not read MTU options.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-windows-vm-manual-mtu-config.json"},{"id":"ocpvirt-worker-nodes-require-rhcos","text":"OpenShift Virtualization worker nodes must run Red Hat Enterprise Linux CoreOS (RHCOS); RHEL worker nodes are not supported.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ocpvirt-worker-nodes-require-rhcos.json"},{"id":"oda-distinct-from-oci","text":"Oracle Database Appliance (ODA) is a distinct installation target from Oracle Cloud Infrastructure (OCI) in OpenShift documentation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oda-distinct-from-oci.json"},{"id":"odf-dr-metro-regional-stretch-ga-420","text":"ODF 4.20 supports Metropolitan DR, Regional DR, and stretch cluster disaster recovery configurations, all GA.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-dr-metro-regional-stretch-ga-420.json"},{"id":"odf-internal-and-external-modes","text":"ODF supports internal mode (storage runs on OCP nodes) and external mode (connects to external Red Hat Ceph Storage or IBM FlashSystem).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-internal-and-external-modes.json"},{"id":"odf-multiple-storage-clusters","text":"Multiple ODF storage clusters can coexist — an external cluster can be deployed alongside an existing internal cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-multiple-storage-clusters.json"},{"id":"odf-noobaa-multicloud-object-gateway","text":"The Multicloud Object Gateway (NooBaa) is the ODF component that enables hybrid and multicloud object storage resource management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-noobaa-multicloud-object-gateway.json"},{"id":"odf-provides-block-file-object-storage","text":"Red Hat OpenShift Data Foundation (ODF) provides block, file, and object storage as a software-defined storage solution for OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-provides-block-file-object-storage.json"},{"id":"odf-provides-file-block-object-storage","text":"OpenShift Data Foundation (ODF) provides agnostic persistent storage supporting file, block, and object storage for OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odf-provides-file-block-object-storage.json"},{"id":"odo-not-officially-supported-docs","text":"The `odo` CLI tool is no longer covered in official OpenShift documentation; it falls under Cooperative Community Support, not standard Red Hat product support.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/odo-not-officially-supported-docs.json"},{"id":"oke-cluster-monitoring-included-uwm-excluded","text":"OKE includes cluster monitoring (Prometheus) but excludes User Workload Monitoring.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-cluster-monitoring-included-uwm-excluded.json"},{"id":"oke-excludes-developer-experience","text":"OKE excludes developer console, S2I/builder automation, OpenShift Pipelines, odo CLI, and Dev Spaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-excludes-developer-experience.json"},{"id":"oke-excludes-service-mesh-serverless-logging","text":"OKE excludes Service Mesh (Istio/Kiali), Serverless (Knative/Kourier), Distributed Tracing, and Platform Logging.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-excludes-service-mesh-serverless-logging.json"},{"id":"oke-includes-openshift-virtualization","text":"OpenShift Kubernetes Engine (OKE) includes OpenShift Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-includes-openshift-virtualization.json"},{"id":"oke-log-forwarding-included-platform-logging-excluded","text":"OKE includes log forwarding but excludes Platform Logging (Elasticsearch/Fluentd/Kibana stack).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-log-forwarding-included-platform-logging-excluded.json"},{"id":"oke-renamed-april-2020","text":"OpenShift Container Engine was renamed to OpenShift Kubernetes Engine in April 2020.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-renamed-april-2020.json"},{"id":"oke-same-binary-as-ocp","text":"OpenShift Kubernetes Engine (OKE) and OpenShift Container Platform (OCP) are the same binary download — the difference is subscription entitlement only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oke-same-binary-as-ocp.json"},{"id":"olm-csv-dual-role","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-csv-dual-role.json"},{"id":"olm-default-catalogsources-namespace","text":"Default CatalogSources (redhat-operators, certified-operators, community-operators) live in the `openshift-marketplace` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-default-catalogsources-namespace.json"},{"id":"olm-dependency-resolution-via-crd-api","text":"OLM resolves Operator dependencies by finding Operators in a catalog that satisfy required CRD APIs, not through direct package or bundle references.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-dependency-resolution-via-crd-api.json"},{"id":"olm-deployed-by-default-ocp","text":"Operator Lifecycle Manager (OLM) is deployed by default in OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-deployed-by-default-ocp.json"},{"id":"olm-deployed-by-default-ocp417","text":"OLM (Operator Lifecycle Manager) is deployed by default in OpenShift Container Platform 4.17 and manages Operator installation, upgrades, and RBAC.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-deployed-by-default-ocp417.json"},{"id":"olm-deprecations-schema","text":"The `olm.deprecations` schema in file-based catalogs allows deprecating entire packages, channels, or specific bundles with custom messages.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-deprecations-schema.json"},{"id":"olm-full-lifecycle-chain","text":"OLM operator installation follows a deterministic chain: CatalogSource → Subscription → InstallPlan → CSV → Operator Deployment, where Subscriptions track channels and InstallPlans require explicit approval fields.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-full-lifecycle-chain.json"},{"id":"olm-generational-transition-complete-in-disconnected","text":"OLM's generational transition (v1 GA → v1 extension API) is fully functional in disconnected environments only when both the v1 extension API reaches GA and private registry authentication is resolved.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-generational-transition-complete-in-disconnected.json"},{"id":"olm-included-since-ocp-4-0","text":"OLM (Operator Lifecycle Manager) has been included with OpenShift Container Platform since the initial OCP 4.0 release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-included-since-ocp-4-0.json"},{"id":"olm-index-image-managed-with-opm","text":"Index images (containing Operator bundle database snapshots with CSVs, CRDs, all versions) are managed with the `opm` CLI tool.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-index-image-managed-with-opm.json"},{"id":"olm-install-chain","text":"OLM operator installation lifecycle chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-install-chain.json"},{"id":"olm-install-plan-calculated-resource-list","text":"An install plan is a calculated list of resources to be created for automatic CSV installation or upgrade.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-install-plan-calculated-resource-list.json"},{"id":"olm-lifecycle-fully-ga","text":"The complete OLM operator lifecycle (CatalogSource → Subscription → InstallPlan → CSV) is fully GA and production-supported.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-lifecycle-fully-ga.json"},{"id":"olm-operator-group-watch-scope","text":"An Operator group configures all Operators in a namespace to watch for custom resources in a list of namespaces or cluster-wide.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-operator-group-watch-scope.json"},{"id":"olm-original-included-since-ocp-40","text":"The original Operator Lifecycle Manager (OLM) has been included in OpenShift Container Platform since the 4.0 initial release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-original-included-since-ocp-40.json"},{"id":"olm-resource-chain","text":"OLM operator installation lifecycle follows: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion → OperatorGroup.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-resource-chain.json"},{"id":"olm-subscription-tracks-channel","text":"A Subscription keeps CSVs up to date by tracking a channel in a package.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-subscription-tracks-channel.json"},{"id":"olm-supports-disconnected-environments","text":"OLM supports disconnected/restricted network environments for Operator installation and management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-supports-disconnected-environments.json"},{"id":"olm-transitioning-between-generations","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-transitioning-between-generations.json"},{"id":"olm-v1-api-renamed-from-operator-in-416","text":"The OLM v1 API was renamed from `Operator` to `ClusterExtension` in OCP 4.16.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-api-renamed-from-operator-in-416.json"},{"id":"olm-v1-cannot-auth-private-registries","text":"OLM v1 cannot authenticate to private registries including Red Hat-provided catalogs (known issue OCPBUGS-36364)","truth_value":"IN","justification_count":0,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-cannot-auth-private-registries.json"},{"id":"olm-v1-catalogd-namespace","text":"The OLM v1 catalog server runs in the `openshift-catalogd` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-catalogd-namespace.json"},{"id":"olm-v1-clusterextension-api-version","text":"The ClusterExtension custom resource uses apiVersion `olm.operatorframework.io/v1alpha1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-clusterextension-api-version.json"},{"id":"olm-v1-clusterextension-cluster-scoped","text":"ClusterExtension objects in OLM v1 are cluster-scoped, unlike original OLM where Operators could be namespace- or cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-clusterextension-cluster-scoped.json"},{"id":"olm-v1-extension-installable","text":"An OLM v1 extension is installable when it meets format and ownership requirements.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-extension-installable.json"},{"id":"olm-v1-extension-requirements","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-extension-requirements.json"},{"id":"olm-v1-extensions-superset-of-operators","text":"In OLM v1 terminology, \"extensions\" is the broader category that generalizes beyond just Operators; Operators are one type of extension.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-extensions-superset-of-operators.json"},{"id":"olm-v1-https-catalog-communication","text":"OLM v1 uses HTTPS encryption for catalogd server responses.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-https-catalog-communication.json"},{"id":"olm-v1-no-builtin-install-permissions","text":"OLM v1 does not have built-in permissions to install extensions; a ServiceAccount with explicit RBAC (ServiceAccount + ClusterRole + ClusterRoleBinding) must be created before installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-no-builtin-install-permissions.json"},{"id":"olm-v1-no-etcd-bundle-size-limit","text":"OLM v1 removes the etcd value size limit constraint on bundle size that existed in original OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-no-etcd-bundle-size-limit.json"},{"id":"olm-v1-ocp-421","text":"OCP 4.21 uses OLM v1 (Operator Lifecycle Manager v1) for extension management, replacing the classic OLM (v0) with new APIs and workflows.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-ocp-421.json"},{"id":"olm-v1-rebranded-extensions-ocp-417","text":"OLM v1 documentation is referred to as \"Extensions\" in the reorganized documentation starting in OCP 4.17.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-rebranded-extensions-ocp-417.json"},{"id":"olm-v1-single-ownership-principle","text":"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","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-single-ownership-principle.json"},{"id":"olm-v1-tech-preview-in-417","text":"OLM v1 (Operator Lifecycle Manager v1) is Technology Preview in OpenShift 4.17 — not GA.","truth_value":"IN","justification_count":0,"dependent_count":6,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-tech-preview-in-417.json"},{"id":"olm-v1-tech-preview-ocp-417","text":"OLM v1 is a Technology Preview feature in OpenShift Container Platform 4.17, not supported under production SLAs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-tech-preview-ocp-417.json"},{"id":"olm-v1-two-components","text":"OLM v1 is composed of two main components: Operator Controller (installs/manages Operators) and Catalogd (unpacks file-based catalog content from container images)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-two-components.json"},{"id":"olm-v1-two-core-components","text":"OLM v1 has two core components: Operator Controller (provides the ClusterExtension API) and catalogd (provides the Catalog API and unpacks catalog content).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-two-core-components.json"},{"id":"olm-v1-upgrade-constraint-policy-selfcertified","text":"Setting `upgradeConstraintPolicy: SelfCertified` in a ClusterExtension CR bypasses upgrade path constraints in OLM v1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olm-v1-upgrade-constraint-policy-selfcertified.json"},{"id":"olmconfig-cluster-scoped-singleton","text":"OLMConfig is a cluster-scoped singleton resource in `operators.coreos.com/v1` that configures OLM behavior globally.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olmconfig-cluster-scoped-singleton.json"},{"id":"olmconfig-disable-copied-csvs","text":"OLMConfig `spec.features.disableCopiedCSVs` disables the Copied CSV feature for cluster-scoped operators (OperatorGroup targeting all namespaces); re-enabling causes OLM to recreate them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olmconfig-disable-copied-csvs.json"},{"id":"olmconfig-packageserver-sync-interval-units","text":"OLMConfig `spec.features.packageServerSyncInterval` controls packageserver CatalogSource polling frequency and only accepts `h`, `m`, `s` duration units.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/olmconfig-packageserver-sync-interval-units.json"},{"id":"on-cluster-containerfile-from-configs","text":"On-cluster layering Containerfiles use `FROM configs AS final` as the base stage; out-of-cluster Containerfiles use the full RHCOS image reference.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/on-cluster-containerfile-from-configs.json"},{"id":"on-cluster-layering-push-pull-secret-different","text":"For on-cluster image layering builds, the push secret and pull secret must be different secrets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/on-cluster-layering-push-pull-secret-different.json"},{"id":"on-cluster-layering-tech-preview","text":"On-cluster RHCOS image layering is Technology Preview and requires the TechPreviewNoUpgrade feature gate to be enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/on-cluster-layering-tech-preview.json"},{"id":"one-operatorgroup-per-namespace","text":"Only one OperatorGroup is allowed per namespace — this is a hard constraint enforced by OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/one-operatorgroup-per-namespace.json"},{"id":"one-primary-multiple-secondary-networks","text":"Only one primary network can be created per pod; multiple secondary networks are allowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/one-primary-multiple-secondary-networks.json"},{"id":"only-ovn-kubernetes-supports-mtu-change","text":"Only the OVN-Kubernetes network plugin supports changing the MTU value on an existing OpenShift cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/only-ovn-kubernetes-supports-mtu-change.json"},{"id":"only-ovn-kubernetes-supports-post-install-mtu-change","text":"Only OVN-Kubernetes supports changing the cluster network MTU post-installation; OpenShift SDN does not.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/only-ovn-kubernetes-supports-post-install-mtu-change.json"},{"id":"oom-kills-use-crio-metric","text":"OOM kill tracking in the Node Metrics Dashboard uses the CRI-O specific counter container_runtime_crio_containers_oom_count_total.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oom-kills-use-crio-metric.json"},{"id":"opc-tech-preview-only","text":"The `opc` binary included in the tkn package is a Technology Preview feature and not supported for production use.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opc-tech-preview-only.json"},{"id":"open-service-broker-api-provisions-services","text":"The Open Service Broker API is the mechanism for provisioning and binding to external managed services (databases, message queues, etc.) within OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/open-service-broker-api-provisions-services.json"},{"id":"openshift-ai-cloud-service-runs-on-osd-or-rosa","text":"OpenShift AI Cloud Service installs on OpenShift Dedicated or ROSA — not on self-managed OCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ai-cloud-service-runs-on-osd-or-rosa.json"},{"id":"openshift-ai-feature-store-tech-preview","text":"OpenShift AI Feature Store is a Technology Preview feature, not GA.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ai-feature-store-tech-preview.json"},{"id":"openshift-ai-integrates-s3-compatible-storage","text":"OpenShift AI uses S3-compatible object stores as the primary data storage integration pattern.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ai-integrates-s3-compatible-storage.json"},{"id":"openshift-ai-plus-ocp-ai-platform","text":"Red Hat OpenShift AI combined with OpenShift Container Platform forms the enterprise AI application platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ai-plus-ocp-ai-platform.json"},{"id":"openshift-ai-three-user-roles","text":"OpenShift AI defines three distinct user roles: OpenShift cluster administrators, OpenShift AI administrators, and OpenShift AI users (ML Ops Engineers / Data Scientists).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ai-three-user-roles.json"},{"id":"openshift-api-docs-organized-by-category","text":"OpenShift organizes its API reference documentation by functional category, with Metadata being one of the primary categories","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-api-docs-organized-by-category.json"},{"id":"openshift-api-mgmt-managed-service-on-3scale","text":"Red Hat OpenShift API Management is a managed service add-on built on 3scale API Management, running on managed OpenShift offerings (ROSA/OSD).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-api-mgmt-managed-service-on-3scale.json"},{"id":"openshift-api-mgmt-not-self-installed","text":"OpenShift API Management is a managed service, not a self-installed operator — distinct from self-managed 3scale.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-api-mgmt-not-self-installed.json"},{"id":"openshift-apis-organized-by-category","text":"OpenShift organizes its APIs into categories including Workloads, Networking, Storage, Security, Config, Metadata, and Operator APIs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-apis-organized-by-category.json"},{"id":"openshift-apiserver-separate-from-kube-apiserver","text":"The OpenShift API Server handles OpenShift-specific APIs (Routes, DeploymentConfigs, Builds) and is separate from the Kubernetes API Server which handles core Kubernetes resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-apiserver-separate-from-kube-apiserver.json"},{"id":"openshift-builtin-oauth-server","text":"OpenShift has a built-in OAuth server managed by the Authentication operator; this is a key differentiator from vanilla Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-builtin-oauth-server.json"},{"id":"openshift-cloud-services-rosa-aro","text":"OpenShift cloud services (managed) editions include ROSA (Red Hat OpenShift Service on AWS) and ARO (Microsoft Azure Red Hat OpenShift).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-cloud-services-rosa-aro.json"},{"id":"openshift-controller-manager-separate-from-kube-cm","text":"The openshift-controller-manager is separate from kube-controller-manager and handles OpenShift-specific controllers for builds, deployments, images, and service accounts","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-controller-manager-separate-from-kube-cm.json"},{"id":"openshift-extends-k8s-authorization-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-extends-k8s-authorization-model.json"},{"id":"openshift-extends-kubernetes-api","text":"OpenShift extends the Kubernetes API with platform-specific Extension API resources such as `Route`, `BuildConfig`, `DeploymentConfig`, `ImageStream`, `Project`, `ClusterVersion`, and `MachineSet`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-extends-kubernetes-api.json"},{"id":"openshift-extension-apis-beyond-kubernetes","text":"OpenShift extends the Kubernetes API with its own extension API objects including Route, DeploymentConfig, BuildConfig, ImageStream, Project, and SecurityContextConstraints.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-extension-apis-beyond-kubernetes.json"},{"id":"openshift-gitops-is-argocd-distribution","text":"OpenShift GitOps is Red Hat's supported distribution of Argo CD.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-gitops-is-argocd-distribution.json"},{"id":"openshift-gitops-uses-argocd","text":"OpenShift GitOps is an Operator that uses Argo CD as its declarative GitOps engine, enabling GitOps workflows across multicluster OpenShift and Kubernetes infrastructure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-gitops-uses-argocd.json"},{"id":"openshift-gitops-wraps-argocd","text":"OpenShift GitOps is an Operator (installed via OLM/OperatorHub) that wraps Argo CD as its declarative GitOps engine for continuous deployment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-gitops-wraps-argocd.json"},{"id":"openshift-has-own-authorization-api","text":"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`).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-has-own-authorization-api.json"},{"id":"openshift-has-own-authorization-api-group","text":"OpenShift has its own authorization API group (`authorization.openshift.io`) in addition to Kubernetes-native RBAC (`rbac.authorization.k8s.io`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-has-own-authorization-api-group.json"},{"id":"openshift-identity-lifecycle-chain","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-identity-lifecycle-chain.json"},{"id":"openshift-ingress-translates-to-routes","text":"In OpenShift, the ingress controller typically translates Kubernetes Ingress objects into Route objects","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ingress-translates-to-routes.json"},{"id":"openshift-install-destroy-requires-metadata","text":"The `openshift-install destroy cluster` command requires the original installation directory containing `metadata.json` and the same installer version used to create the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-install-destroy-requires-metadata.json"},{"id":"openshift-mtu-change-post-install","text":"OpenShift supports changing MTU (Maximum Transmission Unit) settings post-installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-mtu-change-post-install.json"},{"id":"openshift-pipelines-based-on-tekton","text":"OpenShift Pipelines is a Kubernetes-native CI/CD framework based on Tekton where each pipeline step runs in its own container.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-based-on-tekton.json"},{"id":"openshift-pipelines-installed-via-operator","text":"OpenShift Pipelines is typically installed via the OpenShift Pipelines Operator from OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-installed-via-operator.json"},{"id":"openshift-pipelines-kubernetes-native-crds","text":"OpenShift Pipelines defines pipelines as Kubernetes custom resources (CRDs), not as external server configurations, making them portable across Kubernetes clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-kubernetes-native-crds.json"},{"id":"openshift-pipelines-separate-release-cadence","text":"OpenShift Pipelines releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-separate-release-cadence.json"},{"id":"openshift-pipelines-serverless-ephemeral","text":"OpenShift Pipelines is serverless in nature — pipeline runs are ephemeral and do not require a persistent CI server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-serverless-ephemeral.json"},{"id":"openshift-pipelines-serverless-no-central-controller","text":"OpenShift Pipelines is serverless and distributed with no central controller dependency, unlike Jenkins which requires a central controller node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-serverless-no-central-controller.json"},{"id":"openshift-pipelines-tekton-replaces-jenkins","text":"OpenShift Pipelines (Tekton) is the strategic replacement for Jenkins as the CI/CD engine in OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-tekton-replaces-jenkins.json"},{"id":"openshift-pipelines-tekton-strategic-cicd","text":"OpenShift Pipelines (Tekton-based) is the strategic CI/CD solution replacing Jenkins in OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-tekton-strategic-cicd.json"},{"id":"openshift-pipelines-uses-kubernetes-crds","text":"OpenShift Pipelines uses Kubernetes custom resources (Tasks, Pipelines, PipelineRuns, Triggers) as its primitives.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-pipelines-uses-kubernetes-crds.json"},{"id":"openshift-project-wraps-namespace","text":"In OpenShift, Projects wrap Namespaces with additional annotations and RBAC; every Project creates a corresponding Namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-project-wraps-namespace.json"},{"id":"openshift-ptp-hardware-support","text":"OpenShift provides PTP (Precision Time Protocol) hardware support for high-accuracy time synchronization use cases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-ptp-hardware-support.json"},{"id":"openshift-sdn-deprecated","text":"OpenShift SDN is deprecated; migration to OVN-Kubernetes is expected.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-sdn-deprecated.json"},{"id":"openshift-self-managed-ocp-platform-plus","text":"OpenShift self-managed editions include OpenShift Container Platform (OCP) and OpenShift Platform Plus, which bundles OCP with ACS, ACM, and Quay.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-self-managed-ocp-platform-plus.json"},{"id":"openshift-serverless-based-on-knative","text":"OpenShift Serverless is the Red Hat-supported distribution of Knative on OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-serverless-based-on-knative.json"},{"id":"openshift-specific-api-groups","text":"`build.openshift.io/v1` and `apps.openshift.io/v1` are OpenShift-specific API groups; `apps/v1` and `batch/v1` are standard Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-specific-api-groups.json"},{"id":"openshift-supports-sctp-protocol","text":"OpenShift supports SCTP (Stream Control Transmission Protocol) as a transport protocol beyond TCP/UDP, relevant for telecom workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-supports-sctp-protocol.json"},{"id":"openshift-uses-metal3-ironic-for-bare-metal","text":"OpenShift uses Metal3 (Metal³) and Ironic for bare-metal provisioning; the provisioning service (Ironic) is deployed automatically during bare-metal IPI installations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-uses-metal3-ironic-for-bare-metal.json"},{"id":"openshift-virt-engine-separate-edition","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-virt-engine-separate-edition.json"},{"id":"openshift-virt-supported-vm-maximums-per-node","text":"OpenShift Virtualization has defined supported maximum numbers of VMs per node, documented as part of tuning and scaling guidance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-virt-supported-vm-maximums-per-node.json"},{"id":"openshift-virt-versions-track-ocp","text":"OpenShift Virtualization version numbers align with OpenShift Container Platform version numbers (e.g., OCP 4.21 = OpenShift Virtualization 4.21).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-virt-versions-track-ocp.json"},{"id":"openshift-virtualization-is-ocp-feature","text":"OpenShift Virtualization is a feature within OpenShift Container Platform that enables creating, deploying, and managing virtual machines alongside containers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openshift-virtualization-is-ocp-feature.json"},{"id":"openstack-supported-ocp-install-platform","text":"Red Hat OpenStack Platform (RHOSP) is a supported installation platform for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openstack-supported-ocp-install-platform.json"},{"id":"openstack-supports-ipi-and-upi","text":"OCP supports both IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) installation methods on OpenStack.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/openstack-supports-ipi-and-upi.json"},{"id":"opentelemetry-separate-operator","text":"Red Hat build of OpenTelemetry is a separate Operator from the cluster monitoring stack and the distributed tracing platform Operator, installed via OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opentelemetry-separate-operator.json"},{"id":"opentelemetry-three-signal-types","text":"Red Hat build of OpenTelemetry collects three signal types: traces, metrics, and logs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opentelemetry-three-signal-types.json"},{"id":"opentelemetry-vendor-neutral-standard","text":"OpenTelemetry is the vendor-neutral, open standard for telemetry collection in OpenShift, not tied to a specific observability backend.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opentelemetry-vendor-neutral-standard.json"},{"id":"operator-apis-backed-by-crds","text":"Each OpenShift Operator API is backed by a CustomResourceDefinition (CRD).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-apis-backed-by-crds.json"},{"id":"operator-apis-distinct-from-config-apis","text":"OpenShift distinguishes Operator APIs from Config APIs, Machine APIs, and core Kubernetes APIs in its documentation taxonomy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-apis-distinct-from-config-apis.json"},{"id":"operator-apis-implemented-as-crds","text":"OpenShift Operator APIs are implemented as CustomResourceDefinitions (CRDs) registered in the cluster, distinct from core Kubernetes APIs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-apis-implemented-as-crds.json"},{"id":"operator-bundle-exactly-one-csv","text":"Each Operator bundle must contain exactly one Cluster Service Version (CSV) and belong to at least one channel.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-bundle-exactly-one-csv.json"},{"id":"operator-catalog-to-deployment-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-catalog-to-deployment-pipeline.json"},{"id":"operator-configs-singleton-named-cluster","text":"Most operator.openshift.io/v1 configuration resources are singleton objects named \"cluster\"","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-configs-singleton-named-cluster.json"},{"id":"operator-delivery-through-console-integration","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-delivery-through-console-integration.json"},{"id":"operator-dependency-types","text":"OLM supports three Operator dependency types: `olm.package` (version-based), `olm.gvk` (API group/version/kind), and `olm.constraint` (generic constraints).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-dependency-types.json"},{"id":"operator-driven-immutable-platform-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":6,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-driven-immutable-platform-model.json"},{"id":"operator-framework-four-components","text":"The Operator Framework consists of four components: Operator SDK, Operator Lifecycle Manager (OLM), Operator Registry, and OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-framework-four-components.json"},{"id":"operator-install-chain","text":"The Operator install chain is: OperatorHub → PackageManifest → Subscription → InstallPlan → CSV.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-install-chain.json"},{"id":"operator-lifecycle-bounded-by-platform-constraints","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-lifecycle-bounded-by-platform-constraints.json"},{"id":"operator-lifecycle-classifications-since-414","text":"Operator lifecycle classifications (Platform Aligned, Platform Agnostic, Rolling Stream) were introduced in OCP 4.14.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-lifecycle-classifications-since-414.json"},{"id":"operator-log-level-separate-from-operand","text":"OpenShift operator resources have two separate log level controls: `logLevel` for the operand and `operatorLogLevel` for the operator itself","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-log-level-separate-from-operand.json"},{"id":"operator-log-levels-four-values","text":"Valid log levels across OpenShift operators are: Normal, Debug, Trace, and TraceAll (default is Normal).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-log-levels-four-values.json"},{"id":"operator-log-levels-normal-debug-trace-traceall","text":"OpenShift operator CRs accept log level values `Normal`, `Debug`, `Trace`, and `TraceAll` for both `logLevel` (operand) and `operatorLogLevel` (operator).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-log-levels-normal-debug-trace-traceall.json"},{"id":"operator-loglevel-vs-operatorloglevel","text":"`logLevel` controls logging for the operand while `operatorLogLevel` controls logging for the operator process itself","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-loglevel-vs-operatorloglevel.json"},{"id":"operator-management-state-three-values","text":"The `managementState` field on OpenShift operators supports three values: `Managed` (actively reconciles), `Unmanaged` (stops reconciling), and `Removed` (deletes managed resources).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-management-state-three-values.json"},{"id":"operator-manager-default-watches-own-namespace","text":"The Operator Manager default behavior watches only the namespace where the Operator runs; set `Namespace: \"\"` to watch all namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-manager-default-watches-own-namespace.json"},{"id":"operator-maturity-model-five-levels","text":"The Operator maturity model defines five phases: Basic Install → Seamless Upgrades → Full Lifecycle → Deep Insights → Auto Pilot.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-maturity-model-five-levels.json"},{"id":"operator-observed-config-lives-in-spec","text":"The `observedConfig` field lives in `.spec` (not `.status`) because it serves as input to the operator's reconciliation logic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-observed-config-lives-in-spec.json"},{"id":"operator-pattern-replicates-across-platforms","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-pattern-replicates-across-platforms.json"},{"id":"operator-pki-cert-rotation","text":"OperatorPKI CA cert validity is 10 years (rotated after 9 years); target cert validity is 6 months (rotated after 3 months)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-pki-cert-rotation.json"},{"id":"operator-sdk-ansible-helm-base-images-not-deprecated","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-ansible-helm-base-images-not-deprecated.json"},{"id":"operator-sdk-deprecated-ocp-417","text":"The Red Hat-supported Operator SDK CLI is deprecated in OpenShift Container Platform 4.17 and planned for removal in a future release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-deprecated-ocp-417.json"},{"id":"operator-sdk-deprecated-ocp417","text":"The Red Hat-supported Operator SDK CLI is deprecated as of OpenShift Container Platform 4.17 and planned for removal in a future release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-deprecated-ocp417.json"},{"id":"operator-sdk-embeds-kubebuilder","text":"Kubebuilder is embedded into the Operator SDK as the scaffolding solution for Go-based Operators; existing Kubebuilder projects work as-is.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-embeds-kubebuilder.json"},{"id":"operator-sdk-init-go-plugin-default","text":"The `operator-sdk init` command uses the Go plugin by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-init-go-plugin-default.json"},{"id":"operator-sdk-make-bundle-shortcut","text":"Running `make bundle` automates executing `operator-sdk generate kustomize manifests` followed by `operator-sdk generate bundle`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-make-bundle-shortcut.json"},{"id":"operator-sdk-official-build-tool","text":"The Operator SDK is the official tool for building custom Operators in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-official-build-tool.json"},{"id":"operator-sdk-part-of-operator-framework","text":"The Operator SDK is a component of the Operator Framework, used to build, test, and deploy Operators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-part-of-operator-framework.json"},{"id":"operator-sdk-repo-flag-required-outside-gopath","text":"The `--repo` flag is required when creating an Operator SDK project outside `$GOPATH/src/`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-repo-flag-required-outside-gopath.json"},{"id":"operator-sdk-restricted-security-context-not-default-ns","text":"The `--security-context-config restricted` flag for `operator-sdk run bundle` is not compatible with the `default` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-restricted-security-context-not-default-ns.json"},{"id":"operator-sdk-scorecard-default-config-path","text":"The default scorecard configuration path is `bundle/tests/scorecard/config.yaml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-scorecard-default-config-path.json"},{"id":"operator-sdk-supported-types","text":"The Operator SDK supports building Operators based on Go, Ansible, Helm, or Java.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-supported-types.json"},{"id":"operator-sdk-supports-four-languages","text":"The Operator SDK supports four project types: Go, Ansible, Helm, and Java.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-supports-four-languages.json"},{"id":"operator-sdk-three-types","text":"Operator SDK supports three Operator types: Helm (lower maturity), Ansible, and Go (enables highest maturity level).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-three-types.json"},{"id":"operator-sdk-version-ocp-417","text":"OpenShift Container Platform 4.17 supports Operator SDK v1.36.1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-version-ocp-417.json"},{"id":"operator-sdk-version-ocp417","text":"OpenShift Container Platform 4.17 ships Operator SDK v1.36.1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operator-sdk-version-ocp417.json"},{"id":"operatorcondition-upgradeable-false-blocks","text":"An OperatorCondition with `Upgradeable=False` blocks OLM from upgrading that Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorcondition-upgradeable-false-blocks.json"},{"id":"operatorgroup-api-group-v1","text":"The OperatorGroup resource uses API group `operators.coreos.com/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-api-group-v1.json"},{"id":"operatorgroup-default-upgrade-strategy-blocks-failed","text":"OperatorGroup `Default` upgrade strategy blocks operator upgrades when a prior install/upgrade has failed (CSVs can only move to Replacing from Succeeded)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-default-upgrade-strategy-blocks-failed.json"},{"id":"operatorgroup-failforward-techpreview-unsafe","text":"OperatorGroup `TechPreviewUnsafeFailForward` upgrade strategy allows CSVs to move to Replacing from Succeeded or Failed, and triggers new InstallPlan generation on catalog updates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-failforward-techpreview-unsafe.json"},{"id":"operatorgroup-namespace-scopes","text":"OperatorGroups control which namespaces an Operator can watch, with options: AllNamespaces, OwnNamespace, or a specific set of namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-namespace-scopes.json"},{"id":"operatorgroup-one-per-namespace","text":"Only one OperatorGroup should exist per namespace; multiple OperatorGroups cause conflicts","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-one-per-namespace.json"},{"id":"operatorgroup-serviceaccountname-deploy-identity","text":"OperatorGroup `serviceAccountName` specifies the service account used to deploy operators within the group, enabling least-privilege configurations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-serviceaccountname-deploy-identity.json"},{"id":"operatorgroup-targetnamespaces-overrides-selector","text":"In an OperatorGroup, `targetNamespaces` takes precedence over `selector`; if both are set, the selector is ignored","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-targetnamespaces-overrides-selector.json"},{"id":"operatorgroup-unit-of-multitenancy","text":"OperatorGroup is the unit of multitenancy for OLM-managed operators, constraining which namespaces an operator can watch and manage","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorgroup-unit-of-multitenancy.json"},{"id":"operatorhub-apis-group-operators-coreos","text":"OperatorHub API objects (CatalogSource, Subscription, InstallPlan, CSV, OperatorGroup, OperatorCondition) are CRDs under the `operators.coreos.com` API group, managed by OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-apis-group-operators-coreos.json"},{"id":"operatorhub-apis-namespace-coreos","text":"OperatorHub API resources are in the operators.coreos.com API group, discoverable via `oc api-resources | grep operators.coreos.com`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-apis-namespace-coreos.json"},{"id":"operatorhub-available-every-ocp4-cluster","text":"OperatorHub is available in every OpenShift Container Platform 4.x cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-available-every-ocp4-cluster.json"},{"id":"operatorhub-controls-default-sources-only","text":"OperatorHub config controls default catalog sources only; custom CatalogSource resources are managed separately and are not affected","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-controls-default-sources-only.json"},{"id":"operatorhub-default-catalogsources","text":"The default CatalogSources in the openshift-marketplace namespace are: redhat-operators, certified-operators, community-operators, and redhat-marketplace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-default-catalogsources.json"},{"id":"operatorhub-deployed-by-default-ocp417","text":"OperatorHub is deployed by default in OpenShift Container Platform 4.17 for Operator discovery via the web console.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-deployed-by-default-ocp417.json"},{"id":"operatorhub-disable-all-disconnected","text":"Setting `disableAllDefaultSources: true` on OperatorHub is a required step for disconnected/air-gapped installations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-disable-all-disconnected.json"},{"id":"operatorhub-install-pipeline-order","text":"The Operator installation pipeline follows the chain: CatalogSource → Subscription → InstallPlan → ClusterServiceVersion (CSV).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-install-pipeline-order.json"},{"id":"operatorhub-singleton-named-cluster","text":"The OperatorHub resource (`config.openshift.io/v1`) is a cluster-scoped singleton named `cluster` that controls default hub catalog sources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-singleton-named-cluster.json"},{"id":"operatorhub-sources-override-disableall","text":"When `disableAllDefaultSources` is `true`, individual `spec.sources[]` entries can selectively re-enable specific default catalog sources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorhub-sources-override-disableall.json"},{"id":"operatorpki-api-group","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-api-group.json"},{"id":"operatorpki-ca-validity-10-years","text":"OperatorPKI CA certificate validity is 10 years, rotated after 9 years","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-ca-validity-10-years.json"},{"id":"operatorpki-creates-three-resources","text":"The CNO creates three resources per OperatorPKI named `<name>`: Secret `<name>-ca`, ConfigMap `<name>-ca`, and Secret `<name>-cert`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-creates-three-resources.json"},{"id":"operatorpki-required-field-commonname","text":"The only required spec field for OperatorPKI is `spec.targetCert.commonName`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-required-field-commonname.json"},{"id":"operatorpki-target-cert-extended-key-usages","text":"OperatorPKI target certificates have both ClientAuth and ServerAuth extended key usages enabled","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-target-cert-extended-key-usages.json"},{"id":"operatorpki-target-cert-validity-6-months","text":"OperatorPKI target certificate validity is 6 months, rotated after 3 months","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operatorpki-target-cert-validity-6-months.json"},{"id":"operators-and-updates-share-security-constraint-hierarchy","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operators-and-updates-share-security-constraint-hierarchy.json"},{"id":"operators-control-loop-pattern","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operators-control-loop-pattern.json"},{"id":"operators-day1-day2","text":"Operators automate both Day 1 operations (installation and configuration) and Day 2 operations (autoscaling, backups, ongoing maintenance).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operators-day1-day2.json"},{"id":"operators-subset-of-extensions-olm-v1","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operators-subset-of-extensions-olm-v1.json"},{"id":"operators-three-roles","text":"Operators documentation addresses three distinct roles: cluster administrators (install/manage), developers (consume), and Operator authors (build with Operator SDK).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/operators-three-roles.json"},{"id":"opm-cli-for-operator-catalogs","text":"The `opm` CLI is used to create and maintain Operator catalogs, distinct from the Operator SDK which builds/tests/deploys Operators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-cli-for-operator-catalogs.json"},{"id":"opm-file-based-catalog-default-since-411","text":"File-based catalog (FBC) is the default Operator catalog format since OpenShift Container Platform 4.11, replacing the deprecated SQLite-based format.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-file-based-catalog-default-since-411.json"},{"id":"opm-index-add-graph-update-modes","text":"The `opm index add --mode` flag supports graph update modes: `replaces` (default), `semver`, and `semver-skippatch`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-index-add-graph-update-modes.json"},{"id":"opm-index-subcommands-sqlite-only","text":"The `opm index` subcommands (add, prune, prune-stranded, rm) work only with SQLite-based catalogs and do not work with file-based catalogs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-index-subcommands-sqlite-only.json"},{"id":"opm-migrate-sqlite-to-fbc","text":"The `opm migrate` command converts a SQLite-based catalog index to file-based catalog format.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-migrate-sqlite-to-fbc.json"},{"id":"opm-not-forward-compatible","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-not-forward-compatible.json"},{"id":"opm-render-converts-to-fbc","text":"`opm render <image-reference>` converts an existing catalog image into file-based catalog format","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-render-converts-to-fbc.json"},{"id":"opm-serve-default-port-50051","text":"The `opm serve` command serves declarative configs via gRPC on default port 50051.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-serve-default-port-50051.json"},{"id":"opm-serve-loads-config-at-startup-only","text":"The `opm serve` command loads configuration at startup only; runtime changes to the declarative config are not reflected.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-serve-loads-config-at-startup-only.json"},{"id":"opm-validate-checks-catalog","text":"`opm validate <catalog-directory>` checks catalog validity including duplicate detection and schema violations","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-validate-checks-catalog.json"},{"id":"opm-validate-command","text":"The `opm validate <catalog-dir>` command validates a file-based Operator catalog.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/opm-validate-command.json"},{"id":"optional-cluster-capabilities","text":"Optional cluster capabilities that can be disabled at install time include: Baremetal, CSI Snapshot Controller, Cluster Samples, Cluster Storage, Console, and Insights.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/optional-cluster-capabilities.json"},{"id":"oracle-database-appliance-supported-platform","text":"Oracle Database Appliance (ODA) is a supported installation platform for OCP as of version 4.21.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oracle-database-appliance-supported-platform.json"},{"id":"oracle-dci-definition","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oracle-dci-definition.json"},{"id":"oracle-distributed-cloud-supported-platform","text":"Oracle Distributed Cloud Infrastructure (DCI) is a supported installation target for OCP, distinct from standard Oracle Cloud Infrastructure (OCI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oracle-distributed-cloud-supported-platform.json"},{"id":"oracle-edge-cloud-supported-platform","text":"Oracle Edge Cloud is a supported installation platform for OCP 4.21, distinct from Oracle Cloud Infrastructure (OCI).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/oracle-edge-cloud-supported-platform.json"},{"id":"osd-ci-cd-ecosystem","text":"OpenShift Dedicated supports Tekton Pipelines, Shipwright builds, BuildConfig (legacy), GitOps (Argo CD), and Jenkins for CI/CD.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/osd-ci-cd-ecosystem.json"},{"id":"osd-provisioned-via-openshift-cluster-manager","text":"OpenShift Dedicated clusters are provisioned and configured through OpenShift Cluster Manager (OCM), not directly via `openshift-install`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/osd-provisioned-via-openshift-cluster-manager.json"},{"id":"osd-runs-on-aws-and-gcp-only","text":"OpenShift Dedicated (OSD) runs on AWS and Google Cloud only — no Azure or on-prem support.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/osd-runs-on-aws-and-gcp-only.json"},{"id":"osd-shared-responsibility-model","text":"OpenShift Dedicated has a shared responsibility model — Red Hat manages the control plane and infrastructure; customers manage workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/osd-shared-responsibility-model.json"},{"id":"osd-uses-ovn-kubernetes-network-plugin","text":"OpenShift Dedicated uses OVN-Kubernetes as its network plugin (not OpenShift SDN).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/osd-uses-ovn-kubernetes-network-plugin.json"},{"id":"out-of-service-taint-evicts-all-pods","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/out-of-service-taint-evicts-all-pods.json"},{"id":"out-of-service-taint-key","text":"The out-of-service taint for non-graceful node shutdown is `node.kubernetes.io/out-of-service=nodeshutdown:NoExecute`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/out-of-service-taint-key.json"},{"id":"out-of-service-taint-manual","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/out-of-service-taint-manual.json"},{"id":"out-of-service-taint-running-node-corruption","text":"Applying the out-of-service taint to a node that is still running risks filesystem corruption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/out-of-service-taint-running-node-corruption.json"},{"id":"ove-ansible-full-vm-lifecycle","text":"Red Hat Ansible Automation Platform manages the full VM lifecycle on OpenShift Virtualization Engine: provisioning, patching, configuration enforcement, and migration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ove-ansible-full-vm-lifecycle.json"},{"id":"ove-installed-via-assisted-installer","text":"OpenShift Virtualization Engine is installed via the Assisted Installer for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ove-installed-via-assisted-installer.json"},{"id":"ove-migration-sources-vsphere-and-rhv","text":"OpenShift Virtualization Engine supports migration from VMware vSphere and Red Hat Virtualization (RHV) via the Migration Toolkit for Virtualization.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ove-migration-sources-vsphere-and-rhv.json"},{"id":"ove-rhacm-multi-cluster-management","text":"Red Hat Advanced Cluster Management (RHACM) provides single-console multi-cluster management with built-in security policies and compliance for OpenShift Virtualization Engine clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ove-rhacm-multi-cluster-management.json"},{"id":"ovn-databases-run-on-each-node","text":"All OVN databases (nbdb, sbdb) and northd run on each node (not centralized), processing mostly local information.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-databases-run-on-each-node.json"},{"id":"ovn-dual-stack-same-gateway-interface","text":"OVN-Kubernetes dual-stack limitation: both IPv4 and IPv6 must use the same default gateway interface; violation causes CrashLoopBackOff in ovnkube-node pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-dual-stack-same-gateway-interface.json"},{"id":"ovn-geneve-port-6081","text":"OVN-Kubernetes uses Geneve encapsulation (not VXLAN) with default port 6081 and default MTU 1400","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-geneve-port-6081.json"},{"id":"ovn-internal-subnets-immutable","text":"v4InternalSubnet (100.64.0.0/16), v6InternalSubnet (fd98::/48), and internalTransitSwitchSubnet cannot be changed after installation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-internal-subnets-immutable.json"},{"id":"ovn-ipv6-disable-causes-crashloop","text":"Setting `ipv6.disable=1` in kernel arguments causes CrashLoopBackOff in ovnkube-node pods and blocks cluster upgrades.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-ipv6-disable-causes-crashloop.json"},{"id":"ovn-k-secondary-cni-type","text":"OVN-Kubernetes secondary networks require CNI type `ovn-k8s-cni-overlay` with `cniVersion: 0.3.1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-k-secondary-cni-type.json"},{"id":"ovn-k-secondary-topologies","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-k-secondary-topologies.json"},{"id":"ovn-kubernetes-built-on-ovn-ovs","text":"OVN-Kubernetes is built on Open Virtual Network (OVN), which itself builds on Open vSwitch (OVS).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-built-on-ovn-ovs.json"},{"id":"ovn-kubernetes-default-cni","text":"OVN-Kubernetes is the default Container Network Interface (CNI) for OpenShift Container Platform clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-default-cni.json"},{"id":"ovn-kubernetes-default-cni-plugin","text":"OVN-Kubernetes is the default CNI network plugin in OpenShift Container Platform (replacing OpenShift SDN as default from OCP 4.12+)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-default-cni-plugin.json"},{"id":"ovn-kubernetes-default-network-plugin","text":"OVN-Kubernetes is the default network plugin and supports both IPv4 and IPv6.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-default-network-plugin.json"},{"id":"ovn-kubernetes-default-network-plugin-417","text":"OVN-Kubernetes is the default network plugin in OpenShift Container Platform 4.17","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-default-network-plugin-417.json"},{"id":"ovn-kubernetes-default-sdn","text":"OVN-Kubernetes is the default SDN in OpenShift Container Platform; network issues should be checked in the `openshift-ovn-kubernetes` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-default-sdn.json"},{"id":"ovn-kubernetes-enforces-network-policy","text":"OVN-Kubernetes natively enforces Kubernetes NetworkPolicy and OpenShift-specific network policy objects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-enforces-network-policy.json"},{"id":"ovn-kubernetes-internal-subnets-must-not-overlap","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-internal-subnets-must-not-overlap.json"},{"id":"ovn-kubernetes-join-subnet-default","text":"The default OVN-Kubernetes V4JoinSubnet is `100.64.0.0/16` and V6JoinSubnet is `fd98::/64`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-join-subnet-default.json"},{"id":"ovn-kubernetes-multicast-low-bandwidth-only","text":"OVN-Kubernetes default network multicast is suitable only for low-bandwidth use cases (coordination, service discovery); SR-IOV is required for high-bandwidth multicast.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-multicast-low-bandwidth-only.json"},{"id":"ovn-kubernetes-namespace","text":"OVN-Kubernetes resources run in the `openshift-ovn-kubernetes` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-namespace.json"},{"id":"ovn-kubernetes-overhead-100-bytes","text":"OVN-Kubernetes network plugin has a 100-byte overhead, so cluster network MTU should be set to hardware MTU minus 100.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-overhead-100-bytes.json"},{"id":"ovn-kubernetes-overlay-overhead-100-bytes","text":"OVN-Kubernetes overlay overhead is exactly 100 bytes; cluster network MTU = hardware MTU - 100.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-overlay-overhead-100-bytes.json"},{"id":"ovn-kubernetes-owns-egress-crds","text":"OVN-Kubernetes plugin owns most egress CRDs: EgressFirewall, EgressIP, EgressQoS, EgressService, and AdminPolicyBasedExternalRoute (all `k8s.ovn.org/v1`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-owns-egress-crds.json"},{"id":"ovn-kubernetes-primary-network-plugin","text":"OVN-Kubernetes is the primary network plugin in OpenShift 4.x (replacing OpenShift SDN in newer versions).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-primary-network-plugin.json"},{"id":"ovn-kubernetes-single-service-network-block","text":"OVN-Kubernetes supports only a single IP address block for the service network.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-single-service-network-block.json"},{"id":"ovn-kubernetes-supports-ipsec","text":"OVN-Kubernetes supports IPsec for encrypting cluster network traffic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-supports-ipsec.json"},{"id":"ovn-kubernetes-uses-geneve","text":"OVN-Kubernetes uses the Geneve protocol (not VXLAN) to create the overlay network between nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-kubernetes-uses-geneve.json"},{"id":"ovn-masquerade-subnet-mutable","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-masquerade-subnet-mutable.json"},{"id":"ovn-session-affinity-last-packet","text":"OVN-Kubernetes session affinity stickiness timeout is calculated from the last packet received, not the first — continuous traffic keeps the session alive indefinitely.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovn-session-affinity-last-packet.json"},{"id":"ovnkube-control-plane-deployment-2-replicas","text":"`ovnkube-control-plane` runs as a Deployment with 2 replicas on separate control plane nodes, using leader election.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovnkube-control-plane-deployment-2-replicas.json"},{"id":"ovnkube-node-daemonset-8-containers","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovnkube-node-daemonset-8-containers.json"},{"id":"ovnkubernetes-default-network-plugin","text":"OVNKubernetes is the default network plugin (CNI) for OpenShift Container Platform, supporting Linux and hybrid Linux/Windows networks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovnkubernetes-default-network-plugin.json"},{"id":"ovnkubernetes-default-only-cni","text":"OVNKubernetes is the default and only supported networkType in OpenShift 4.17; it supports only a single service network CIDR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovnkubernetes-default-only-cni.json"},{"id":"ovs-bonding-two-modes","text":"OVS bonding supports two modes: `active-backup` and `balance-slb`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovs-bonding-two-modes.json"},{"id":"ovs-bridge-architecture-br-ex-br-phy","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ovs-bridge-architecture-br-ex-br-phy.json"},{"id":"packagemanifest-api-group","text":"PackageManifest uses API group `packages.operators.coreos.com/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifest-api-group.json"},{"id":"packagemanifest-defaultchannel-behavior","text":"The PackageManifest `defaultChannel` field determines what channel gets installed when no channel is specified in a Subscription","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifest-defaultchannel-behavior.json"},{"id":"packagemanifest-deprecation-three-levels","text":"PackageManifest deprecation can occur at three levels: entire package, individual channel, or individual entry (CSV) within a channel","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifest-deprecation-three-levels.json"},{"id":"packagemanifest-entries-upgrade-paths","text":"The `entries[]` array in a PackageManifest channel lists all CSVs with their upgrade edges, enabling OLM to compute valid upgrade paths","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifest-entries-upgrade-paths.json"},{"id":"packagemanifest-read-only","text":"PackageManifest is a read-only resource with no POST/PUT/DELETE endpoints; it is generated from CatalogSource content","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifest-read-only.json"},{"id":"packagemanifests-list-available-operators","text":"`oc get packagemanifests -n openshift-marketplace` lists available Operators from OperatorHub catalogs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/packagemanifests-list-available-operators.json"},{"id":"pdb-api-group-policy-v1","text":"PodDisruptionBudget (PDB) is a `policy/v1` API resource, not in the `apps` or `core` API groups.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-api-group-policy-v1.json"},{"id":"pdb-block-all-evictions-settings","text":"Setting `maxUnavailable: 0` or `minAvailable: 100%` on a PDB blocks all voluntary evictions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-block-all-evictions-settings.json"},{"id":"pdb-default-maxunavailable-1","text":"Default `maxUnavailable` for machine config pools is 1; it should not be changed to 3 for the control plane.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-default-maxunavailable-1.json"},{"id":"pdb-minavailable-maxunavailable-mutually-exclusive","text":"`minAvailable` and `maxUnavailable` in a PDB spec are mutually exclusive — specifying both is invalid.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-minavailable-maxunavailable-mutually-exclusive.json"},{"id":"pdb-minavailable-or-maxunavailable","text":"PDB spec uses either `minAvailable` or `maxUnavailable` (not both) to define disruption tolerance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-minavailable-or-maxunavailable.json"},{"id":"pdb-misconfiguration-blocks-updates","text":"PodDisruptionBudget misconfiguration can prevent nodes from draining during cluster updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-misconfiguration-blocks-updates.json"},{"id":"pdb-namespaced-resource","text":"PodDisruptionBudgets are namespaced resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-namespaced-resource.json"},{"id":"pdb-null-vs-empty-selector","text":"A null PDB selector matches no pods; an empty selector `{}` matches all pods in the namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-null-vs-empty-selector.json"},{"id":"pdb-only-voluntary-disruptions","text":"PodDisruptionBudgets only protect against voluntary disruptions (drains, evictions), not involuntary ones (node crashes, OOM kills).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-only-voluntary-disruptions.json"},{"id":"pdb-unhealthy-pod-eviction-default","text":"The `unhealthyPodEvictionPolicy` field in PDB defaults to `IfHealthyBudget` behavior, meaning unhealthy running pods can only be evicted if `currentHealthy >= desiredHealthy`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-unhealthy-pod-eviction-default.json"},{"id":"pdb-values-intorstring","text":"PDB `minAvailable` and `maxUnavailable` fields accept either an integer or a percentage string (IntOrString type).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-values-intorstring.json"},{"id":"pdb-voluntary-disruptions-only","text":"PDBs only affect voluntary disruptions (evictions); they do not protect against involuntary disruptions like node crashes or OOM kills.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-voluntary-disruptions-only.json"},{"id":"pdb-voluntary-only","text":"PodDisruptionBudgets are only honored on voluntary evictions, not involuntary disruptions like node failures.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pdb-voluntary-only.json"},{"id":"pending-csrs-after-restart","text":"After a graceful restart, pending CSRs may need to be manually approved with `oc adm certificate approve` for nodes to reach Ready state.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pending-csrs-after-restart.json"},{"id":"performanceprofile-1g-hugepage-removes-2m","text":"Setting PerformanceProfile `defaultHugepagesSize` to 1G removes all 2M hugepage folders from the node, making 2M hugepage configuration impossible.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-1g-hugepage-removes-2m.json"},{"id":"performanceprofile-api-group-v2","text":"PerformanceProfile uses API group `performance.openshift.io/v2` (v2, not v1).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-api-group-v2.json"},{"id":"performanceprofile-balance-isolated-default-true","text":"PerformanceProfile `balanceIsolated` defaults to `true`; setting to `false` disables load balancing on isolated CPUs for most predictable latency.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-balance-isolated-default-true.json"},{"id":"performanceprofile-generates-tuned-and-runtimeclass","text":"PerformanceProfile controller auto-creates a RuntimeClass (name in `.status.runtimeClass`) and a Tuned CR (referenced in `.status.tuned`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-generates-tuned-and-runtimeclass.json"},{"id":"performanceprofile-highpower-perpod-mutually-exclusive","text":"PerformanceProfile workloadHints `highPowerConsumption` and `perPodPowerManagement` cannot be enabled together (mutually exclusive).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-highpower-perpod-mutually-exclusive.json"},{"id":"performanceprofile-net-queue-count-equals-reserved","text":"When `userLevelNetworking` is enabled in a PerformanceProfile, network device queue count is set equal to the reserved CPU count.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-net-queue-count-equals-reserved.json"},{"id":"performanceprofile-numa-topology-default-best-effort","text":"PerformanceProfile NUMA `topologyPolicy` defaults to `best-effort` when TopologyManager is enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-numa-topology-default-best-effort.json"},{"id":"performanceprofile-required-fields","text":"PerformanceProfile requires `spec.cpu` (with both `isolated` and `reserved`) and `spec.nodeSelector`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-required-fields.json"},{"id":"performanceprofile-rt-kernel-requires-explicit-enable","text":"Real-time kernel packages are not installed on OpenShift nodes unless `realTimeKernel.enabled: true` is explicitly set in the PerformanceProfile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/performanceprofile-rt-kernel-requires-explicit-enable.json"},{"id":"perspective-switcher-requires-cluster-admin","text":"The perspective switcher (to toggle between Administrator and Developer views) is available only to `cluster-admin` users","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/perspective-switcher-requires-cluster-admin.json"},{"id":"pgt-bindingrules-must-match-siteconfig-labels","text":"PGT `bindingRules` labels must match labels in the `SiteConfig` CR — a mismatch means policies won't apply to the managed cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pgt-bindingrules-must-match-siteconfig-labels.json"},{"id":"pgt-deprecated-for-policygenerator","text":"PolicyGenTemplate (PGT) is deprecated in OCP 4.17 in favor of RHACM `PolicyGenerator` CRs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pgt-deprecated-for-policygenerator.json"},{"id":"pgt-namespace-cr-separate-file","text":"The `Namespace` CR must NOT be in the same file as the `PolicyGenTemplate` CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pgt-namespace-cr-separate-file.json"},{"id":"pgt-policy-naming-convention","text":"Generated ZTP policy names follow the pattern `<PGT-metadata.name>-<policyName>` (e.g., `group-du-sno-config-policy`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pgt-policy-naming-convention.json"},{"id":"pipelines-tekton-gitops-argocd","text":"OpenShift Pipelines is Tekton-based; OpenShift GitOps is Argo CD-based.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pipelines-tekton-gitops-argocd.json"},{"id":"pipelines-vs-builds-distinction","text":"OpenShift Pipelines orchestrates multi-step CI/CD workflows, while OpenShift Builds focuses on container image creation — they are related but distinct.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pipelines-vs-builds-distinction.json"},{"id":"platform-delivers-software-under-governance-across-topologies","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-delivers-software-under-governance-across-topologies.json"},{"id":"platform-governance-from-identity-to-node","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-governance-from-identity-to-node.json"},{"id":"platform-lifecycle-bounded-at-install-and-update","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-lifecycle-bounded-at-install-and-update.json"},{"id":"platform-lifecycle-spans-updates-and-recovery","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-lifecycle-spans-updates-and-recovery.json"},{"id":"platform-model-with-topology-variants","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-model-with-topology-variants.json"},{"id":"platform-none-cannot-use-machine-api","text":"Clusters with infrastructure platform type `none` cannot use the Machine API, and this cannot be changed post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-none-cannot-use-machine-api.json"},{"id":"platform-plus-bundles-ocp-acm-acs-quay","text":"OpenShift Platform Plus is a product SKU that bundles OpenShift Container Platform with Advanced Cluster Management (ACM), Advanced Cluster Security (ACS), and Quay.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-plus-bundles-ocp-acm-acs-quay.json"},{"id":"platform-type-none-no-machine-api","text":"Clusters with infrastructure platform type `none` cannot use the Machine API, and this is immutable post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/platform-type-none-no-machine-api.json"},{"id":"pod-binding-endpoint-path","text":"The preferred (non-deprecated) pod binding endpoint is `POST /api/v1/namespaces/{namespace}/pods/{name}/binding`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-binding-endpoint-path.json"},{"id":"pod-bound-to-node-never-rebound","text":"Once a pod is bound to a node, it will never be rebound to another node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-bound-to-node-never-rebound.json"},{"id":"pod-default-dns-policy-clusterfirst","text":"The default DNS policy for pods is `ClusterFirst`; to use DNS with `hostNetwork: true`, you must explicitly set `ClusterFirstWithHostNet`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-dns-policy-clusterfirst.json"},{"id":"pod-default-dnspolicy-clusterfirst","text":"The default Pod `dnsPolicy` is `ClusterFirst`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-dnspolicy-clusterfirst.json"},{"id":"pod-default-interface-eth0-secondary-net1","text":"The default pod interface is always `eth0`; secondary network interfaces are named `net1`, `net2`, etc.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-interface-eth0-secondary-net1.json"},{"id":"pod-default-restartpolicy-always","text":"The default Pod `restartPolicy` is `Always`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-restartpolicy-always.json"},{"id":"pod-default-termination-grace-30","text":"The default `terminationGracePeriodSeconds` for a Pod is 30 seconds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-termination-grace-30.json"},{"id":"pod-default-termination-grace-period-30s","text":"The default `terminationGracePeriodSeconds` for pods is 30 seconds","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-default-termination-grace-period-30s.json"},{"id":"pod-network-name-info-metric-value-zero","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-network-name-info-metric-value-zero.json"},{"id":"pod-network-name-info-promql-join-pattern","text":"To enrich `container_network_*` metrics with network names, use `+ on(namespace,pod,interface) group_left(network_name) ( pod_network_name_info )`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-network-name-info-promql-join-pattern.json"},{"id":"pod-only-required-field-containers","text":"The only required field in PodSpec is `containers` (at least one container must be specified).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-only-required-field-containers.json"},{"id":"pod-restart-policy-default-always","text":"Default pod restart policy is `Always`; exponential back-off delay (10s, 20s, 40s) caps at 5 minutes.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-restart-policy-default-always.json"},{"id":"pod-scheduling-mechanisms","text":"Pod scheduling to nodes is controlled via node selectors, node affinity, and taints/tolerations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-scheduling-mechanisms.json"},{"id":"pod-secondary-network-annotation","text":"Pods are attached to secondary networks using the annotation `k8s.v1.cni.cncf.io/networks`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-secondary-network-annotation.json"},{"id":"pod-serviceaccount-field-deprecated","text":"The `serviceAccount` field in PodSpec is deprecated — `serviceAccountName` should be used instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-serviceaccount-field-deprecated.json"},{"id":"pod-smallest-logical-unit","text":"The Pod is the smallest logical unit in Kubernetes, containing one or more containers running on a worker node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-smallest-logical-unit.json"},{"id":"pod-static-ip-layer2-localnet-no-subnets","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pod-static-ip-layer2-localnet-no-subnets.json"},{"id":"podmetrics-container-names-match","text":"Container names in PodMetrics map directly to `pod.spec.containers[].name`; all container metrics within a pod are collected within the same time window.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmetrics-container-names-match.json"},{"id":"podmetrics-endpoints","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmetrics-endpoints.json"},{"id":"podmonitor-api-group-v1","text":"PodMonitor is a CRD from the `monitoring.coreos.com/v1` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-api-group-v1.json"},{"id":"podmonitor-auth-mutually-exclusive","text":"PodMonitor endpoint authentication options (`authorization`, `basicAuth`, `oauth2`) are mutually exclusive","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-auth-mutually-exclusive.json"},{"id":"podmonitor-bearer-token-secret-deprecated","text":"PodMonitor's `bearerTokenSecret` is deprecated; the replacement is the `authorization` field","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-bearer-token-secret-deprecated.json"},{"id":"podmonitor-default-path-metrics-scheme-http","text":"PodMonitor default scrape path is `/metrics` and default scheme is `http`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-default-path-metrics-scheme-http.json"},{"id":"podmonitor-filter-running-default-enabled","text":"PodMonitor's `filterRunning` is enabled by default, dropping non-Running pods from target discovery","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-filter-running-default-enabled.json"},{"id":"podmonitor-only-required-field-selector","text":"The only required field in PodMonitor `.spec` is `selector`, a label selector for pod discovery","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-only-required-field-selector.json"},{"id":"podmonitor-relabelings-vs-metric-relabelings","text":"In PodMonitor, `relabelings` apply to target metadata labels before scrape; `metricRelabelings` apply to scraped samples before ingestion","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-relabelings-vs-metric-relabelings.json"},{"id":"podmonitor-scrapes-pods-directly","text":"PodMonitor targets pods directly without requiring a Service, unlike ServiceMonitor which targets Services","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podmonitor-scrapes-pods-directly.json"},{"id":"podnetworkconnectivitycheck-api-group","text":"PodNetworkConnectivityCheck belongs to API group `controlplane.operator.openshift.io/v1alpha1` and has Compatibility Level 4 (no stability guarantees)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podnetworkconnectivitycheck-api-group.json"},{"id":"podnetworkconnectivitycheck-internal-api","text":"PodNetworkConnectivityCheck is an internal control plane API for cluster health monitoring, not intended for end-user application use","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podnetworkconnectivitycheck-internal-api.json"},{"id":"podnetworkconnectivitycheck-status-fields","text":"PodNetworkConnectivityCheck status tracks `successes[]`, `failures[]` (individual log entries), and `outages[]` (time periods with start/end timestamps and boundary logs)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podnetworkconnectivitycheck-status-fields.json"},{"id":"podnetworkconnectivitycheck-target-endpoint-format","text":"PodNetworkConnectivityCheck `targetEndpoint` uses `host:port` format; using an IP bypasses DNS resolution, using a DNS name causes failure if DNS resolution fails","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podnetworkconnectivitycheck-target-endpoint-format.json"},{"id":"podnetworkconnectivitycheck-tls-secret-same-namespace","text":"PodNetworkConnectivityCheck `tlsClientCert` must reference a `kubernetes.io/tls` type secret in the same namespace as the resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podnetworkconnectivitycheck-tls-secret-same-namespace.json"},{"id":"pods-are-basic-deployable-unit","text":"Pods (not containers) are the basic unit of deployment, scaling, and management in Kubernetes/OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pods-are-basic-deployable-unit.json"},{"id":"pods-immutable-expendable","text":"Pods are immutable while running (changes require recreation) and expendable (do not maintain state when recreated).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pods-immutable-expendable.json"},{"id":"pods-reference-nads-via-annotation","text":"Pods reference NetworkAttachmentDefinitions via the annotation `k8s.v1.cni.cncf.io/networks`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pods-reference-nads-via-annotation.json"},{"id":"podsecuritypolicy-review-three-variants","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podsecuritypolicy-review-three-variants.json"},{"id":"podsecuritypolicysubjectreview-allowedby-nil-means-denied","text":"In PodSecurityPolicySubjectReview, the `status.allowedBy` field references the SCC that permits the pod; when nil, the request was denied","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podsecuritypolicysubjectreview-allowedby-nil-means-denied.json"},{"id":"podsecuritypolicysubjectreview-api-group","text":"PodSecurityPolicySubjectReview belongs to the `security.openshift.io/v1` API group and is OpenShift-specific, not available in vanilla Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podsecuritypolicysubjectreview-api-group.json"},{"id":"podsecuritypolicysubjectreview-namespace-scoped","text":"PodSecurityPolicySubjectReview is a namespace-scoped resource accessed via `POST /apis/security.openshift.io/v1/namespaces/{namespace}/podsecuritypolicysubjectreviews`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podsecuritypolicysubjectreview-namespace-scoped.json"},{"id":"podsecuritypolicysubjectreview-user-no-groups","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podsecuritypolicysubjectreview-user-no-groups.json"},{"id":"podspec-containers-only-required-field","text":"The `containers` field is the only required field in a PodSpec — at least one container must be specified","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/podspec-containers-only-required-field.json"},{"id":"policygenerator-namespace-must-prefix-ztp","text":"All PolicyGenerator CRs must be in a namespace prefixed with `ztp`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/policygenerator-namespace-must-prefix-ztp.json"},{"id":"policygentemplate-deprecated-for-policygenerator","text":"PolicyGenTemplate CRs are deprecated in favor of RHACM PolicyGenerator CRs for generating Day 2 configuration policies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/policygentemplate-deprecated-for-policygenerator.json"},{"id":"policyrule-empty-apigroups-means-both","text":"In a PolicyRule, an empty `apiGroups` field means both Kubernetes and OpenShift API groups are assumed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/policyrule-empty-apigroups-means-both.json"},{"id":"policyrule-nonresourceurls-wildcard-final-segment","text":"In PolicyRules, `nonResourceURLs` supports `*` wildcards but only as the final path segment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/policyrule-nonresourceurls-wildcard-final-segment.json"},{"id":"power-metrics-categories","text":"Power consumption metrics are categorized as total, active, and idle CPU power.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-metrics-categories.json"},{"id":"power-monitor-cr-name-must-be-exact","text":"The PowerMonitor custom resource instance must be named exactly `power-monitor`; all other instance names are ignored by the operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitor-cr-name-must-be-exact.json"},{"id":"power-monitoring-container-level-granularity","text":"Power Monitoring in OCP tracks power consumption at the container level, not just node or pod level","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-container-level-granularity.json"},{"id":"power-monitoring-developer-dashboard-access","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-developer-dashboard-access.json"},{"id":"power-monitoring-install-operator-then-cr","text":"Power monitoring installation requires two steps: install the Power monitoring Operator, then deploy the PowerMonitor custom resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-install-operator-then-cr.json"},{"id":"power-monitoring-namespace","text":"Kepler is deployed in the `openshift-power-monitoring` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-namespace.json"},{"id":"power-monitoring-operator-all-namespaces","text":"The Power Monitoring Operator installation makes power monitoring available across all namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-operator-all-namespaces.json"},{"id":"power-monitoring-operator-installed","text":"Power Monitoring is an optional capability installed and managed via the Power Monitoring Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-operator-installed.json"},{"id":"power-monitoring-prereqs-dashboards","text":"Power monitoring dashboards require three prerequisites: Power Monitoring Operator installed, Kepler deployed, and user-defined project monitoring enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-prereqs-dashboards.json"},{"id":"power-monitoring-production-ready","text":"Power monitoring with Kepler provides container-level granularity power consumption tracking that is production-ready.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-production-ready.json"},{"id":"power-monitoring-requires-cluster-admin","text":"Installing, configuring, and uninstalling power monitoring requires the cluster-admin role.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-requires-cluster-admin.json"},{"id":"power-monitoring-tech-preview","text":"Power monitoring for OpenShift is Technical Preview and not supported for production use.","truth_value":"IN","justification_count":0,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-tech-preview.json"},{"id":"power-monitoring-technology-preview","text":"Power monitoring in OpenShift Container Platform is a Technology Preview feature, not supported under production SLAs and not recommended for production use.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-technology-preview.json"},{"id":"power-monitoring-technology-preview-ocp417","text":"Power monitoring using Kepler is a Technology Preview feature in OCP 4.17, not supported under production SLAs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-technology-preview-ocp417.json"},{"id":"power-monitoring-tracks-cpu-and-dram","text":"Power monitoring tracks power consumption of two specific hardware components: CPU and DRAM, at container granularity.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-tracks-cpu-and-dram.json"},{"id":"power-monitoring-two-dashboards","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-two-dashboards.json"},{"id":"power-monitoring-uninstall-order","text":"Power monitoring uninstall must follow a specific order: delete Kepler instance first, then delete PowerMonitor CR, then uninstall the Power Monitoring Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-uninstall-order.json"},{"id":"power-monitoring-uses-kepler","text":"Power monitoring for OpenShift is built on Kepler (Kubernetes-based Efficient Power Level Exporter) for collecting power consumption metrics.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-uses-kepler.json"},{"id":"power-monitoring-uses-kepler-upstream","text":"Power Monitoring is powered by Kepler (Kubernetes Efficient Power Level Exporter) as its upstream project","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/power-monitoring-uses-kepler-upstream.json"},{"id":"powermonitor-apiversion","text":"The PowerMonitor CR uses apiVersion `kepler.system.sustainable.computing.io/v1alpha1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/powermonitor-apiversion.json"},{"id":"powermonitor-must-be-named-power-monitor","text":"The PowerMonitor custom resource instance must be named `power-monitor`; all other names are rejected by the operator webhook.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/powermonitor-must-be-named-power-monitor.json"},{"id":"precache-disk-must-be-wiped-first","text":"The disk must be wiped before partitioning with `wipefs -a`; the factory-precaching-cli tool fails on non-empty disks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/precache-disk-must-be-wiped-first.json"},{"id":"precache-du-profile-flag-day2-operators","text":"The `--du-profile` flag adds Day-2 Operator images for telco 5G RAN distributed unit workloads to the pre-cache.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/precache-du-profile-flag-day2-operators.json"},{"id":"precache-parallel-workers-80pct-cpus","text":"The factory-precaching-cli default parallel download workers is 80% of available CPUs, configurable via `--parallel` / `-p`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/precache-parallel-workers-80pct-cpus.json"},{"id":"precache-partition-end-of-disk-labelled-data","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/precache-partition-end-of-disk-labelled-data.json"},{"id":"preprovisioningimage-api-group-metal3-v1alpha1","text":"The PreprovisioningImage custom resource belongs to API group `metal3.io/v1alpha1` and is a namespaced resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/preprovisioningimage-api-group-metal3-v1alpha1.json"},{"id":"preprovisioningimage-formats-iso-and-initrd","text":"PreprovisioningImage supports two image formats: `iso` and `initrd`; kernel-related fields (`kernelUrl`, `extraKernelParams`) only apply to initrd format.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/preprovisioningimage-formats-iso-and-initrd.json"},{"id":"preprovisioningimage-network-data-via-secret","text":"PreprovisioningImage injects network data via a Kubernetes Secret referenced by name in the spec field `networkDataName`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/preprovisioningimage-network-data-via-secret.json"},{"id":"preserve-images-from-pruning-by-digest-tag","text":"To preserve historical images from pruning, maintain a tag in the ImageStream spec pointing to the image by digest.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/preserve-images-from-pruning-by-digest-tag.json"},{"id":"priorityclass-integer-scheduling","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/priorityclass-integer-scheduling.json"},{"id":"priorityclass-preemption-never-queues","text":"Setting `preemptionPolicy: Never` on a PriorityClass creates high-priority pods that queue instead of evicting lower-priority pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/priorityclass-preemption-never-queues.json"},{"id":"prioritylevelconfig-default-queuing","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prioritylevelconfig-default-queuing.json"},{"id":"prioritylevelconfig-types-exempt-limited","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prioritylevelconfig-types-exempt-limited.json"},{"id":"privileged-projects-no-image-resolution","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/privileged-projects-no-image-resolution.json"},{"id":"privileged-projects-no-workloads","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/privileged-projects-no-workloads.json"},{"id":"probe-crd-api-group-v1","text":"The Probe CRD belongs to the `monitoring.coreos.com/v1` API group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-crd-api-group-v1.json"},{"id":"probe-default-prober-path-probe","text":"The Probe CRD's default prober path is `/probe`, default scheme is `http`, default auth type is `Bearer`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-default-prober-path-probe.json"},{"id":"probe-default-values","text":"Probe default values: `initialDelaySeconds=0`, `periodSeconds=10`, `timeoutSeconds=1`, `successThreshold=1`, `failureThreshold=3`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-default-values.json"},{"id":"probe-liveness-success-threshold-must-be-1","text":"The `successThreshold` parameter must be 1 for liveness probes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-liveness-success-threshold-must-be-1.json"},{"id":"probe-oauth2-required-fields","text":"Probe OAuth2 configuration requires three fields: `clientId`, `clientSecret`, and `tokenUrl`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-oauth2-required-fields.json"},{"id":"probe-prober-url-mandatory","text":"The Probe CRD's `prober.url` field is mandatory — targets cannot be probed without it","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-prober-url-mandatory.json"},{"id":"probe-startup-max-time-formula","text":"Startup probe maximum startup time is calculated as `failureThreshold × periodSeconds`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-startup-max-time-formula.json"},{"id":"probe-static-config-takes-precedence","text":"When both `staticConfig` and `ingress` targets are defined on a Probe, `staticConfig` takes precedence","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-static-config-takes-precedence.json"},{"id":"probe-three-test-mechanisms","text":"Health check probes support three test mechanisms: HTTP GET (200–399 = success), container command/exec (exit 0 = success), and TCP socket (connection established = success).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-three-test-mechanisms.json"},{"id":"probe-three-types","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-three-types.json"},{"id":"probe-two-target-types","text":"Probe supports two target types: `staticConfig` (explicit host list) and `ingress` (auto-discovery from Ingress objects via label selectors)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/probe-two-target-types.json"},{"id":"progressive-update-across-heterogeneous-fleet","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/progressive-update-across-heterogeneous-fleet.json"},{"id":"progressive-update-within-lifecycle-bounds","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/progressive-update-within-lifecycle-bounds.json"},{"id":"project-admin-cannot-change-own-quotas","text":"Project administrators cannot alter their own project quotas — only cluster administrators can modify quotas","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-admin-cannot-change-own-quotas.json"},{"id":"project-api-group-openshift-io-v1","text":"The Project and ProjectRequest resources belong to the `project.openshift.io/v1` API group, not core Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-api-group-openshift-io-v1.json"},{"id":"project-config-singleton-named-cluster","text":"The `config.openshift.io/v1 Project` resource is a cluster-wide singleton with the canonical name `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-config-singleton-named-cluster.json"},{"id":"project-config-vs-project-resource-api-groups","text":"`config.openshift.io/v1 Project` is the cluster config singleton; `project.openshift.io/v1 Project` represents individual project resources — they are distinct API groups.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-config-vs-project-resource-api-groups.json"},{"id":"project-listing-scoped-to-user-access","text":"Listing or watching projects returns only projects where the user has the reader role","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-listing-scoped-to-user-access.json"},{"id":"project-one-to-one-namespace-mapping","text":"Every OpenShift Project maps 1:1 to a Kubernetes Namespace, but not every Namespace is necessarily a Project","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-one-to-one-namespace-mapping.json"},{"id":"project-request-message-shown-when-denied","text":"The `spec.projectRequestMessage` field on the Project config controls the message shown to users who cannot create projects via the projectrequest endpoint.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-request-message-shown-when-denied.json"},{"id":"project-request-template-customizable","text":"The default project request template can be customized to inject default network policies, resource quotas, and limit ranges into every new project.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-request-template-customizable.json"},{"id":"project-request-template-in-openshift-config-ns","text":"The custom project request template referenced by the Project config must reside in the `openshift-config` namespace.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-request-template-in-openshift-config-ns.json"},{"id":"project-self-provisioning-governance","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-self-provisioning-governance.json"},{"id":"project-status-phase-active-or-terminating","text":"A Project's status phase is either `Active` (available for use) or `Terminating` (undergoing graceful termination)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-status-phase-active-or-terminating.json"},{"id":"project-three-roles-admin-edit-view","text":"Projects have three roles: admin (set membership), edit (create/manage resources), view (read-only, no container access)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-three-roles-admin-edit-view.json"},{"id":"project-watch-endpoints-deprecated","text":"The dedicated watch endpoints for Projects (`/watch/projects`) are deprecated — use the `watch` query parameter on list operations instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-watch-endpoints-deprecated.json"},{"id":"project-wraps-namespace","text":"Project (`project.openshift.io/v1`) wraps Namespace (`v1`) with additional policy in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-wraps-namespace.json"},{"id":"project-wraps-namespace-editable-by-users","text":"An OpenShift Project is an alternative representation of a Kubernetes Namespace; Projects are editable by end users while Namespaces are not","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/project-wraps-namespace-editable-by-users.json"},{"id":"projecthelmchartrepo-ca-configmap-key","text":"The CA bundle ConfigMap for `ProjectHelmChartRepository` uses the key `ca-bundle.crt`; if empty, default system roots are used.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projecthelmchartrepo-ca-configmap-key.json"},{"id":"projecthelmchartrepo-namespace-scoped","text":"`ProjectHelmChartRepository` (`helm.openshift.io/v1beta1`) is namespace-scoped, while `HelmChartRepository` is cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projecthelmchartrepo-namespace-scoped.json"},{"id":"projecthelmchartrepo-secrets-same-namespace","text":"Secrets and ConfigMaps referenced by a `ProjectHelmChartRepository` for auth, TLS, and CA must be in the same namespace as the resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projecthelmchartrepo-secrets-same-namespace.json"},{"id":"projectrequest-displayname-description-fields","text":"ProjectRequest has `displayName` and `description` fields that are OpenShift-specific metadata not present on Kubernetes Namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projectrequest-displayname-description-fields.json"},{"id":"projects-extend-namespaces","text":"OpenShift Projects extend Kubernetes namespaces with additional features including user self-provisioning, policies, constraints, and service accounts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projects-extend-namespaces.json"},{"id":"projects-fundamental-org-unit","text":"Projects are the fundamental organizational unit (namespace/tenancy boundary) for applications in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/projects-fundamental-org-unit.json"},{"id":"prometheusrule-api-group-v1","text":"PrometheusRule belongs to API group `monitoring.coreos.com/v1` and is namespace-scoped","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-api-group-v1.json"},{"id":"prometheusrule-expr-required","text":"The `expr` field (PromQL expression) is required on every PrometheusRule rule","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-expr-required.json"},{"id":"prometheusrule-for-user-defined-alerts","text":"User-defined project alerting rules use kind PrometheusRule with apiVersion monitoring.coreos.com/v1, created in the user's project namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-for-user-defined-alerts.json"},{"id":"prometheusrule-for-vs-keep-firing-for","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-for-vs-keep-firing-for.json"},{"id":"prometheusrule-group-name-required","text":"The `name` field is required on every PrometheusRule rule group","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-group-name-required.json"},{"id":"prometheusrule-limit-requires-prometheus-231","text":"PrometheusRule's `limit` field on rule groups requires Prometheus >= 2.31","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-limit-requires-prometheus-231.json"},{"id":"prometheusrule-record-or-alert-not-both","text":"A PrometheusRule rule must set exactly one of `record` or `alert`, never both","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-record-or-alert-not-both.json"},{"id":"prometheusrule-supports-both-rule-types","text":"PrometheusRule (`monitoring.coreos.com/v1`) supports both recording and alerting rules, unlike the OpenShift-specific AlertingRule which only supports alerting rules.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/prometheusrule-supports-both-rule-types.json"},{"id":"provisioning-apis-bare-metal-only","text":"Provisioning APIs (metal3.io group) are specific to bare-metal deployments and do not apply to cloud-based (AWS, Azure, GCP) or virtualized installations","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-apis-bare-metal-only.json"},{"id":"provisioning-apis-use-metal3-api-group","text":"Provisioning APIs (BareMetalHost, Provisioning, HardwareData, PreprovisioningImage, HostFirmwareSettings, FirmwareSchema) belong to the `metal3.io` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-apis-use-metal3-api-group.json"},{"id":"provisioning-consumed-by-cluster-baremetal-operator","text":"The Provisioning CR is consumed by the `cluster-baremetal-operator` to manage metal3 container lifecycle.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-consumed-by-cluster-baremetal-operator.json"},{"id":"provisioning-cr-singleton-per-cluster","text":"The Provisioning custom resource (`metal3.io/v1alpha1`) is a singleton — only one exists per cluster, named `cluster`, created automatically by the OpenShift installer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-cr-singleton-per-cluster.json"},{"id":"provisioning-default-dhcp-range-10-to-100","text":"The default provisioning DHCP range is `.10` to `.100` of the `provisioningNetworkCIDR`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-default-dhcp-range-10-to-100.json"},{"id":"provisioning-dhcp-external-deprecated","text":"The `provisioningDHCPExternal` field is deprecated in favor of the `provisioningNetwork` field on the Provisioning CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-dhcp-external-deprecated.json"},{"id":"provisioning-dhcprange-only-mutable-post-install","text":"The `provisioningDHCPRange` field is the only field on the Provisioning CR that can be changed after installation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-dhcprange-only-mutable-post-install.json"},{"id":"provisioning-ip-inside-subnet-outside-dhcp","text":"The `provisioningIP` must be within the provisioning subnet (`provisioningNetworkCIDR`) but outside the DHCP range.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-ip-inside-subnet-outside-dhcp.json"},{"id":"provisioning-ipv6-max-64-prefix","text":"IPv6 provisioning networks in Managed mode cannot exceed a /64 prefix length.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-ipv6-max-64-prefix.json"},{"id":"provisioning-network-three-modes","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-network-three-modes.json"},{"id":"provisioning-subsystem-uses-ironic","text":"The OpenShift bare metal provisioning subsystem uses Ironic under the covers for BMC communication via IPMI, Redfish, and iDRAC protocols.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-subsystem-uses-ironic.json"},{"id":"provisioning-watch-all-namespaces-default-false","text":"The Provisioning CR field `watchAllNamespaces` defaults to `false`, meaning bare metal hosts are only provisioned in the `openshift-machine-api` namespace by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/provisioning-watch-all-namespaces-default-false.json"},{"id":"proxy-empty-fields-no-env-vars","text":"Empty values for `httpProxy`, `httpsProxy`, or `noProxy` in the Proxy resource mean no corresponding environment variable is set on pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/proxy-empty-fields-no-env-vars.json"},{"id":"proxy-merged-bundle-in-openshift-config-managed","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/proxy-merged-bundle-in-openshift-config-managed.json"},{"id":"proxy-readiness-endpoints-verify-connectivity","text":"The Proxy resource's `readinessEndpoints` field is used to verify proxy connectivity before applying the configuration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/proxy-readiness-endpoints-verify-connectivity.json"},{"id":"proxy-trustedca-in-openshift-config","text":"The Proxy resource's `trustedCA` field references a ConfigMap in the `openshift-config` namespace with key `ca-bundle.crt`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/proxy-trustedca-in-openshift-config.json"},{"id":"pruner-behavior-depends-on-management-state","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pruner-behavior-depends-on-management-state.json"},{"id":"ptp-clock-health-master-offset-range","text":"PTP clock health requires `master_offset` between -100 and +100 ns, `gmPresent` must be `true`, and `portState` should be `SLAVE`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-clock-health-master-offset-range.json"},{"id":"ptp-fast-events-cloud-event-proxy","text":"PTP fast event notifications use a pub-sub REST API delivered via `cloud-event-proxy` sidecar over HTTP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-fast-events-cloud-event-proxy.json"},{"id":"ptp-gnss-requires-e810-nic","text":"GNSS timing for PTP is supported only with Intel E810 Westport Channel NICs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-gnss-requires-e810-nic.json"},{"id":"ptp-linuxptp-daemons","text":"The linuxptp package provides `ts2phc` (grandmaster), `ptp4l` (boundary/ordinary clocks), `phc2sys` (system clock to PHC sync), and `pmc` daemons.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-linuxptp-daemons.json"},{"id":"ptp-operator-bare-metal-only","text":"The PTP Operator works only on bare-metal infrastructure in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-operator-bare-metal-only.json"},{"id":"ptp-operator-namespace-openshift-ptp","text":"The PTP Operator is installed in the `openshift-ptp` namespace with label `openshift.io/cluster-monitoring: \"true\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-operator-namespace-openshift-ptp.json"},{"id":"ptp-requires-chronyd-disabled","text":"NTP/chronyd must be disabled via MachineConfig CR before enabling PTP on OpenShift nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-requires-chronyd-disabled.json"},{"id":"ptp-sub-microsecond-accuracy","text":"PTP (Precision Time Protocol) provides sub-microsecond clock accuracy using hardware support, more accurate than NTP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-sub-microsecond-accuracy.json"},{"id":"ptp-three-clock-types","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ptp-three-clock-types.json"},{"id":"publish-internal-not-supported-non-cloud","text":"`publish: Internal` is not supported on non-cloud platforms.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/publish-internal-not-supported-non-cloud.json"},{"id":"publish-internal-private-cluster","text":"Setting `publish: Internal` in `install-config.yaml` creates a private cluster inaccessible from the internet.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/publish-internal-private-cluster.json"},{"id":"pull-secret-types-docker-vs-podman","text":"Pull secret types: `kubernetes.io/dockerconfigjson` for Docker (`~/.docker/config.json`) and `kubernetes.io/podmanconfigjson` for Podman (`~/.config/containers/auth.json`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pull-secret-types-docker-vs-podman.json"},{"id":"pv-access-modes-rwo-rox-rwx-rwop","text":"OpenShift supports four PV access modes: RWO (ReadWriteOnce), ROX (ReadOnlyMany), RWX (ReadWriteMany), and RWOP (ReadWriteOncePod).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-access-modes-rwo-rox-rwx-rwop.json"},{"id":"pv-bound-to-single-pvc","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-bound-to-single-pvc.json"},{"id":"pv-cluster-scoped-pvc-namespace-scoped","text":"PersistentVolumes (PVs) are cluster-scoped resources; PersistentVolumeClaims (PVCs) are namespace/project-scoped resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-cluster-scoped-pvc-namespace-scoped.json"},{"id":"pv-expansion-failure-recovery-procedure","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-expansion-failure-recovery-procedure.json"},{"id":"pv-lifecycle-phases","text":"PV lifecycle phases are: Available → Bound → Released → Failed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-lifecycle-phases.json"},{"id":"pv-pvc-one-to-one-binding","text":"A PV bound to a PVC cannot be bound to additional PVCs — the binding is one-to-one.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-pvc-one-to-one-binding.json"},{"id":"pv-reclaim-policies-retain-recycle-delete","text":"PV reclaim policies are Retain, Recycle, and Delete — determining what happens to a PV after release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pv-reclaim-policies-retain-recycle-delete.json"},{"id":"pvc-access-modes-rwo-rox-rwx-rwop","text":"The four PV access modes are ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), and ReadWriteOncePod (RWOP).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-access-modes-rwo-rox-rwx-rwop.json"},{"id":"pvc-binding-matches-access-mode-and-size","text":"PVC binding matches on access modes and size only, selecting the smallest sufficient PV.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-binding-matches-access-mode-and-size.json"},{"id":"pvc-binds-smallest-matching-pv","text":"OCP binds PVCs to the smallest PV that matches all criteria to minimize storage waste.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-binds-smallest-matching-pv.json"},{"id":"pvc-cannot-shrink","text":"PVCs cannot be shrunk — only expanded. A smaller value in `.spec.resources.requests.storage` is rejected.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-cannot-shrink.json"},{"id":"pvc-datasourceref-more-flexible-than-datasource","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-datasourceref-more-flexible-than-datasource.json"},{"id":"pvc-default-volumemode-filesystem","text":"The default `volumeMode` for a PersistentVolumeClaim is `Filesystem` when not specified.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-default-volumemode-filesystem.json"},{"id":"pvc-is-namespaced-pv-is-cluster-scoped","text":"PersistentVolumeClaims (PVCs) are namespaced resources; PersistentVolumes (PVs) are cluster-scoped resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-is-namespaced-pv-is-cluster-scoped.json"},{"id":"pvc-three-phases","text":"A PVC has three phases: `Pending` (not yet bound), `Bound` (bound to a PV), and `Lost` (underlying PV no longer exists).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/pvc-three-phases.json"},{"id":"quay-container-security-operator-deprecated","text":"The Red Hat Quay Container Security Operator is deprecated and will be replaced by Red Hat Advanced Cluster Security (ACS) for Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/quay-container-security-operator-deprecated.json"},{"id":"quota-forces-complete-resource-declarations","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/quota-forces-complete-resource-declarations.json"},{"id":"quota-openshift-io-api-group","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/quota-openshift-io-api-group.json"},{"id":"rangeallocation-cluster-scoped-level4","text":"RangeAllocation (`security.openshift.io/v1`) is a cluster-scoped resource with Compatibility Level 4 (no stability guarantees)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rangeallocation-cluster-scoped-level4.json"},{"id":"rangeallocation-range-format","text":"RangeAllocation's `range` field uses the format `\"start-end/blockSize\"` (e.g., `\"1000000000-2000000000/10000\"`) and both `range` and `data` fields are required","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rangeallocation-range-format.json"},{"id":"rangeallocation-tracks-namespace-uid-ranges","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rangeallocation-tracks-namespace-uid-ranges.json"},{"id":"rangeallocation-tracks-uid-gid-ranges","text":"RangeAllocation is a Security API object that tracks UID/GID range assignments for namespaces in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rangeallocation-tracks-uid-gid-ranges.json"},{"id":"rbac-api-groups-k8s-and-openshift","text":"RBAC APIs live under `rbac.authorization.k8s.io/v1` (Kubernetes) and `authorization.openshift.io/v1` (OpenShift extensions).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-api-groups-k8s-and-openshift.json"},{"id":"rbac-binding-references-not-contains","text":"RoleBindings and ClusterRoleBindings reference roles but do not contain them — they are separate API objects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-binding-references-not-contains.json"},{"id":"rbac-dual-api-groups","text":"OpenShift uses both Kubernetes-native RBAC (`rbac.authorization.k8s.io`) and OpenShift-specific authorization APIs (`authorization.openshift.io`) for role-based access control.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-dual-api-groups.json"},{"id":"rbac-empty-string-core-api-group","text":"In RBAC rules, `\"\"` (empty string) represents the core API group containing pods, services, configmaps, etc.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-empty-string-core-api-group.json"},{"id":"rbac-four-core-resources","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-four-core-resources.json"},{"id":"rbac-nonresourceurls-clusterrole-only","text":"The `nonResourceURLs` field in PolicyRules only works in ClusterRoles referenced by ClusterRoleBindings, not in namespace-scoped Roles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-nonresourceurls-clusterrole-only.json"},{"id":"rbac-oc-adm-policy-commands","text":"RBAC roles are managed via `oc adm policy add-cluster-role-to-user <role> <user>` for cluster-wide and `oc adm policy add-role-to-user <role> <user> -n <namespace>` for namespace-scoped bindings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-oc-adm-policy-commands.json"},{"id":"rbac-policyrule-verbs-required","text":"In a PolicyRule, `verbs` is the only required field; valid verbs include `get`, `list`, `create`, `update`, `delete`, and `*` (all).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-policyrule-verbs-required.json"},{"id":"rbac-role-namespace-scoped","text":"Role is namespace-scoped and only grants permissions within the namespace where it is created; ClusterRole is cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-role-namespace-scoped.json"},{"id":"rbac-role-requires-binding","text":"A Role alone does nothing — it must be paired with a RoleBinding to grant permissions to subjects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-role-requires-binding.json"},{"id":"rbac-rolebinding-can-reference-clusterrole","text":"A RoleBinding can reference a ClusterRole, which grants the ClusterRole's permissions but scoped only to the RoleBinding's namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-rolebinding-can-reference-clusterrole.json"},{"id":"rbac-roleref-immutable","text":"The `roleRef` field on a RoleBinding is immutable after creation — the RoleBinding must be deleted and recreated to change the referenced role.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-roleref-immutable.json"},{"id":"rbac-subject-apigroup-defaults","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-subject-apigroup-defaults.json"},{"id":"rbac-subject-kinds","text":"The three valid subject kinds in RoleBindings/ClusterRoleBindings are User, Group, and ServiceAccount.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rbac-subject-kinds.json"},{"id":"recordtype-values","text":"`_RecordType` values are: `flowLog` (regular), `newConnection`, `heartbeat`, `endConnection` (for conversation tracking)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/recordtype-values.json"},{"id":"recreate-strategy-has-mid-hook","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/recreate-strategy-has-mid-hook.json"},{"id":"recycle-reclaim-policy-deprecated-ocp4","text":"The Recycle reclaim policy is deprecated in OpenShift Container Platform 4; dynamic provisioning is the recommended replacement.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/recycle-reclaim-policy-deprecated-ocp4.json"},{"id":"redhat-aws-ami-owner-id","text":"Red Hat's AWS account ID for AMI ownership is `309956199498`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/redhat-aws-ami-owner-id.json"},{"id":"redhat-container-registry-url","text":"Red Hat's container registry is `registry.redhat.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/redhat-container-registry-url.json"},{"id":"reference-policy-local-benefits","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/reference-policy-local-benefits.json"},{"id":"reference-policy-local-pull-through","text":"`--reference-policy=local` forces image pulls through the integrated registry, enabling pull-through from insecure registries without container runtime `--insecure` flags.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/reference-policy-local-pull-through.json"},{"id":"referencepolicy-local-enables-layer-mirroring","text":"`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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/referencepolicy-local-enables-layer-mirroring.json"},{"id":"registry-auth-uses-oauth-token","text":"Authentication to the exposed registry uses `oc whoami -t` to obtain an OAuth token, which is passed to `podman login`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-auth-uses-oauth-token.json"},{"id":"registry-auth-uses-token-not-username","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-auth-uses-token-not-username.json"},{"id":"registry-baremetal-vsphere-default-removed","text":"On bare metal and vSphere installations, the registry `managementState` defaults to `Removed` and must be changed to `Managed` with storage configured manually.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-baremetal-vsphere-default-removed.json"},{"id":"registry-ca-port-delimiter-double-dot","text":"In additional trusted CA ConfigMaps for external registries, the port delimiter is `..` (double dot) not `:` — e.g., `registry.example.com..5000`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-ca-port-delimiter-double-dot.json"},{"id":"registry-config-files-on-nodes","text":"Allowed registries are reflected in /etc/containers/policy.json; blocked registries in /etc/containers/registries.conf on cluster nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-config-files-on-nodes.json"},{"id":"registry-cr-name-cluster","text":"The Image Registry Operator custom resource is always named `cluster` — full path: `configs.imageregistry.operator.openshift.io/cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-cr-name-cluster.json"},{"id":"registry-credential-secret-name","text":"Registry storage credentials are stored in a secret named `image-registry-private-configuration-user` in the `openshift-image-registry` namespace.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-credential-secret-name.json"},{"id":"registry-custom-route-spec-fields","text":"Custom registry routes are configured in the operator CR's `spec.routes` array with fields `name`, `hostname`, and optionally `secretName` for custom TLS certificates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-custom-route-spec-fields.json"},{"id":"registry-default-route-patch-command","text":"Setting `spec.defaultRoute: true` on `configs.imageregistry.operator.openshift.io/cluster` creates a route named `default-route` in the `openshift-image-registry` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-default-route-patch-command.json"},{"id":"registry-default-route-uses-ingress-cert","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-default-route-uses-ingress-cert.json"},{"id":"registry-disable-redirect-proxies-traffic","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-disable-redirect-proxies-traffic.json"},{"id":"registry-emptydir-non-production-only","text":"The `emptyDir` storage backend for the registry is acceptable only for non-production use; data does not persist across pod restarts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-emptydir-non-production-only.json"},{"id":"registry-logs-command","text":"Registry logs are viewed with `oc logs deployments/image-registry -n openshift-image-registry`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-logs-command.json"},{"id":"registry-management-state-values","text":"The Image Registry Operator `managementState` has three values: `Managed` (actively manages), `Unmanaged` (ignores changes), and `Removed` (tears down registry and storage).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-management-state-values.json"},{"id":"registry-metrics-endpoint-path","text":"The integrated registry exposes Prometheus metrics at `/extensions/v2/metrics`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-metrics-endpoint-path.json"},{"id":"registry-not-exposed-by-default","text":"The OpenShift image registry is not exposed outside the cluster by default; external access requires explicitly creating a route.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-not-exposed-by-default.json"},{"id":"registry-operator-cr-name","text":"The Image Registry Operator manages the registry via the `configs.imageregistry.operator.openshift.io` CR; the cluster-scoped instance is named `cluster`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-operator-cr-name.json"},{"id":"registry-push-format-project-name","text":"Repository names pushed to the internal registry must use `<project>/<name>` format; deeper paths cause authentication errors.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-push-format-project-name.json"},{"id":"registry-pvc-namespace-and-annotation","text":"PVCs for the registry must be in the `openshift-image-registry` namespace with annotation `imageregistry.openshift.io: \"true\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-pvc-namespace-and-annotation.json"},{"id":"registry-redhat-io-requires-auth","text":"registry.redhat.io requires authentication; registry.access.redhat.com is the deprecated unauthenticated alternative.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-redhat-io-requires-auth.json"},{"id":"registry-s3-chunk-size-defaults","text":"The S3 storage backend default `chunkSizeMiB` is 10 MiB with a minimum of 5 MiB.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-s3-chunk-size-defaults.json"},{"id":"registry-storage-auto-config-ipi-only","text":"Registry storage is only auto-configured on installer-provisioned infrastructure (IPI) clusters on AWS, Azure, GCP, IBM, or RHOSP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-storage-auto-config-ipi-only.json"},{"id":"registry-storage-credentials-secret","text":"Custom storage credentials for the registry go in secret `image-registry-private-configuration-user` in namespace `openshift-image-registry`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-storage-credentials-secret.json"},{"id":"registry-storage-secret-keys-per-provider","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-storage-secret-keys-per-provider.json"},{"id":"registry-viewer-pull-editor-push","text":"The `registry-viewer` role grants pull access and the `registry-editor` role grants push access to the integrated image registry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/registry-viewer-pull-editor-push.json"},{"id":"release-channel-graduation-depends-on-telemetry","text":"Release channel graduation from `fast` to `stable` depends on connected cluster telemetry data about update success rates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/release-channel-graduation-depends-on-telemetry.json"},{"id":"release-images-hosted-in-quay","text":"OCP release artifacts are hosted in Quay as container images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/release-images-hosted-in-quay.json"},{"id":"remote-health-monitoring-telemetry-and-insights","text":"Remote health monitoring in OpenShift consists of two mechanisms: Telemetry (metrics/usage data) and the Insights Operator (configuration analysis and recommendations).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/remote-health-monitoring-telemetry-and-insights.json"},{"id":"remote-health-no-identifying-info","text":"Neither Telemetry nor the Insights Operator collects identifying information such as usernames, passwords, or certificates","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/remote-health-no-identifying-info.json"},{"id":"remote-health-tls-mutual-cert-auth","text":"Remote health monitoring data is encrypted using TLS with mutual certificate authentication, both in transit and at rest","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/remote-health-tls-mutual-cert-auth.json"},{"id":"remote-workers-must-use-virtual-media-not-pxe","text":"Remote worker nodes must use virtual media (not PXE) for IPI bare metal deployments, configured via virtualMediaViaExternalNetwork: true.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/remote-workers-must-use-virtual-media-not-pxe.json"},{"id":"remove-self-provisioner-prevents-project-creation","text":"Removing the `self-provisioner` ClusterRoleBinding from `system:authenticated:oauth` prevents users from creating their own projects.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/remove-self-provisioner-prevents-project-creation.json"},{"id":"replicaset-apps-v1-api-group","text":"ReplicaSets belong to the `apps/v1` API group (not `v1` or `extensions`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/replicaset-apps-v1-api-group.json"},{"id":"replicaset-replicas-default-1","text":"ReplicaSet `.spec.replicas` defaults to 1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/replicaset-replicas-default-1.json"},{"id":"replicaset-selector-required","text":"The `.spec.selector` is the only required field in a ReplicaSet spec; it must match the pod template's labels.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/replicaset-selector-required.json"},{"id":"replicationcontroller-v1-core-equality-selectors","text":"ReplicationController is a v1 core API resource that uses equality-based label selectors only, unlike ReplicaSet which supports set-based selectors.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/replicationcontroller-v1-core-equality-selectors.json"},{"id":"reserved-isolated-cpu-sets-no-overlap","text":"In workload partitioning, reserved and isolated CPU sets must not overlap, and all non-isolated CPUs must be reserved.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/reserved-isolated-cpu-sets-no-overlap.json"},{"id":"resource-field-immutability-pattern","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resource-field-immutability-pattern.json"},{"id":"resource-verbs-vs-http-verbs","text":"SubjectAccessReview resourceAttributes uses Kubernetes verbs (get, list, watch, create, update, delete, proxy); HTTP verbs are used only for nonResourceAttributes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resource-verbs-vs-http-verbs.json"},{"id":"resourceaccessreview-is-cluster-scoped","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourceaccessreview-is-cluster-scoped.json"},{"id":"resourceaccessreview-openshift-only","text":"ResourceAccessReview (returns which users/groups can perform an action) is an OpenShift-only resource with no Kubernetes equivalent.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourceaccessreview-openshift-only.json"},{"id":"resourceattributes-uses-k8s-verbs-nonresource-uses-http-verbs","text":"In LocalSubjectAccessReview, `resourceAttributes.verb` uses Kubernetes API verbs (get, list, watch, create, update, delete, proxy), while `nonResourceAttributes.verb` uses standard HTTP verbs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourceattributes-uses-k8s-verbs-nonresource-uses-http-verbs.json"},{"id":"resourcequota-limits-aggregate-per-namespace","text":"ResourceQuota limits aggregate resource consumption per namespace in OpenShift/Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourcequota-limits-aggregate-per-namespace.json"},{"id":"resourcequota-limits-compute-objects-storage","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourcequota-limits-compute-objects-storage.json"},{"id":"resourcequota-namespace-scoped","text":"ResourceQuota is a namespace-scoped Kubernetes API object (core v1) that enforces aggregate resource consumption limits within a single namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourcequota-namespace-scoped.json"},{"id":"resourcequota-scopes","text":"ResourceQuota scopes include BestEffort, NotBestEffort, Terminating (activeDeadlineSeconds >= 0), NotTerminating (activeDeadlineSeconds is nil), PriorityClass, and CrossNamespacePodAffinity; scope selectors use AND logic.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/resourcequota-scopes.json"},{"id":"restricted-v2-more-restrictive-than-restricted","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/restricted-v2-more-restrictive-than-restricted.json"},{"id":"revision-limit-minus-one-unlimited","text":"Setting static pod operator revision limits to -1 enables unlimited revision retention","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/revision-limit-minus-one-unlimited.json"},{"id":"rh-marketplace-admin-launches-instances-via-crds","text":"Administrators can launch Marketplace application instances by browsing CRDs in the Installed Operators list.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rh-marketplace-admin-launches-instances-via-crds.json"},{"id":"rh-marketplace-developer-perspective-no-operator-install","text":"The Developer perspective in OCP does not include Operator installation or usage tracking — those are Administrator-only functions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rh-marketplace-developer-perspective-no-operator-install.json"},{"id":"rh-marketplace-operator-three-functions","text":"The Red Hat Marketplace Operator performs three functions: updates image registry secrets, manages the catalog, and reports application usage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rh-marketplace-operator-three-functions.json"},{"id":"rhacm-hub-validated-3500-sno-clusters","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhacm-hub-validated-3500-sno-clusters.json"},{"id":"rhcos-custom-layering-verified","text":"RHCOS custom image layering is verified and operational when rpm-ostree status confirms deployment.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-custom-layering-verified.json"},{"id":"rhcos-default-ssh-user-core","text":"The default SSH username for RHCOS (Red Hat Enterprise Linux CoreOS) nodes is `core`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-default-ssh-user-core.json"},{"id":"rhcos-default-user-core","text":"The default user on RHCOS is `core`, with SSH key injected via Ignition.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-default-user-core.json"},{"id":"rhcos-fs-changes-not-preserved","text":"RHCOS filesystem modifications are not preserved across minor releases unless made through a supported Operator (MCO, Node Tuning Operator).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-fs-changes-not-preserved.json"},{"id":"rhcos-image-layering-production-ready","text":"RHCOS custom image layering via rpm-ostree is production-ready on the immutable node model.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-image-layering-production-ready.json"},{"id":"rhcos-immutable-container-os","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-immutable-container-os.json"},{"id":"rhcos-immutable-update-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":3,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-immutable-update-model.json"},{"id":"rhcos-nodes-immutable","text":"RHCOS nodes are immutable — changes are applied via Operators, not SSH. SSH is a last resort when API/kubelet is down.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-nodes-immutable.json"},{"id":"rhcos-only-supported-os-control-plane","text":"RHCOS is the only supported operating system for control plane nodes in OpenShift Container Platform 4.x; workers can optionally run RHEL.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-only-supported-os-control-plane.json"},{"id":"rhcos-qcow2-not-supported-for-ztp","text":"QCOW2 images are not supported for ZTP; RHCOS images must match or be less than or equal to the OCP version being installed.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-qcow2-not-supported-for-ztp.json"},{"id":"rhcos-rpm-ostree-updates","text":"RHCOS uses rpm-ostree for atomic in-place OS updates, with OS updates delivered as bootable container images","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-rpm-ostree-updates.json"},{"id":"rhcos-ssh-core-user","text":"SSH access to RHCOS nodes uses the `core` user: `ssh core@<node>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-ssh-core-user.json"},{"id":"rhcos-usr-readonly","text":"On RHCOS, `/usr` is read-only; `/etc`, `/boot`, and `/var` are writable but intended to be changed only by the MCO.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhcos-usr-readonly.json"},{"id":"rhel-compute-nodes-deprecated-ocp-416","text":"RHEL compute nodes are deprecated as of OpenShift Container Platform 4.16 and will be removed in a future release.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-compute-nodes-deprecated-ocp-416.json"},{"id":"rhel-trusted-ca-path","text":"The trusted CA certificate path on RHEL is `/etc/pki/ca-trust/source/anchors/`, updated with `sudo update-ca-trust enable`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-trusted-ca-path.json"},{"id":"rhel-worker-csr-approval-two-rounds","text":"Adding RHEL workers requires two rounds of CSR approval (client CSRs first, then server CSRs) within 1 hour before certificates rotate.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-csr-approval-two-rounds.json"},{"id":"rhel-worker-csr-one-hour-deadline","text":"CSRs for new worker nodes must be approved within one hour before certificate rotation creates additional certificates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-csr-one-hour-deadline.json"},{"id":"rhel-worker-csr-two-rounds-approval","text":"Adding RHEL workers requires two rounds of CSR approval: first client CSRs (from `node-bootstrapper`), then server/serving CSRs (from `system:node:*`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-csr-two-rounds-approval.json"},{"id":"rhel-worker-fast-datapath-repo-required","text":"RHEL compute nodes require the `fast-datapath-for-rhel-8-x86_64-rpms` repo, but the playbook machine does not.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-fast-datapath-repo-required.json"},{"id":"rhel-worker-firewalld-must-be-disabled","text":"firewalld must be permanently disabled on RHEL worker nodes; re-enabling it breaks log access.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-firewalld-must-be-disabled.json"},{"id":"rhel-worker-four-repos-required","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-four-repos-required.json"},{"id":"rhel-worker-manual-api-update","text":"RHEL worker nodes require manual OpenShift API update before the MCO can update the kubelet on those machines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-manual-api-update.json"},{"id":"rhel-worker-min-version-8-8","text":"RHEL compute nodes require RHEL 8.8 or later; RHEL 7 is not supported and RHEL 7 nodes must be replaced, not upgraded.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-min-version-8-8.json"},{"id":"rhel-worker-minimum-version-8-8","text":"RHEL 7 is not supported for OCP 4.17 worker nodes; minimum is RHEL 8.8.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-minimum-version-8-8.json"},{"id":"rhel-worker-package-based-deprecated","text":"Package-based RHEL compute worker support is deprecated and will be replaced by RHCOS image layering.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-package-based-deprecated.json"},{"id":"rhel-worker-scaleup-playbook-path","text":"The Ansible scaleup playbook for adding RHEL workers is at `/usr/share/ansible/openshift-ansible/playbooks/scaleup.yml`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-scaleup-playbook-path.json"},{"id":"rhel-worker-swap-disabled","text":"Swap memory is disabled on all RHEL compute machines and cannot be re-enabled.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-worker-swap-disabled.json"},{"id":"rhel-workers-control-plane-must-be-rhcos","text":"Control plane nodes must be RHCOS; only compute/worker nodes can be RHEL.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-workers-control-plane-must-be-rhcos.json"},{"id":"rhel-workers-deprecated-for-image-layering","text":"Package-based RHEL compute nodes are deprecated in favor of RHCOS image layering.","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-workers-deprecated-for-image-layering.json"},{"id":"rhel-workers-only-not-control-plane","text":"RHEL can only be used for compute (worker) nodes, never for control plane nodes; control plane must run RHCOS.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-workers-only-not-control-plane.json"},{"id":"rhel-workers-x86-64-only","text":"RHEL compute machines are supported only on x86_64 architecture in OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel-workers-x86-64-only.json"},{"id":"rhel7-workers-no-inplace-update","text":"RHEL 7 workers cannot be updated in-place during cluster updates — they must be replaced with RHEL 8 or RHCOS workers","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhel7-workers-no-inplace-update.json"},{"id":"rhoai-distributed-workloads-gpu-autoscaling","text":"OpenShift AI distributed workloads support GPU-aware auto-scaling for distributing data processing and training jobs across GPUs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-distributed-workloads-gpu-autoscaling.json"},{"id":"rhoai-feature-store-reusable-ml-features","text":"OpenShift AI Feature Store defines, stores, and serves reusable ML features to models across both training and serving pipelines.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-feature-store-reusable-ml-features.json"},{"id":"rhoai-guardrails-safety-layer","text":"Guardrails is the OpenShift AI safety mechanism for filtering model input and output on deployed models.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-guardrails-safety-layer.json"},{"id":"rhoai-install-modes-connected-disconnected","text":"OpenShift AI Self-Managed supports two installation modes: standard (connected) and disconnected (air-gapped) environment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-install-modes-connected-disconnected.json"},{"id":"rhoai-llamastack-openai-compatible-rag","text":"The LlamaStack operator in OpenShift AI enables OpenAI-compatible RAG APIs, integrating with vLLM and vector stores.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-llamastack-openai-compatible-rag.json"},{"id":"rhoai-lmeval-evaluation-framework","text":"LM-Eval is the OpenShift AI evaluation framework, configured via LMEvalJob CRDs for benchmarking model performance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-lmeval-evaluation-framework.json"},{"id":"rhoai-model-registry-rbac-groups","text":"The OpenShift AI Model Registry provides cross-project model sharing with RBAC group-based access control and version lifecycle management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-model-registry-rbac-groups.json"},{"id":"rhoai-model-serving-kserve-two-modes","text":"OpenShift AI model serving uses KServe with two deployment modes: RawDeployment and Knative.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-model-serving-kserve-two-modes.json"},{"id":"rhoai-no-upgrade-2x-to-3x","text":"There is no upgrade path from Red Hat OpenShift AI 2.x to 3.x; a fresh installation is required.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-no-upgrade-2x-to-3x.json"},{"id":"rhoai-pipelines-kfp-based","text":"OpenShift AI pipelines are based on Kubeflow Pipelines (KFP) with S3-compatible artifact storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-pipelines-kfp-based.json"},{"id":"rhoai-runs-as-operator-on-ocp","text":"Red Hat OpenShift AI Self-Managed runs as an operator on OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-runs-as-operator-on-ocp.json"},{"id":"rhoai-telemetry-admin-controllable","text":"OpenShift AI telemetry (usage data collection) can be enabled or disabled by administrators.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoai-telemetry-admin-controllable.json"},{"id":"rhoso-compact-topology-default","text":"RHOSO default topology is \"compact\" where RHOSO and RHOCP control planes share the same physical nodes on a 3-node compact cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-compact-topology-default.json"},{"id":"rhoso-control-plane-runs-on-rhocp","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-control-plane-runs-on-rhocp.json"},{"id":"rhoso-controlplane-crd-apiversion","text":"The `OpenStackControlPlane` CRD uses apiVersion `core.openstack.org/v1beta1`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-controlplane-crd-apiversion.json"},{"id":"rhoso-data-plane-ansible-automation","text":"RHOSO data plane RHEL nodes are configured via Ansible automation execution environments run by the OpenStack Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-data-plane-ansible-automation.json"},{"id":"rhoso-disabled-services-default","text":"RHOSO services disabled by default: ironic, horizon, designate, octavia, heat, and manila.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-disabled-services-default.json"},{"id":"rhoso-disconnected-deployment-supported","text":"RHOSO 18.0 supports disconnected (air-gapped) deployment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-disconnected-deployment-supported.json"},{"id":"rhoso-follows-platform-operator-pattern","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-follows-platform-operator-pattern.json"},{"id":"rhoso-multiple-environments-single-cluster","text":"Multiple RHOSO environments can coexist on a single RHOCP cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-multiple-environments-single-cluster.json"},{"id":"rhoso-nfs-below-v4-not-supported","text":"NFS versions earlier than 4 are not supported across RHOSO services (Cinder, Nova, Glance).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-nfs-below-v4-not-supported.json"},{"id":"rhoso-only-x86-64-supported","text":"RHOSO supports only x86_64 architecture for RHOCP master and worker nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-only-x86-64-supported.json"},{"id":"rhoso-openstack-operator-master-operator","text":"The `openstack-operator` is the single master operator installed via OperatorHub that installs and manages all individual RHOSO service operators.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-openstack-operator-master-operator.json"},{"id":"rhoso-requires-rhocp-418","text":"RHOSO 18.0 requires RHOCP 4.18 as the hosting platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-requires-rhocp-418.json"},{"id":"rhoso-succeeds-director-tripleo","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rhoso-succeeds-director-tripleo.json"},{"id":"rocminfo-amd-gpu-diagnostic","text":"`rocminfo` is the diagnostic command for verifying AMD GPU detection in OpenShift (analogous to `nvidia-smi` for NVIDIA).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rocminfo-amd-gpu-diagnostic.json"},{"id":"role-apis-authorization-openshift-io-v1","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/role-apis-authorization-openshift-io-v1.json"},{"id":"role-apis-compatibility-level-1","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/role-apis-compatibility-level-1.json"},{"id":"role-namespace-scoped-clusterrole-cluster-scoped","text":"Role is namespace-scoped while ClusterRole is cluster-scoped; RoleBinding is namespace-scoped while ClusterRoleBinding is cluster-scoped.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/role-namespace-scoped-clusterrole-cluster-scoped.json"},{"id":"role-rules-field-required","text":"A Role object requires the `rules` field, which is an array of PolicyRule objects; each PolicyRule requires `verbs` and `resources` fields.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/role-rules-field-required.json"},{"id":"rolebinding-can-reference-clusterrole","text":"A namespaced RoleBinding can reference a ClusterRole, granting its permissions only within the RoleBinding's namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebinding-can-reference-clusterrole.json"},{"id":"rolebinding-clusterrole-namespace-scoped","text":"A RoleBinding referencing a ClusterRole grants those ClusterRole permissions only within the RoleBinding's namespace, not cluster-wide.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebinding-clusterrole-namespace-scoped.json"},{"id":"rolebinding-master-namespace-exception","text":"RoleBindings only have effect in the namespace where they exist, except in the master namespace which has power across all namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebinding-master-namespace-exception.json"},{"id":"rolebinding-references-role-not-embeds","text":"A RoleBinding references a Role via `roleRef` — it does not contain or embed the Role. Required fields are `subjects` and `roleRef`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebinding-references-role-not-embeds.json"},{"id":"rolebinding-usernames-groupnames-legacy","text":"The `userNames` and `groupNames` fields on RoleBinding are legacy backward-compatibility fields; modern clients should use the `subjects` field exclusively.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebinding-usernames-groupnames-legacy.json"},{"id":"rolebindingrestriction-openshift-specific","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebindingrestriction-openshift-specific.json"},{"id":"rolebindingrestriction-permissive-or-matching","text":"RoleBindingRestriction uses permissive/OR matching: if any RoleBindingRestriction in a namespace matches a subject, rolebindings for that subject are allowed.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebindingrestriction-permissive-or-matching.json"},{"id":"rolebindingrestriction-three-subject-types","text":"RoleBindingRestriction supports three restriction types: `userrestriction`, `grouprestriction`, and `serviceaccountrestriction`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolebindingrestriction-three-subject-types.json"},{"id":"rolling-default-deployment-strategy","text":"Rolling is the default deployment strategy for DeploymentConfig, providing zero-downtime deployments.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rolling-default-deployment-strategy.json"},{"id":"rollout-undo-disables-image-triggers","text":"`oc rollout undo dc/<name>` reverts to the last successful revision and disables image change triggers; they must be re-enabled with `oc set triggers dc/<name> --auto`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rollout-undo-disables-image-triggers.json"},{"id":"rootless-dpdk-requires-vhostnet-tap-selinux","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rootless-dpdk-requires-vhostnet-tap-selinux.json"},{"id":"rosa-classic-protected-managed-resources","text":"ROSA Classic has protected/managed resources that are managed exclusively by Red Hat SRE and cannot be modified by customers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-classic-protected-managed-resources.json"},{"id":"rosa-classic-uses-aws-sts","text":"ROSA Classic uses AWS Secure Token Service (STS) for its deployment workflow with short-lived credentials.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-classic-uses-aws-sts.json"},{"id":"rosa-cli-tools-rosa-and-oc","text":"ROSA is managed via two CLI tools (ROSA CLI and oc CLI) plus the OpenShift Cluster Manager (OCM) web UI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-cli-tools-rosa-and-oc.json"},{"id":"rosa-create-network-uses-cloudformation","text":"The `rosa create network` command wraps AWS CloudFormation for VPC infrastructure provisioning and requires ROSA CLI v1.2.48+.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-create-network-uses-cloudformation.json"},{"id":"rosa-default-cidr-ranges","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-default-cidr-ranges.json"},{"id":"rosa-default-compute-m5xlarge-2-nodes","text":"ROSA HCP default compute configuration is 2x `m5.xlarge` instances (4 vCPU, 16 GiB RAM) with no autoscaling.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-default-compute-m5xlarge-2-nodes.json"},{"id":"rosa-default-storage-class-gp3-csi","text":"ROSA HCP default storage class is `gp3-csi` using the `ebs.csi.aws.com` provisioner with 300 GiB GP3 node volumes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-default-storage-class-gp3-csi.json"},{"id":"rosa-hcp-control-plane-in-redhat-account","text":"ROSA HCP (hosted control planes) runs the control plane in Red Hat's AWS account, not the customer's.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-hcp-control-plane-in-redhat-account.json"},{"id":"rosa-logging-not-installed-by-default","text":"The ROSA logging subsystem is not installed by default — it must be added and can forward logs to external services.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-logging-not-installed-by-default.json"},{"id":"rosa-network-plugin-ovn-kubernetes","text":"ROSA uses OVN-Kubernetes as its network plugin (both HCP and classic architectures).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-network-plugin-ovn-kubernetes.json"},{"id":"rosa-requires-three-clis","text":"ROSA installation requires three CLI tools: `aws` CLI, `rosa` CLI, and `oc` (OpenShift client).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-requires-three-clis.json"},{"id":"rosa-reserved-ip-172-20-0-1","text":"The IP address `172.20.0.1` is reserved for the internal Kubernetes API in ROSA and CIDRs must not conflict with it.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-reserved-ip-172-20-0-1.json"},{"id":"rosa-shared-responsibility-three-parties","text":"ROSA follows a shared responsibility model split between Red Hat, AWS, and the customer.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-shared-responsibility-three-parties.json"},{"id":"rosa-subnet-tagging-requirements","text":"ROSA requires public subnets tagged with `kubernetes.io/role/elb` and private subnets tagged with `kubernetes.io/role/internal-elb`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-subnet-tagging-requirements.json"},{"id":"rosa-supports-aws-govcloud","text":"ROSA supports deployment into AWS GovCloud regions for government workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-supports-aws-govcloud.json"},{"id":"rosa-two-architectures-hcp-and-classic","text":"ROSA has two deployment architectures: default (Hosted Control Planes/HCP) and classic, each with separate documentation sets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rosa-two-architectures-hcp-and-classic.json"},{"id":"route-api-group","text":"Route is under `route.openshift.io/v1` — OpenShift's native ingress mechanism, distinct from Kubernetes Ingress (`networking.k8s.io/v1`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-api-group.json"},{"id":"route-api-version","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-api-version.json"},{"id":"route-backend-weights","text":"Route backend weights range 0–256 (default 100); weight 0 suppresses traffic; all-zero weights return 503","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-backend-weights.json"},{"id":"route-destination-ca-cert-reencrypt","text":"The `destinationCACertificate` field is used with reencrypt termination for validating the backend's certificate during health checks","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-destination-ca-cert-reencrypt.json"},{"id":"route-header-action-limits","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-header-action-limits.json"},{"id":"route-header-action-precedence","text":"Route request header actions execute after IngressController actions; Route response header actions execute before IngressController actions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-header-action-precedence.json"},{"id":"route-host-immutable","text":"A Route's `host` field cannot be changed after creation; routers resolve host conflicts by preferring the oldest route","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-host-immutable.json"},{"id":"route-host-immutable-after-creation","text":"OpenShift Route `host` field is immutable after creation; oldest route wins on host conflicts","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-host-immutable-after-creation.json"},{"id":"route-hostname-pattern","text":"Route hostname pattern is `<route-name>.<route-namespace>.<domain>` based on the Ingress config `spec.domain`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-hostname-pattern.json"},{"id":"route-http2-requires-custom-cert","text":"HTTP/2 ALPN on OpenShift Routes requires a custom (non-wildcard) certificate — not supported with the default ingress certificate","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-http2-requires-custom-cert.json"},{"id":"route-insecure-edge-termination-default","text":"Route `insecureEdgeTerminationPolicy` defaults to `None`; options are `None`, `Allow`, and `Redirect`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-insecure-edge-termination-default.json"},{"id":"route-max-four-backends","text":"A Route supports maximum 4 backends total: 1 primary (`spec.to`) plus up to 3 alternate backends (`spec.alternateBackends`), all must be Services","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-max-four-backends.json"},{"id":"route-openshift-ingress-kubernetes","text":"Route is OpenShift-specific; Ingress is the Kubernetes-native equivalent.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-openshift-ingress-kubernetes.json"},{"id":"route-passthrough-no-header-actions","text":"Passthrough routes are incompatible with HTTP header actions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-passthrough-no-header-actions.json"},{"id":"route-tls-termination-types","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/route-tls-termination-types.json"},{"id":"routing-via-host-disables-offload","text":"Setting routingViaHost to true causes pod egress to exit via ovn-k8s-mp0 into the host stack and disables hardware offload","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/routing-via-host-disables-offload.json"},{"id":"rpm-ostree-atomic-upgrades","text":"rpm-ostree delivers transactional, atomic OS upgrades via container images with single-reboot rollback capability.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rpm-ostree-atomic-upgrades.json"},{"id":"rukpak-tech-preview-ocp417","text":"RukPak is Tech Preview (not GA) in OCP 4.17, representing the next-gen OLM packaging component using the `BundleDeployment` API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/rukpak-tech-preview-ocp417.json"},{"id":"runtime-operations-fully-observable-within-governance","text":"The complete runtime operations stack (networking + observability + autoscaling + resource management) is fully observable within governance only when all observability components reach GA — currently power monitoring and eBPF flow management remain tech preview, creating blind spots in the otherwise governed runtime model","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtime-operations-fully-observable-within-governance.json"},{"id":"runtime-operations-require-integrated-networking-and-resource-governance","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtime-operations-require-integrated-networking-and-resource-governance.json"},{"id":"runtimeclass-api-group-node-k8s-io-v1","text":"RuntimeClass uses API group `node.k8s.io/v1` and is a cluster-scoped resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtimeclass-api-group-node-k8s-io-v1.json"},{"id":"runtimeclass-handler-required-immutable-lowercase","text":"RuntimeClass `handler` field is required, immutable once set, and must be a lowercase DNS label conforming to RFC 1123.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtimeclass-handler-required-immutable-lowercase.json"},{"id":"runtimeclass-manually-defined","text":"RuntimeClass resources are manually defined by users or cluster provisioners — they are not auto-discovered.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtimeclass-manually-defined.json"},{"id":"runtimeclass-scheduling-nodeselector-merged","text":"RuntimeClass `scheduling.nodeSelector` is merged with the pod's existing nodeSelector during admission; conflicts cause admission rejection.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtimeclass-scheduling-nodeselector-merged.json"},{"id":"runtimeclass-tolerations-appended","text":"RuntimeClass `scheduling.tolerations` are appended (not replaced) to the pod's tolerations during admission, excluding duplicates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/runtimeclass-tolerations-appended.json"},{"id":"s2i-build-steps-order","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-build-steps-order.json"},{"id":"s2i-buildah-creates-final-image","text":"Buildah is the tool that creates the final container image after S2I completes its build steps.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-buildah-creates-final-image.json"},{"id":"s2i-builder-tilde-syntax","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-builder-tilde-syntax.json"},{"id":"s2i-custom-scripts-directory","text":"Custom S2I scripts are placed in the `.s2i/bin/` directory of the application source (e.g., `.s2i/bin/assemble`, `.s2i/bin/run`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-custom-scripts-directory.json"},{"id":"s2i-images-developer-catalog","text":"Source-to-Image (S2I) runtime base images are accessible from the Developer perspective via +Add → Developer Catalog.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-images-developer-catalog.json"},{"id":"s2i-recommended-default-strategy","text":"Source-to-Image (S2I) is the recommended default build strategy — it produces consistent images without requiring a Dockerfile.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-recommended-default-strategy.json"},{"id":"s2i-required-scripts","text":"The two required S2I scripts are `assemble` (build the app) and `run` (execute the app)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-required-scripts.json"},{"id":"s2i-run-wrapper-must-use-exec","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-run-wrapper-must-use-exec.json"},{"id":"s2i-script-search-order","text":"S2I script search order: (1) build config, (2) .s2i/bin in application source, (3) io.openshift.s2i.scripts-url label on builder image","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-script-search-order.json"},{"id":"s2i-scripts-url-label","text":"The S2I scripts location is stored in the `io.openshift.s2i.scripts-url` label on the builder image (typically `image:///usr/libexec/s2i`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/s2i-scripts-url-label.json"},{"id":"sa-automount-token-pod-overrides-sa","text":"`automountServiceAccountToken: false` on a ServiceAccount disables automatic token mounting, but pod-level settings override SA-level settings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-automount-token-pod-overrides-sa.json"},{"id":"sa-enforce-mountable-secrets-annotation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-enforce-mountable-secrets-annotation.json"},{"id":"sa-imagepullsecrets-used-by-kubelet","text":"ServiceAccount `imagePullSecrets` are accessed by the kubelet (not the pod) for pulling container images and are not mountable into pods.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-imagepullsecrets-used-by-kubelet.json"},{"id":"sa-issuer-trust-24h-default-expiration","text":"Service account issuer trust has a 24-hour default expiration for previously-used issuers in the KubeAPIServer resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-issuer-trust-24h-default-expiration.json"},{"id":"sa-namespace-scoped-resource","text":"ServiceAccounts are namespace-scoped resources accessed via `/api/v1/namespaces/{namespace}/serviceaccounts`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-namespace-scoped-resource.json"},{"id":"sa-tokenrequest-api-recommended-for-external-tokens","text":"The recommended way to obtain ServiceAccount tokens for use outside pods is the TokenRequest API, not auto-generated SA token secrets.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sa-tokenrequest-api-recommended-for-external-tokens.json"},{"id":"samples-operator-architecture-change-requires-removed","text":"To change the Cluster Samples Operator architecture, you must set state to Removed first, then change architecture and set back to Managed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-architecture-change-requires-removed.json"},{"id":"samples-operator-bootstrap-removed-conditions","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-bootstrap-removed-conditions.json"},{"id":"samples-operator-config-resource","text":"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`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-config-resource.json"},{"id":"samples-operator-default-managed","text":"The Cluster Samples Operator default management state is Managed and default registry is registry.redhat.io","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-default-managed.json"},{"id":"samples-operator-default-registry","text":"The Samples Operator default registry for sample ImageStreams is `registry.redhat.io`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-default-registry.json"},{"id":"samples-operator-imagestreamtag-to-image-configmap","text":"The `imagestreamtag-to-image` config map in `openshift-cluster-samples-operator` namespace maps imagestream tags to image references for mirroring guidance","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-imagestreamtag-to-image-configmap.json"},{"id":"samples-operator-import-retry-15min","text":"Failed image stream tag imports are retried every ~15 minutes; failing-import alerts start 2 hours after installation when state is Managed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-import-retry-15min.json"},{"id":"samples-operator-manages-openshift-namespace","text":"The Samples Operator manages sample ImageStreams and Templates in the `openshift` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-manages-openshift-namespace.json"},{"id":"samples-operator-removed-deletes-all","text":"Setting the Samples Operator `managementState: Removed` causes it to delete all managed ImageStreams, Templates, and the registry secret.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-removed-deletes-all.json"},{"id":"samples-operator-skipped-requires-manual-delete","text":"Using `skippedImagestreams`/`skippedTemplates` in the Samples Operator prevents recreation but does not delete existing resources — admins must manually delete them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-skipped-requires-manual-delete.json"},{"id":"samples-operator-supported-architectures","text":"The Samples Operator supports three architectures: `x86_64`, `ppc64le`, and `s390x`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-supported-architectures.json"},{"id":"samples-operator-three-management-states","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/samples-operator-three-management-states.json"},{"id":"sandboxed-containers-kata-runtime","text":"OpenShift sandboxed containers use Kata Containers to run pods inside lightweight VMs, providing hardware-virtualization-based isolation stronger than namespace/cgroup isolation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-containers-kata-runtime.json"},{"id":"sandboxed-containers-operator-kataconfig","text":"OpenShift sandboxed containers are deployed via the OpenShift sandboxed containers Operator, and the `KataConfig` CR triggers deployment of the Kata runtime on selected nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-containers-operator-kataconfig.json"},{"id":"sandboxed-containers-runtimeclass-kata","text":"Workloads opt into OpenShift sandboxed containers by setting `runtimeClassName: kata` in the pod spec.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-containers-runtimeclass-kata.json"},{"id":"sandboxed-containers-uses-kata-runtime","text":"OpenShift sandboxed containers use Kata Containers as the underlying runtime technology for workload isolation beyond standard container boundaries.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-containers-uses-kata-runtime.json"},{"id":"sandboxed-containers-versioned-separately","text":"OpenShift sandboxed containers is versioned separately from core OCP (e.g., version 1.11).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-containers-versioned-separately.json"},{"id":"sandboxed-vs-kubevirt-distinction","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sandboxed-vs-kubevirt-distinction.json"},{"id":"sar-empty-namespace-means-all","text":"Empty string for `namespace` in SubjectAccessReview resourceAttributes means \"all namespaces\" for namespace-scoped resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sar-empty-namespace-means-all.json"},{"id":"sar-spec-requires-one-of-resource-or-nonresource","text":"SubjectAccessReview spec must contain exactly one of `resourceAttributes` or `nonResourceAttributes`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sar-spec-requires-one-of-resource-or-nonresource.json"},{"id":"scale-machineset-command","text":"The command to scale a MachineSet is `oc scale --replicas=<n> machinesets.machine.openshift.io <name> -n openshift-machine-api`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scale-machineset-command.json"},{"id":"scale-subresource-autoscaling-v1","text":"The Scale subresource is part of `autoscaling/v1` and is accessed via `/{resource-name}/scale` — not a top-level API object","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scale-subresource-autoscaling-v1.json"},{"id":"scale-subresource-four-resource-types","text":"Four resource types support the Scale subresource: Deployment, ReplicaSet, StatefulSet, and ReplicationController","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scale-subresource-four-resource-types.json"},{"id":"scc-allow-privilege-escalation-defaults-true","text":"`allowPrivilegeEscalation` in an SCC defaults to `true` if unset.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-allow-privilege-escalation-defaults-true.json"},{"id":"scc-api-group-security-openshift","text":"SecurityContextConstraints (SCC) is under the `security.openshift.io/v1` API group — OpenShift-specific, not standard Kubernetes.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-api-group-security-openshift.json"},{"id":"scc-api-group-security-openshift-io","text":"SecurityContextConstraints (SCCs) belong to the `security.openshift.io` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-api-group-security-openshift-io.json"},{"id":"scc-api-group-security-openshift-io-v1","text":"SecurityContextConstraints use the API group `security.openshift.io/v1`; the old core Kubernetes API group exposure is deprecated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-api-group-security-openshift-io-v1.json"},{"id":"scc-cluster-scoped-resource","text":"SecurityContextConstraints (SCCs) are cluster-scoped resources, not namespaced.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-cluster-scoped-resource.json"},{"id":"scc-grant-command-oc-adm-policy","text":"SCCs are granted to users/service accounts via `oc adm policy add-scc-to-user <scc-name> -z <service-account>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-grant-command-oc-adm-policy.json"},{"id":"scc-migrating-to-security-openshift-io","text":"SCC is migrating from the core API group to `security.openshift.io`; the core API group exposure is deprecated","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-migrating-to-security-openshift-io.json"},{"id":"scc-openshift-specific-compatibility-level1","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-openshift-specific-compatibility-level1.json"},{"id":"scc-primary-openshift-security-api","text":"SecurityContextConstraints (SCCs) are the primary OpenShift-specific security API object, controlling what a pod can and cannot do.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-primary-openshift-security-api.json"},{"id":"scc-priority-higher-first","text":"SCC priority field determines evaluation order: higher priority SCCs are tried first; ties are broken by most-restrictive-first, then by name.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-priority-higher-first.json"},{"id":"scc-replaces-psp","text":"SecurityContextConstraints (SCCs) are OpenShift-specific security controls with no direct Kubernetes equivalent; PodSecurityPolicies are deprecated.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-replaces-psp.json"},{"id":"scc-required-drop-capabilities-cannot-readd","text":"Capabilities listed in `requiredDropCapabilities` are always dropped and cannot be re-added via `allowedCapabilities`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-required-drop-capabilities-cannot-readd.json"},{"id":"scc-seven-required-boolean-fields","text":"SCCs have seven required boolean fields: `allowHostDirVolumePlugin`, `allowHostIPC`, `allowHostNetwork`, `allowHostPID`, `allowHostPorts`, `allowPrivilegedContainer`, `readOnlyRootFilesystem`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-seven-required-boolean-fields.json"},{"id":"scc-volume-whitelist-star-all-none-none","text":"SCC `volumes` field uses `\"*\"` to allow all volume types and `[\"none\"]` to allow none.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scc-volume-whitelist-star-all-none-none.json"},{"id":"scheduled-reimport-flag","text":"`oc tag <source> <stream>:<tag> --scheduled=true` enables periodic re-import of a tag from an external registry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduled-reimport-flag.json"},{"id":"scheduler-config-vs-operator-api","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-config-vs-operator-api.json"},{"id":"scheduler-default-node-selector-intersection","text":"The Scheduler resource's `defaultNodeSelector` creates an intersection with existing pod nodeSelectors (constrains further, does not replace).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-default-node-selector-intersection.json"},{"id":"scheduler-default-profile-low-node-utilization","text":"The default OpenShift scheduler profile is `LowNodeUtilization`, which spreads pods evenly across nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-default-profile-low-node-utilization.json"},{"id":"scheduler-masters-not-schedulable-by-default","text":"The Scheduler resource's `mastersSchedulable` defaults to `false` — master/control plane nodes do not run workload pods by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-masters-not-schedulable-by-default.json"},{"id":"scheduler-ns-annotation-overrides-default-selector","text":"The namespace-level `openshift.io/node-selector` annotation overrides the cluster-wide `defaultNodeSelector` from the Scheduler config.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-ns-annotation-overrides-default-selector.json"},{"id":"scheduler-policy-deprecated","text":"The Scheduler resource's `policy` field (ConfigMap-based custom scheduler policy in `openshift-config`) is deprecated, replaced by scheduling profiles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-policy-deprecated.json"},{"id":"scheduler-prefers-maximumvolumesize-over-capacity","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-prefers-maximumvolumesize-over-capacity.json"},{"id":"scheduler-profile-config-object","text":"The scheduler profile is configured on the `Scheduler` object named `cluster` (API `config.openshift.io/v1`) via `spec.profile`, requiring `cluster-admin` role","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-profile-config-object.json"},{"id":"scheduler-three-profiles","text":"The Scheduler resource supports three profiles: `LowNodeUtilization` (default, spreads pods), `HighNodeUtilization` (packs pods onto fewer nodes), and `NoScoring` (skips scoring for faster scheduling).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-three-profiles.json"},{"id":"scheduler-three-step-process","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduler-three-step-process.json"},{"id":"scheduling-constraints-multi-dimensional","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduling-constraints-multi-dimensional.json"},{"id":"scheduling-gates-set-at-creation-only","text":"Pod `schedulingGates` can only be set at creation time and removed afterward; they cannot be added post-creation.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/scheduling-gates-set-at-creation-only.json"},{"id":"sctp-enabled-via-machineconfig-kernel-module","text":"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`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sctp-enabled-via-machineconfig-kernel-module.json"},{"id":"seccomp-cannot-apply-privileged-containers","text":"Seccomp profiles cannot be applied to privileged containers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/seccomp-cannot-apply-privileged-containers.json"},{"id":"seccomp-pod-annotation-deprecated-417","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/seccomp-pod-annotation-deprecated-417.json"},{"id":"seccomp-profiles-path-var-lib-kubelet","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/seccomp-profiles-path-var-lib-kubelet.json"},{"id":"secondary-network-cr-types","text":"Secondary networks can be defined using either a `UserDefinedNetwork` CR or a `NetworkAttachmentDefinition` CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secondary-network-cr-types.json"},{"id":"secret-data-base64-not-encrypted","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secret-data-base64-not-encrypted.json"},{"id":"secret-data-key-allowed-chars","text":"Keys in Secret data fields must consist of alphanumeric characters, `-`, `_`, or `.`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secret-data-key-allowed-chars.json"},{"id":"secret-immutable-field","text":"Setting `immutable: true` on a Secret prevents data modifications; only metadata can be changed afterward","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secret-immutable-field.json"},{"id":"secret-stringdata-write-only","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secret-stringdata-write-only.json"},{"id":"secret-type-tls-required-keys","text":"A Secret with `type: kubernetes.io/tls` requires the keys `tls.crt` and `tls.key`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secret-type-tls-required-keys.json"},{"id":"secretlist-endpoint-read-only","text":"The ImageStream secrets endpoint is read-only (only GET is defined); secrets are managed through the core Secret API","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secretlist-endpoint-read-only.json"},{"id":"secretlist-is-imagestream-subresource","text":"SecretList is accessed as a sub-resource of ImageStream via GET /apis/image.openshift.io/v1/namespaces/{namespace}/imagestreams/{name}/secrets","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secretlist-is-imagestream-subresource.json"},{"id":"secretlist-items-only-required-field","text":"The `items` field is the only required field in the SecretList resource","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secretlist-items-only-required-field.json"},{"id":"secrets-create-and-attach-syntax","text":"Secrets are created with `oc create secret generic <name> --from-literal=KEY=VALUE` and attached to deployments with `oc set env --from=secret/<name> deploy/<name>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/secrets-create-and-attach-syntax.json"},{"id":"security-and-governance-unified-across-all-topologies","text":"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","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-and-governance-unified-across-all-topologies.json"},{"id":"security-and-governance-unified-enforcement-stack","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-and-governance-unified-enforcement-stack.json"},{"id":"security-api-compatibility-levels","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-api-compatibility-levels.json"},{"id":"security-constrains-entire-update-path","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-constrains-entire-update-path.json"},{"id":"security-enforced-at-install-runtime-and-api-boundary","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-enforced-at-install-runtime-and-api-boundary.json"},{"id":"security-invariant-across-topology-variants","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-invariant-across-topology-variants.json"},{"id":"security-openshift-io-v1-mixed-tiers","text":"security.openshift.io/v1 is Tier 1 except RangeAllocation (Tier 4) and *Reviews (Tier 2).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/security-openshift-io-v1-mixed-tiers.json"},{"id":"self-provisioner-clusterrolebinding-controls-project-creation","text":"Project self-provisioning can be enabled or disabled cluster-wide by modifying the `self-provisioner` ClusterRoleBinding","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/self-provisioner-clusterrolebinding-controls-project-creation.json"},{"id":"self-provisioners-controls-project-creation","text":"Cluster admins can restrict project self-provisioning by removing the `self-provisioners` cluster role binding.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/self-provisioners-controls-project-creation.json"},{"id":"selfsubjectrulesreview-resource-vs-nonresource-rules","text":"SelfSubjectRulesReview status contains `resourceRules` (actions on API resources with K8s verbs) and `nonResourceRules` (actions on non-resource URL paths like `/healthz` with HTTP verbs).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/selfsubjectrulesreview-resource-vs-nonresource-rules.json"},{"id":"selfsubjectrulesreview-results-can-be-incomplete","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/selfsubjectrulesreview-results-can-be-incomplete.json"},{"id":"selfsubjectrulesreview-ui-only","text":"SelfSubjectRulesReview should only be used for UI show/hide hints, NOT for driving external authorization decisions (confused deputy/cache concerns).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/selfsubjectrulesreview-ui-only.json"},{"id":"selfsubjectrulesreview-ui-only-not-for-authz","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/selfsubjectrulesreview-ui-only-not-for-authz.json"},{"id":"serverless-based-on-knative","text":"OpenShift Serverless is based on the open source Knative project and is the Red Hat enterprise distribution of Knative.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-based-on-knative.json"},{"id":"serverless-installed-via-operator","text":"OpenShift Serverless is installed and managed via the OpenShift Serverless Operator from OperatorHub.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-installed-via-operator.json"},{"id":"serverless-installed-via-serverless-operator","text":"OpenShift Serverless is installed via the Serverless Operator, which manages Knative Serving and Knative Eventing components.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-installed-via-serverless-operator.json"},{"id":"serverless-integrates-with-service-mesh","text":"OpenShift Serverless integrates with OpenShift Service Mesh.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-integrates-with-service-mesh.json"},{"id":"serverless-is-knative-distribution","text":"OpenShift Serverless is Red Hat's distribution of Knative, providing Serving, Eventing, and Functions capabilities.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-is-knative-distribution.json"},{"id":"serverless-kn-cli","text":"The `kn` CLI is the primary Knative command-line client for managing serverless resources on OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-kn-cli.json"},{"id":"serverless-scale-to-zero","text":"OpenShift Serverless enables scale-to-zero behavior — pods are removed when there is no traffic and recreated on demand.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-scale-to-zero.json"},{"id":"serverless-separate-release-cadence","text":"OpenShift Serverless releases on a different cadence from OpenShift Container Platform and has its own separate documentation set.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-separate-release-cadence.json"},{"id":"serverless-two-components-serving-eventing","text":"OpenShift Serverless has two core components: Knative Serving (request-driven compute with scale-to-zero) and Knative Eventing (declarative event source and routing infrastructure).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serverless-two-components-serving-eventing.json"},{"id":"service-account-issuer-24h-grace","text":"Changing `spec.serviceAccountIssuer` on the Authentication resource does not immediately invalidate existing tokens — a 24-hour grace period allows internal components to transition.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-account-issuer-24h-grace.json"},{"id":"service-dual-stack-ipfamilypolicy","text":"Dual-stack Services use `ipFamilyPolicy` (SingleStack, PreferDualStack, RequireDualStack) and `ipFamilies` (IPv4, IPv6); `clusterIPs` holds max two entries","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-dual-stack-ipfamilypolicy.json"},{"id":"service-external-traffic-policy-local","text":"`externalTrafficPolicy: Local` preserves client source IP but drops traffic on nodes with no local endpoints; default is `Cluster`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-external-traffic-policy-local.json"},{"id":"service-headless-clusterip-none","text":"A headless Service is created by setting `clusterIP: \"None\"` — no virtual IP allocated, endpoints published directly; used for StatefulSet peer discovery","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-headless-clusterip-none.json"},{"id":"service-healthcheck-nodeport-requirements","text":"`healthCheckNodePort` only applies when type=LoadBalancer AND externalTrafficPolicy=Local; lets external LBs probe endpoint availability","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-healthcheck-nodeport-requirements.json"},{"id":"service-loadbalancerip-deprecated","text":"`loadBalancerIP` is deprecated; implementation-specific annotations should be used instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-loadbalancerip-deprecated.json"},{"id":"service-mesh-3x-based-on-istio-sail","text":"Red Hat OpenShift Service Mesh 3.x is now generally available and is based on Istio Sail rather than Maistra (used by 2.x).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-3x-based-on-istio-sail.json"},{"id":"service-mesh-3x-uses-sail-operator","text":"OpenShift Service Mesh 3.x is built on upstream Istio with the Sail Operator, replacing the older Maistra-based approach from 2.x.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-3x-uses-sail-operator.json"},{"id":"service-mesh-based-on-istio","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-based-on-istio.json"},{"id":"service-mesh-control-plane-istio-system","text":"The Service Mesh control plane (SMCP) is typically installed in the `istio-system` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-control-plane-istio-system.json"},{"id":"service-mesh-current-version-3x","text":"OpenShift Service Mesh 3.x (up to 3.2) is the current major version line, separate from the older 2.x line.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-current-version-3x.json"},{"id":"service-mesh-four-core-capabilities","text":"OpenShift Service Mesh provides four core capabilities: traffic management, service identity and security, policy enforcement, and telemetry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-four-core-capabilities.json"},{"id":"service-mesh-multi-operator-architecture","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-multi-operator-architecture.json"},{"id":"service-mesh-multi-tenant-default","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-multi-tenant-default.json"},{"id":"service-mesh-no-code-changes","text":"Service Mesh does not require application code changes — it works transparently via sidecar proxies that intercept traffic between services.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-no-code-changes.json"},{"id":"service-mesh-provides-traffic-observability-mtls","text":"OpenShift Service Mesh provides traffic management, observability, and security (mTLS) between microservices.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-provides-traffic-observability-mtls.json"},{"id":"service-mesh-requires-multiple-operators","text":"Service Mesh requires multiple operators to be installed: the Red Hat OpenShift Service Mesh Operator, Kiali Operator, and a tracing operator (Jaeger or Tempo).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-mesh-requires-multiple-operators.json"},{"id":"service-network-single-entry","text":"`serviceNetwork` currently supports only a single entry","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-network-single-entry.json"},{"id":"service-nodeport-range-default-mutable","text":"`serviceNodePortRange` defaults to `30000-32767` and can be changed post-install (unlike most Network spec fields)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-nodeport-range-default-mutable.json"},{"id":"service-port-only-required-field","text":"`port` is the only required field in a ServicePort definition; `targetPort` defaults to the `port` value if omitted","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-port-only-required-field.json"},{"id":"service-publish-not-ready-addresses","text":"`publishNotReadyAddresses: true` treats all endpoints as ready; critical for StatefulSet peer discovery via SRV DNS records","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-publish-not-ready-addresses.json"},{"id":"service-session-affinity-clientip-timeout","text":"Service `sessionAffinity` supports `ClientIP` or `None` (default); ClientIP sticky timeout defaults to 10800s (3 hours), max 86400s (1 day)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-session-affinity-clientip-timeout.json"},{"id":"service-types-hierarchy","text":"Service types form a hierarchy: ClusterIP (default) → NodePort (adds node port) → LoadBalancer (adds external LB); ExternalName is separate (CNAME only, no proxying)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/service-types-hierarchy.json"},{"id":"serviceca-manages-serving-cert-signer","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/serviceca-manages-serving-cert-signer.json"},{"id":"servicemonitor-auth-mutually-exclusive","text":"ServiceMonitor endpoint authentication options (`authorization`, `basicAuth`, `oauth2`) are mutually exclusive","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-auth-mutually-exclusive.json"},{"id":"servicemonitor-honor-labels-preserves-collisions","text":"In ServiceMonitor, `honorLabels: true` preserves the metric's own labels when they collide with target labels","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-honor-labels-preserves-collisions.json"},{"id":"servicemonitor-joblabel-from-service","text":"ServiceMonitor's `jobLabel` field selects a label from the associated Service to use as the Prometheus `job` label; defaults to Service name if unset","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-joblabel-from-service.json"},{"id":"servicemonitor-only-required-field-selector","text":"The only required field under ServiceMonitor `.spec` is `selector` — a label selector for Endpoints discovery","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-only-required-field-selector.json"},{"id":"servicemonitor-port-vs-targetport","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-port-vs-targetport.json"},{"id":"servicemonitor-sample-limit-fails-scrape","text":"ServiceMonitor's `sampleLimit` controls the per-scrape limit on accepted samples; exceeding it causes the scrape to fail","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-sample-limit-fails-scrape.json"},{"id":"servicemonitor-vs-podmonitor","text":"ServiceMonitor selects monitoring targets by matching services; PodMonitor selects monitoring targets by matching pods directly. Both are `monitoring.coreos.com/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/servicemonitor-vs-podmonitor.json"},{"id":"shared-resource-csi-driver-deprecated","text":"The Shared Resource CSI Driver is deprecated in OCP; it migrated to Builds for Red Hat OpenShift 1.1.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shared-resource-csi-driver-deprecated.json"},{"id":"shared-resources-csi-driver-for-builds","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shared-resources-csi-driver-for-builds.json"},{"id":"shared-templates-openshift-namespace","text":"The `openshift` namespace contains cluster-level shared templates available to all projects","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shared-templates-openshift-namespace.json"},{"id":"shipwright-builds-from-source-and-dockerfiles","text":"Shipwright can build container images from both source code and Dockerfiles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-builds-from-source-and-dockerfiles.json"},{"id":"shipwright-builds-from-source-dockerfiles-local","text":"Shipwright can build container images from source code (including local directories), and Dockerfiles.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-builds-from-source-dockerfiles-local.json"},{"id":"shipwright-builds-run-on-cluster","text":"Shipwright builds execute within the OpenShift cluster itself, not externally.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-builds-run-on-cluster.json"},{"id":"shipwright-cli-distinct-from-oc","text":"The Shipwright CLI is a separate tool from `oc` used for creating builds, viewing build run logs, and managing builds on the cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-cli-distinct-from-oc.json"},{"id":"shipwright-distinct-from-legacy-buildconfig","text":"Shipwright-based Builds is distinct from and replaces the legacy OpenShift Build system based on BuildConfig objects and `oc start-build`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-distinct-from-legacy-buildconfig.json"},{"id":"shipwright-independent-release-cadence","text":"Builds (Shipwright) releases on a different cadence from OpenShift Container Platform itself and has its own separate documentation set at docs.redhat.com.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-independent-release-cadence.json"},{"id":"shipwright-is-extensible-build-framework","text":"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).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-is-extensible-build-framework.json"},{"id":"shipwright-runs-on-cluster","text":"Shipwright builds run on-cluster within the OpenShift environment, not externally.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-runs-on-cluster.json"},{"id":"shipwright-supports-s2i-and-buildah","text":"Shipwright-based Builds supports both Source-to-Image (S2I) and Buildah as build strategies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-supports-s2i-and-buildah.json"},{"id":"shipwright-supports-s2i-buildah-custom-strategies","text":"Shipwright-based Builds supports three build strategy types: Source-to-Image (S2I), Buildah, and custom user-defined strategies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/shipwright-supports-s2i-buildah-custom-strategies.json"},{"id":"signature-condition-types-complete-or-failed","text":"Image signature condition types are exactly two: Complete and Failed, with status values of True, False, or Unknown.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/signature-condition-types-complete-or-failed.json"},{"id":"sigstore-fulcio-keyless-signing-via-oidc","text":"Sigstore enables key-less container image signing using OIDC identity via the Fulcio certificate authority, eliminating traditional key management.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sigstore-fulcio-keyless-signing-via-oidc.json"},{"id":"sigstore-rekor-immutable-transparency-log","text":"Rekor is the sigstore component that records signature metadata to an immutable, tamper-resistant transparency log.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sigstore-rekor-immutable-transparency-log.json"},{"id":"sigstore-signatures-colocated-in-registry","text":"Sigstore signatures are stored in the same container registry as the build images, requiring no separate signature server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sigstore-signatures-colocated-in-registry.json"},{"id":"silence-management-roles","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/silence-management-roles.json"},{"id":"silences-require-persistent-storage","text":"Alertmanager silences are replicated across Alertmanager pods but require persistent storage to survive pod restarts.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/silences-require-persistent-storage.json"},{"id":"single-nic-nodes-must-use-br-ex","text":"Single-NIC nodes must use `br-ex` for localnet bridge mappings; multi-NIC nodes can use a dedicated bridge for traffic isolation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/single-nic-nodes-must-use-br-ex.json"},{"id":"single-node-cannot-mix-gpu-types","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/single-node-cannot-mix-gpu-types.json"},{"id":"singleton-resource-naming-convention","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/singleton-resource-naming-convention.json"},{"id":"smm-allows-project-admin-join-mesh","text":"A ServiceMeshMember (SMM) resource allows project admins to add their namespace to a mesh without needing cluster-admin to edit the SMMR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/smm-allows-project-admin-join-mesh.json"},{"id":"smmr-must-be-named-default","text":"The ServiceMeshMemberRoll (SMMR) must be named `default` and must reside in the same namespace as the ServiceMeshControlPlane (SMCP).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/smmr-must-be-named-default.json"},{"id":"snapshot-pattern-mirrors-pvc-pv-storageclass","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/snapshot-pattern-mirrors-pvc-pv-storageclass.json"},{"id":"sno-composable-required-capabilities","text":"Required capabilities for SNO vDU with `baselineCapabilitySet: None`: NodeTuning (4.13+), OperatorLifecycleManager (4.15+), and Ingress (4.16+).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-composable-required-capabilities.json"},{"id":"sno-dns-api-int-required","text":"DNS must resolve `api-int.<cluster_name>.<base_domain>` for worker node addition to an SNO cluster.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-dns-api-int-required.json"},{"id":"sno-dns-records-api-apiint-apps","text":"SNO clusters require three DNS records: `api.<cluster>.<domain>`, `api-int.<cluster>.<domain>`, and `*.apps.<cluster>.<domain>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-dns-records-api-apiint-apps.json"},{"id":"sno-expansion-no-downtime","text":"Adding worker nodes to a single-node OpenShift cluster requires no downtime and the original node retains its control plane role.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-expansion-no-downtime.json"},{"id":"sno-expansion-tech-preview-417","text":"SNO cluster expansion by adding worker nodes is a Technology Preview feature in OCP 4.17 (not supported under production SLAs).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-expansion-tech-preview-417.json"},{"id":"sno-ingress-routes-to-control-plane","text":"All ingress traffic routes to the single control-plane node by default in SNO, even after adding worker nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-ingress-routes-to-control-plane.json"},{"id":"sno-install-methods","text":"SNO can be installed via the Assisted Installer, agent-based installer, or manual UPI.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-install-methods.json"},{"id":"sno-key-edge-topology","text":"Single-Node OpenShift (SNO) is a key topology for edge deployments, running both control plane and workloads on a single node.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-key-edge-topology.json"},{"id":"sno-max-worker-nodes-2","text":"Single-node OpenShift (SNO) clusters support a tested maximum of 2 worker nodes; exceeding this may cause performance degradation or cluster failure.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-max-worker-nodes-2.json"},{"id":"sno-no-high-availability","text":"SNO does not provide high availability — etcd runs as a single instance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-no-high-availability.json"},{"id":"sno-reduced-capability-profile","text":"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+.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-reduced-capability-profile.json"},{"id":"sno-single-node-control-and-worker","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-single-node-control-and-worker.json"},{"id":"sno-static-ip-all-same-address","text":"For SNO with static IPs, the node-specific, API, and Ingress IPs should all be the same address.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-static-ip-all-same-address.json"},{"id":"sno-supported-production-topology","text":"Single Node OpenShift (SNO) is a supported production configuration, not limited to development or testing.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-supported-production-topology.json"},{"id":"sno-update-requires-downtime","text":"Single-node OpenShift (SNO) updates require downtime; no MHC pause is needed, node draining is skipped, and there is no automatic rollback on failure","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-update-requires-downtime.json"},{"id":"sno-worker-csr-approval-required","text":"CSR approval is mandatory to complete worker node installation on SNO clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-worker-csr-approval-required.json"},{"id":"sno-worker-min-requirements","text":"SNO worker node minimum requirements: 2 vCPU, 8 GB RAM, 100 GB storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-worker-min-requirements.json"},{"id":"sno-worker-requires-ocp-411","text":"Adding worker nodes to SNO requires OpenShift Container Platform 4.11 or later.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-worker-requires-ocp-411.json"},{"id":"sno-workers-no-ha-no-control-plane-expansion","text":"Adding worker nodes to SNO does NOT provide high availability and does NOT expand the control plane.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-workers-no-ha-no-control-plane-expansion.json"},{"id":"sno-workload-partitioning-before-worker-install","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sno-workload-partitioning-before-worker-install.json"},{"id":"spec-oauth-metadata-takes-precedence","text":"`spec.oauthMetadata` takes precedence over `status.integratedOAuthMetadata` on the Authentication resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/spec-oauth-metadata-takes-precedence.json"},{"id":"sriov-bypasses-kernel-networking-stack","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-bypasses-kernel-networking-stack.json"},{"id":"sriov-config-daemon-daemonset","text":"The SR-IOV network config daemon runs as a DaemonSet on worker nodes, discovering and initializing SR-IOV devices.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-config-daemon-daemonset.json"},{"id":"sriov-enables-near-native-network-performance","text":"SR-IOV (Single Root I/O Virtualization) enables near-native network performance by allowing pods direct access to virtual functions (VFs) on physical NICs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-enables-near-native-network-performance.json"},{"id":"sriov-fully-operational-on-cluster","text":"SR-IOV networking is fully operational with VF driver modes, config daemon, and hardware offloading support.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-fully-operational-on-cluster.json"},{"id":"sriov-injector-first-container-only","text":"The SR-IOV Network resources injector adds the `resource` field to only the first container in a pod.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-injector-first-container-only.json"},{"id":"sriov-key-for-telco-nfv-workloads","text":"SR-IOV is a key technology for telco/NFV and low-latency use cases on OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-key-for-telco-nfv-workloads.json"},{"id":"sriov-managed-by-sriov-network-operator","text":"SR-IOV functionality in OpenShift is managed by the SR-IOV Network Operator, installed via OperatorHub/OLM.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-managed-by-sriov-network-operator.json"},{"id":"sriov-multi-network-policy-tech-preview","text":"Multi-network policies on SR-IOV networks are Technology Preview, supported for kernel NICs only, and not supported for DPDK applications.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-multi-network-policy-tech-preview.json"},{"id":"sriov-multicast-net-admin-for-multicast-ip","text":"NET_ADMIN capability is required in a pod only when the application needs to assign a multicast IP address to the SR-IOV interface.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-multicast-net-admin-for-multicast-ip.json"},{"id":"sriov-multicast-physical-network-controls-routing","text":"The physical network infrastructure (not OpenShift) controls multicast routing and topology for SR-IOV interfaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-multicast-physical-network-controls-routing.json"},{"id":"sriov-multicast-routes-224-and-232","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-multicast-routes-224-and-232.json"},{"id":"sriov-network-policy-may-drain-reboot-nodes","text":"Applying an `SriovNetworkNodePolicy` may drain and reboot nodes; sufficient available nodes must exist for evicted workloads","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-network-policy-may-drain-reboot-nodes.json"},{"id":"sriov-network-resources-injector-on-control-plane","text":"The SR-IOV Network Resources Injector and Operator Webhook both run as DaemonSets on control plane nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-network-resources-injector-on-control-plane.json"},{"id":"sriov-node-drain-before-policy-change","text":"The SR-IOV Operator performs node draining before every policy change by default; this must be disabled for single-node clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-node-drain-before-policy-change.json"},{"id":"sriov-node-label","text":"The node label to mark SR-IOV-capable nodes is `feature.node.kubernetes.io/network-sriov.capable=\"true\"`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-node-label.json"},{"id":"sriov-node-selector-capability-label","text":"SR-IOV network node policies use the node selector label feature.node.kubernetes.io/network-sriov.capable: \"true\" to target SR-IOV capable nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-node-selector-capability-label.json"},{"id":"sriov-operational-with-live-migration","text":"SR-IOV networking and VM live migration can coexist when SR-IOV is fully operational and migration prerequisites are met, but only on multi-node clusters where SR-IOV drain is not disabled.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operational-with-live-migration.json"},{"id":"sriov-operator-config-default-cr","text":"The `SriovOperatorConfig` CR (named `default`) controls enablement of the SR-IOV webhook and resources injector, both enabled by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operator-config-default-cr.json"},{"id":"sriov-operator-config-named-default","text":"The `SriovOperatorConfig` CR must be named `default` in the `openshift-sriov-network-operator` namespace — no other name is valid.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operator-config-named-default.json"},{"id":"sriov-operator-creates-nads","text":"The SR-IOV Network Operator automatically creates NetworkAttachmentDefinitions when SriovNetwork CRs are defined","truth_value":"IN","justification_count":0,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operator-creates-nads.json"},{"id":"sriov-operator-namespace","text":"All SR-IOV Network Operator resources live in the `openshift-sriov-network-operator` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operator-namespace.json"},{"id":"sriov-operator-required-for-hardware-networks","text":"The SR-IOV Network Operator is required to manage SR-IOV resources in OpenShift, discovering SR-IOV-capable devices and configuring virtual functions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-operator-required-for-hardware-networks.json"},{"id":"sriov-primary-hw-network-tech","text":"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","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-primary-hw-network-tech.json"},{"id":"sriov-requires-bare-metal-hardware","text":"SR-IOV Operator installation requires bare-metal hardware with SR-IOV-capable NICs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-requires-bare-metal-hardware.json"},{"id":"sriov-sno-disable-drain","text":"For single-node OpenShift, the SR-IOV Operator requires `disableDrain: true` and annotation `workload.openshift.io/allowed=management` on the namespace.","truth_value":"IN","justification_count":0,"dependent_count":5,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-sno-disable-drain.json"},{"id":"sriov-supported-bare-metal-rhosp-only","text":"SR-IOV is supported only on bare metal and Red Hat OpenStack Platform (RHOSP) — not on cloud platforms like AWS/Azure/GCP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-supported-bare-metal-rhosp-only.json"},{"id":"sriov-two-driver-modes","text":"SR-IOV has two driver modes: `netdevice` (exposes VF as kernel network device) and `vfio-pci` (exposes VF as character device).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-two-driver-modes.json"},{"id":"sriov-with-nmstate-operational","text":"SR-IOV high-performance networking with declarative NMState node network configuration provides a complete hardware-accelerated networking stack — SR-IOV creates VFs and NetworkAttachmentDefinitions while NMState manages the underlying node interfaces — only when SR-IOV drain limitations on SNO are resolved.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sriov-with-nmstate-operational.json"},{"id":"starting-csv-requires-manual-approval","text":"Setting `startingCSV` in a Subscription to pin a specific Operator version requires `installPlanApproval: Manual`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/starting-csv-requires-manual-approval.json"},{"id":"statefulset-default-pod-management-orderedready","text":"StatefulSet default pod management policy is `OrderedReady` — pods created sequentially (0, 1, 2…) and scaled down in reverse order.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-default-pod-management-orderedready.json"},{"id":"statefulset-default-update-strategy-rollingupdate","text":"StatefulSet default update strategy is `RollingUpdate`; the alternative `OnDelete` requires manual pod deletion to trigger updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-default-update-strategy-rollingupdate.json"},{"id":"statefulset-partition-enables-canary-deployments","text":"Setting `partition` in a StatefulSet RollingUpdate only updates pods with ordinal >= partition value, enabling canary deployments.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-partition-enables-canary-deployments.json"},{"id":"statefulset-pod-naming-convention","text":"StatefulSet pods are named `<statefulsetname>-<podindex>` (e.g., `web-0`, `web-1`, `web-2`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-pod-naming-convention.json"},{"id":"statefulset-pvc-retention-default-retain","text":"StatefulSet PVC retention default is `Retain` — PVCs are NOT deleted when the StatefulSet is deleted or scaled down.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-pvc-retention-default-retain.json"},{"id":"statefulset-replicas-default-one","text":"StatefulSet `replicas` defaults to 1 if unspecified.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-replicas-default-one.json"},{"id":"statefulset-requires-preexisting-headless-service","text":"A StatefulSet's `serviceName` field is required and must reference a pre-existing headless Service that provides network identity.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-requires-preexisting-headless-service.json"},{"id":"statefulset-restart-policy-always-only","text":"The only allowed `restartPolicy` in a StatefulSet pod template is `Always`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulset-restart-policy-always-only.json"},{"id":"statefulsets-for-stable-identity-storage","text":"StatefulSets are for applications needing stable identity/numbering and independent storage (e.g., databases, ZooKeeper).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/statefulsets-for-stable-identity-storage.json"},{"id":"static-pod-operator-default-revision-limit-5","text":"Default revision limits (`failedRevisionLimit` and `succeededRevisionLimit`) for static pod operators are 5 when set to 0 or unset","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/static-pod-operator-default-revision-limit-5.json"},{"id":"static-pods-cannot-use-secrets-or-configmaps","text":"Static pods are automatically restarted by the kubelet on node reboot but cannot use Secrets or ConfigMaps.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/static-pods-cannot-use-secrets-or-configmaps.json"},{"id":"storage-api-groups-distribution","text":"OCP storage APIs span multiple API groups: `v1` (core — PV/PVC), `storage.k8s.io` (StorageClass, CSI objects), and `snapshot.storage.k8s.io` (VolumeSnapshot resources).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storage-api-groups-distribution.json"},{"id":"storage-lifecycle-from-provisioning-to-reclaim","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storage-lifecycle-from-provisioning-to-reclaim.json"},{"id":"storage-object-in-use-protection-default","text":"Storage Object in Use Protection is enabled by default in OCP, preventing deletion of PVCs actively used by pods and PVs bound to PVCs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storage-object-in-use-protection-default.json"},{"id":"storage-operator-singleton-named-cluster","text":"The Storage operator CR (`operator.openshift.io/v1`) singleton instance must be named `cluster`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storage-operator-singleton-named-cluster.json"},{"id":"storage-scope-nonnamespaced-resources","text":"CSIDriver, StorageClass, VolumeAttachment, and VolumeSnapshotClass are non-namespaced (cluster-scoped) resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storage-scope-nonnamespaced-resources.json"},{"id":"storageclass-allowvolumeexpansion-required-for-resize","text":"`allowVolumeExpansion: true` must be set on the StorageClass to permit PVC resizing.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-allowvolumeexpansion-required-for-resize.json"},{"id":"storageclass-default-reclaimpolicy-delete","text":"The default `reclaimPolicy` for dynamically provisioned PersistentVolumes is `Delete`.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-default-reclaimpolicy-delete.json"},{"id":"storageclass-globally-scoped","text":"StorageClass objects are globally scoped (not namespaced) and must be created by cluster-admin or storage-admin users.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-globally-scoped.json"},{"id":"storageclass-mountoptions-not-validated-at-creation","text":"StorageClass `mountOptions` are not validated at creation time; invalid options only cause failures at mount time.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-mountoptions-not-validated-at-creation.json"},{"id":"storageclass-provisioner-only-required-field","text":"The `provisioner` field is the only required field on a StorageClass resource.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-provisioner-only-required-field.json"},{"id":"storageclass-waitforfirstconsumer-delays-binding","text":"`volumeBindingMode: WaitForFirstConsumer` delays PVC binding and provisioning until a Pod referencing the PVC is scheduled, enabling topology-aware provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageclass-waitforfirstconsumer-delays-binding.json"},{"id":"storagestate-api-group-v1alpha1","text":"StorageState is in the `migration.k8s.io/v1alpha1` API group (alpha-level API).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storagestate-api-group-v1alpha1.json"},{"id":"storagestate-current-hash-from-discovery","text":"The `currentStorageVersionHash` in StorageState comes from the API server's discovery document, not from the StorageState spec.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storagestate-current-hash-from-discovery.json"},{"id":"storagestate-storageversionmigration-alpha","text":"StorageState and StorageVersionMigration are `v1alpha1` APIs in the `migration.k8s.io` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storagestate-storageversionmigration-alpha.json"},{"id":"storagestate-unknown-hash-blocks-upgrade","text":"If `\"Unknown\"` is present in `persistedStorageVersionHashes`, it is not safe to upgrade or downgrade the API server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storagestate-unknown-hash-blocks-upgrade.json"},{"id":"storageversionmigration-resource-target-three-fields","text":"StorageVersionMigration targets a resource using three fields: `group`, `resource`, and `version`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageversionmigration-resource-target-three-fields.json"},{"id":"storageversionmigration-spec-resource-immutable","text":"The StorageVersionMigration `.spec.resource` field is immutable after creation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/storageversionmigration-spec-resource-immutable.json"},{"id":"sts-workload-id-requires-manual-approval","text":"Clusters using AWS STS, Microsoft Entra Workload ID, or GCP Workload Identity must use Manual approval strategy for Operator subscriptions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/sts-workload-id-requires-manual-approval.json"},{"id":"subjectaccessreview-cluster-scoped","text":"SubjectAccessReview is cluster-scoped (not namespaced) — accessed via a single endpoint `POST /apis/authorization.k8s.io/v1/subjectaccessreviews`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subjectaccessreview-cluster-scoped.json"},{"id":"submariner-l3-vs-service-interconnect-l7","text":"Submariner provides layer 3 inter-cluster networking; Red Hat Service Interconnect provides layer 7 inter-cluster networking","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/submariner-l3-vs-service-interconnect-l7.json"},{"id":"subscription-api-group-v1alpha1","text":"The Subscription resource uses API group `operators.coreos.com/v1alpha1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-api-group-v1alpha1.json"},{"id":"subscription-config-env-resources-immutable","text":"Subscription `spec.config.env` and `spec.config.resources` are immutable after creation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-config-env-resources-immutable.json"},{"id":"subscription-config-fields","text":"The Subscription `config` section supports: `env`, `envFrom`, `volumes`, `volumeMounts`, `tolerations`, `resources`, and `nodeSelector`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-config-fields.json"},{"id":"subscription-config-scheduling-overrides","text":"Subscription `spec.config` supports nodeSelector, tolerations, and affinity to control operator pod placement (e.g., placing operators on infrastructure nodes)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-config-scheduling-overrides.json"},{"id":"subscription-installplanapproval-values","text":"Subscription `installPlanApproval` has exactly two valid values: `Automatic` and `Manual`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-installplanapproval-values.json"},{"id":"subscription-required-spec-fields","text":"Subscription required spec fields are `name`, `source`, and `sourceNamespace`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-required-spec-fields.json"},{"id":"subscription-specifies-channel-source-approval","text":"A Subscription specifies the channel, source, and approval strategy (Automatic vs Manual) for Operator updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-specifies-channel-source-approval.json"},{"id":"subscription-startingcsv-pins-version","text":"Subscription `startingCSV` optionally pins the initial ClusterServiceVersion; without it, the latest in the channel is installed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-startingcsv-pins-version.json"},{"id":"subscription-triggers-installplan-then-csv","text":"A Subscription triggers OLM to resolve and create an InstallPlan, which when approved installs the ClusterServiceVersion (CSV).","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/subscription-triggers-installplan-then-csv.json"},{"id":"support-case-filed-via-customer-portal","text":"Support cases are filed through the Red Hat Customer Portal at access.redhat.com","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/support-case-filed-via-customer-portal.json"},{"id":"support-case-requires-subscription","text":"Filing a Red Hat support case requires a Red Hat Standard or Premium subscription","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/support-case-requires-subscription.json"},{"id":"system-authenticated-unauthenticated-virtual-groups","text":"`system:authenticated` and `system:unauthenticated` are virtual groups automatically assigned to users based on authentication status","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/system-authenticated-unauthenticated-virtual-groups.json"},{"id":"system-node-critical-higher-than-system-cluster-critical","text":"The `system-node-critical` priority class has higher priority than `system-cluster-critical`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/system-node-critical-higher-than-system-cluster-critical.json"},{"id":"tag-reference-true-prevents-import","text":"Setting `tag.reference=true` on an ImageStreamTag or ImageTag spec means the tag will NOT be imported","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tag-reference-true-prevents-import.json"},{"id":"talm-applies-policies-wave-order","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-applies-policies-wave-order.json"},{"id":"talm-batch-timeout-action-default-continue","text":"TALM's `batchTimeoutAction` defaults to `continue` (skip failing clusters); can be set to `abort` to stop all remediation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-batch-timeout-action-default-continue.json"},{"id":"talm-canary-failure-stops-update","text":"In TALM, canary clusters are updated first (each in its own batch), and any failure in a canary cluster stops the entire update process.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-canary-failure-stops-update.json"},{"id":"talm-cgu-cr-primary-resource","text":"The ClusterGroupUpgrade (CGU) CR (`ran.openshift.io/v1alpha1`) is TALM's primary resource, defining clusters, policies, concurrency, canaries, timeouts, and actions.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-cgu-cr-primary-resource.json"},{"id":"talm-completed-cgu-cannot-be-reused","text":"A completed TALM ClusterGroupUpgrade CR cannot be reused — a new CGU CR must be created for subsequent updates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-completed-cgu-cannot-be-reused.json"},{"id":"talm-controller-deployment-name","text":"The TALM controller deployment is named `cluster-group-upgrades-controller-manager` in the `openshift-operators` namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-controller-deployment-name.json"},{"id":"talm-policies-must-be-inform","text":"Policies used with TALM must have `remediationAction: inform` — TALM handles the enforce lifecycle itself.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-policies-must-be-inform.json"},{"id":"talm-precaching-for-sno-limited-bandwidth","text":"TALM's pre-caching feature (`preCaching: true`) is designed for Single-Node OpenShift clusters with limited bandwidth; TALM checks disk space before caching images.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-precaching-for-sno-limited-bandwidth.json"},{"id":"talm-requires-rhacm-29","text":"The Topology Aware Lifecycle Manager (TALM) requires Red Hat Advanced Cluster Management (RHACM) 2.9 or later.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/talm-requires-rhacm-29.json"},{"id":"tang-hide-old-keys-dot-prefix","text":"To stop advertising old Tang keys while still allowing decryption, rename `.jwk` files with a dot prefix (e.g., `.key.jwk`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tang-hide-old-keys-dot-prefix.json"},{"id":"tang-keys-stored-var-db-tang","text":"Tang server keys are stored in `/var/db/tang` as `.jwk` files; new keys are generated by `/usr/libexec/tangd-keygen /var/db/tang`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tang-keys-stored-var-db-tang.json"},{"id":"tang-rekey-order-critical","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tang-rekey-order-critical.json"},{"id":"tang-server-stateless-no-tls","text":"Tang is a stateless server that requires no TLS, no authentication, and never stores or learns node encryption keys.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tang-server-stateless-no-tls.json"},{"id":"tekton-concept-mapping-from-jenkins","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-concept-mapping-from-jenkins.json"},{"id":"tekton-every-step-runs-as-container-in-pod","text":"Every step in OpenShift Pipelines runs as a container in a pod.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-every-step-runs-as-container-in-pod.json"},{"id":"tekton-hub-replaces-jenkins-plugins","text":"Tekton Hub replaces Jenkins plugins as the extensibility mechanism, providing a catalog of reusable community tasks.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-hub-replaces-jenkins-plugins.json"},{"id":"tekton-runafter-controls-task-order","text":"The runAfter field controls task execution order in a Tekton pipeline.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-runafter-controls-task-order.json"},{"id":"tekton-uses-openshift-rbac-not-plugin","text":"OpenShift Pipelines uses OpenShift's built-in RBAC for authorization instead of a plugin like Jenkins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-uses-openshift-rbac-not-plugin.json"},{"id":"tekton-workspace-triple-duty","text":"Tekton Workspaces serve triple duty: storage for inputs/outputs/artifacts, shared data among tasks, and mount points for secrets/configmaps.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tekton-workspace-triple-duty.json"},{"id":"telemetry-and-insights-enabled-by-default","text":"Both Telemetry and the Insights Operator are installed and enabled by default on OpenShift clusters","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-and-insights-enabled-by-default.json"},{"id":"telemetry-insights-enabled-by-default","text":"Telemetry and the Insights Operator are enabled by default in connected OpenShift clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-insights-enabled-by-default.json"},{"id":"telemetry-interval-4m30s","text":"The Telemeter Client sends Prometheus metrics to Red Hat every 4 minutes and 30 seconds","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-interval-4m30s.json"},{"id":"telemetry-upload-interval-4m30s","text":"The Telemetry client gathers and uploads metrics to Red Hat every 4 minutes and 30 seconds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-upload-interval-4m30s.json"},{"id":"telemetry-view-requires-cluster-admin-or-monitoring-view","text":"Viewing telemetry data requires the `cluster-admin` or `cluster-monitoring-view` role","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-view-requires-cluster-admin-or-monitoring-view.json"},{"id":"telemetry-vs-insights-operator-distinction","text":"Telemetry collects metrics and usage data, while the Insights Operator gathers anonymized cluster configuration and provides actionable recommendations via Red Hat Insights analysis.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/telemetry-vs-insights-operator-distinction.json"},{"id":"template-api-objects-three-types","text":"The Template API category covers three object types: Template (parameterized resource definition), TemplateInstance (record of processed template), and BrokerTemplateInstance (used by template service broker)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-api-objects-three-types.json"},{"id":"template-builder-tag-annotation","text":"Image streams must have the `builder` tag in annotations to appear as builder images in the web console Developer Catalog.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-builder-tag-annotation.json"},{"id":"template-global-openshift-project","text":"Cluster-wide templates are stored in the `openshift` project and can be listed with `oc get templates -n openshift`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-global-openshift-project.json"},{"id":"template-hardcoded-namespace-stripped","text":"Hardcoded namespace values in template objects are stripped during instantiation, but parameterized namespaces (containing `${PARAMETER_REFERENCE}`) are preserved after substitution","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-hardcoded-namespace-stripped.json"},{"id":"template-labels-apply-to-all-objects","text":"Template-level labels are applied to all objects created from the template.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-labels-apply-to-all-objects.json"},{"id":"template-list-parameters-command","text":"`oc process --parameters -f <filename>` lists the overridable parameters of a template.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-list-parameters-command.json"},{"id":"template-param-value-overrides-generator","text":"If a `value` is specified on a template parameter, the generator is ignored","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-param-value-overrides-generator.json"},{"id":"template-parameter-syntax-dollar-brace","text":"Template parameter substitution uses `${PARAMETER_NAME}` syntax, and the only supported generator type is `\"expression\"`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-parameter-syntax-dollar-brace.json"},{"id":"template-parameters-generate-expression","text":"Template parameters with `generate: expression` and `from:` (e.g., `'[A-Z0-9]{8}'`) produce auto-generated values such as passwords.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-parameters-generate-expression.json"},{"id":"template-process-create-pattern","text":"`oc process -f <file> | oc create -f -` is the standard pattern for creating objects from a template file in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-process-create-pattern.json"},{"id":"template-quickstart-ephemeral-storage","text":"Quick start database templates use ephemeral storage by default — data is lost on pod restart.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-quickstart-ephemeral-storage.json"},{"id":"template-required-parameter-fails","text":"A template parameter with `required: true` causes template processing to fail if no value is supplied and no default or generator exists.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-required-parameter-fails.json"},{"id":"template-service-broker-deprecated","text":"The Template Service Broker is a deprecated component in newer OCP versions; BrokerTemplateInstance exists to support the Open Service Broker API integration.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/template-service-broker-deprecated.json"},{"id":"templateinstance-api-group","text":"TemplateInstance is a namespaced resource in the `template.openshift.io/v1` API group that records the instantiation of a Template","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templateinstance-api-group.json"},{"id":"templateinstance-secret-for-params","text":"TemplateInstance `.spec.secret` references a Secret containing template parameter values, keeping sensitive values out of the TemplateInstance spec","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templateinstance-secret-for-params.json"},{"id":"templateinstance-status-condition-types","text":"TemplateInstance status conditions have two types: `Ready` and `InstantiateFailure`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templateinstance-status-condition-types.json"},{"id":"templates-are-openshift-native-parameterized-resources","text":"Templates are an OpenShift-native mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-are-openshift-native-parameterized-resources.json"},{"id":"templates-are-openshift-specific-api","text":"Templates are an OpenShift-specific API extension not present in upstream Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-are-openshift-specific-api.json"},{"id":"templates-openshift-namespace-cluster-wide","text":"Shared templates are placed in the `openshift` namespace to make them accessible from all namespaces.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-openshift-namespace-cluster-wide.json"},{"id":"templates-openshift-parameterized-resources","text":"Templates are an OpenShift-specific mechanism for parameterized resource creation, distinct from Helm charts or Kustomize.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-openshift-parameterized-resources.json"},{"id":"templates-openshift-specific","text":"Templates are an OpenShift-specific concept not found in vanilla Kubernetes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-openshift-specific.json"},{"id":"templates-openshift-specific-parameterized-resources","text":"Templates are an OpenShift-specific mechanism for deploying parameterized sets of resources, distinct from Helm charts.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-openshift-specific-parameterized-resources.json"},{"id":"templates-supplemented-by-helm-operators","text":"Templates are increasingly supplemented by Helm charts and Operators as preferred deployment mechanisms in modern OpenShift versions","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/templates-supplemented-by-helm-operators.json"},{"id":"tempo-delete-cli-command","text":"To delete a TempoStack instance via CLI: `oc delete tempo <instance_name> -n <namespace>` (uses `tempo` resource kind, not `tempostack`)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tempo-delete-cli-command.json"},{"id":"tempo-removal-order","text":"When removing the Distributed Tracing Platform (Tempo), TempoStack instances must be deleted before removing the Tempo Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tempo-removal-order.json"},{"id":"tempo-removal-requires-cluster-admin","text":"Removing the Distributed Tracing Platform requires `cluster-admin` role, or `dedicated-admin` on Red Hat OpenShift Dedicated","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tempo-removal-requires-cluster-admin.json"},{"id":"thanosruler-alertmanagers-config-v0100","text":"ThanosRuler's `alertmanagersConfig` requires Thanos v0.10.0+; `queryConfig` requires v0.11.0+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-alertmanagers-config-v0100.json"},{"id":"thanosruler-api-group-v1","text":"ThanosRuler is a CRD in the `monitoring.coreos.com/v1` API group, managed by the Prometheus Operator","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-api-group-v1.json"},{"id":"thanosruler-default-retention-24h","text":"ThanosRuler's default data retention is `24h`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-default-retention-24h.json"},{"id":"thanosruler-deploys-as-statefulset","text":"ThanosRuler deploys as a StatefulSet with two containers: `thanos-ruler` and `config-reloader`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-deploys-as-statefulset.json"},{"id":"thanosruler-excluded-from-enforcement-replaces-deprecated","text":"ThanosRuler's `prometheusRulesExcludedFromEnforce` is deprecated in favor of `excludedFromEnforcement`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-excluded-from-enforcement-replaces-deprecated.json"},{"id":"thanosruler-replica-label-always-added-dropped","text":"ThanosRuler always adds the `thanos_ruler_replica` label and automatically drops it from alerts","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-replica-label-always-added-dropped.json"},{"id":"thanosruler-rule-namespace-selector-default","text":"If ThanosRuler's `ruleNamespaceSelector` is unspecified, only the ThanosRuler's own namespace is used for rule discovery","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/thanosruler-rule-namespace-selector-default.json"},{"id":"third-party-registries-no-notifications","text":"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`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/third-party-registries-no-notifications.json"},{"id":"three-autoscaling-types-hpa-vpa-custom","text":"OpenShift provides three autoscaling mechanisms: HPA (horizontal, CPU/memory-based), VPA (vertical, adjusts resource requests), and Custom Metrics Autoscaler (non-CPU/memory metrics).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-autoscaling-types-hpa-vpa-custom.json"},{"id":"three-build-strategies-dockerfile-s2i-custom","text":"OpenShift BuildConfig supports three build strategies: Dockerfile-based, Source-to-Image (S2I), and Custom builds.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-build-strategies-dockerfile-s2i-custom.json"},{"id":"three-control-plane-nodes-production","text":"Exactly three control plane nodes are required for production; bare metal clusters can scale up to five.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-control-plane-nodes-production.json"},{"id":"three-image-mirror-resources","text":"OpenShift has three image mirror resources: `ImageContentPolicy` (general), `ImageDigestMirrorSet` (digest-based), and `ImageTagMirrorSet` (tag-based).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-image-mirror-resources.json"},{"id":"three-image-reference-types","text":"OpenShift has three image reference types: `ImageStreamTag` (`<stream>:<tag>`), `ImageStreamImage` (`<stream>@<sha256:digest>`), and `DockerImage` (`<registry>/<namespace>/<image>:<tag>`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-image-reference-types.json"},{"id":"three-operator-roles","text":"Three distinct roles interact with Operators in OpenShift: cluster admin (install/manage), developer (consume), and Operator author (build).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/three-operator-roles.json"},{"id":"tier1-apis-must-roundtrip-without-info-loss","text":"Tier 1 APIs must round-trip between versions without information loss.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tier1-apis-must-roundtrip-without-info-loss.json"},{"id":"time-slicing-no-memory-fault-isolation","text":"GPU time-slicing has no memory or fault isolation between workloads, unlike MIG which provides full isolation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/time-slicing-no-memory-fault-isolation.json"},{"id":"timeflowrttns-srtt-nanoseconds","text":"TCP Round Trip Time (`TimeFlowRttNs`) is the Smoothed RTT (SRTT) measured in nanoseconds","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/timeflowrttns-srtt-nanoseconds.json"},{"id":"tkn-cli-for-openshift-pipelines","text":"The `tkn` CLI interacts with OpenShift Pipelines (Tekton-based CI/CD).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-cli-for-openshift-pipelines.json"},{"id":"tkn-cli-version-ocp417","text":"The tkn CLI version for OpenShift Container Platform 4.17 is 1.18.0.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-cli-version-ocp417.json"},{"id":"tkn-keep-flag-preserves-recent-runs","text":"The `--keep N` flag on `tkn pipelinerun delete` and `tkn taskrun delete` preserves the N most recently executed runs when bulk deleting.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-keep-flag-preserves-recent-runs.json"},{"id":"tkn-package-three-binaries","text":"The tkn CLI archive includes three executables: `tkn`, `tkn-pac`, and `opc`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-package-three-binaries.json"},{"id":"tkn-pipelinerun-delete-all-skips-running","text":"The `tkn pipelinerun delete --all` command does not delete pipeline run resources that are in a running state (since Pipelines 1.6).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-pipelinerun-delete-all-skips-running.json"},{"id":"tkn-task-start-requires-service-account","text":"The `tkn task start` command requires specifying a ServiceAccount via the `-s` flag.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tkn-task-start-requires-service-account.json"},{"id":"tokenreview-post-only","text":"TokenReview is a POST-only API that validates a bearer token and returns user identity information without creating persistent resources","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tokenreview-post-only.json"},{"id":"tokenreview-responses-may-be-cached","text":"TokenReview responses may be cached by the webhook token authenticator, which affects token revocation behavior.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tokenreview-responses-may-be-cached.json"},{"id":"tokenreview-results-may-be-cached","text":"TokenReview results may be cached by the webhook token authenticator in kube-apiserver","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tokenreview-results-may-be-cached.json"},{"id":"tokenreview-two-endpoints-openshift","text":"TokenReview has two endpoints in OpenShift: `/apis/authentication.k8s.io/v1/tokenreviews` (Kubernetes-native) and `/apis/oauth.openshift.io/v1/tokenreviews` (OpenShift OAuth)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tokenreview-two-endpoints-openshift.json"},{"id":"tokenreview-uid-unique-across-time","text":"A user's UID uniquely identifies them across time — if a user is deleted and recreated with the same name, the UID will differ","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tokenreview-uid-unique-across-time.json"},{"id":"topology-manager-policies","text":"Topology Manager has four policies: `none`, `best-effort`, `restricted`, `single-numa-node`; and two scopes: `container` (default) and `pod`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/topology-manager-policies.json"},{"id":"topology-manager-single-numa-strictest","text":"Topology Manager `single-numa-node` is the strictest policy — it rejects pods that cannot fit on a single NUMA node.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/topology-manager-single-numa-strictest.json"},{"id":"topology-spread-constraints-anded","text":"Pod `topologySpreadConstraints` are ANDed together — all constraints must be satisfied","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/topology-spread-constraints-anded.json"},{"id":"topology-yellow-border-quota","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/topology-yellow-border-quota.json"},{"id":"tracking-tags-single-imagestream-only","text":"Tracking tags (`--alias=true`) only work within a single image stream; cross-image-stream aliases produce an error.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tracking-tags-single-imagestream-only.json"},{"id":"trustee-attestation-component","text":"Red Hat build of Trustee is the attestation component that validates TEE integrity before releasing secrets or keys to confidential containers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/trustee-attestation-component.json"},{"id":"tuned-cr-api-version","text":"The Tuned custom resource uses API version `tuned.openshift.io/v1`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-cr-api-version.json"},{"id":"tuned-cr-namespaced-resource","text":"The Tuned CR is a namespaced resource, typically in the `openshift-cluster-node-tuning-operator` namespace","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-cr-namespaced-resource.json"},{"id":"tuned-machineconfiglabels-auto-mc","text":"Setting `machineConfigLabels` on a Tuned recommend entry triggers automatic MachineConfig creation for host-level changes like kernel boot parameters","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-machineconfiglabels-auto-mc.json"},{"id":"tuned-managed-by-node-tuning-operator","text":"The Cluster Node Tuning Operator manages Tuned CRs and deploys containerized TuneD daemons on each node","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-managed-by-node-tuning-operator.json"},{"id":"tuned-match-or-nested-and","text":"Tuned match rules at the same level are combined with logical OR; nested match rules within a match entry use logical AND","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-match-or-nested-and.json"},{"id":"tuned-match-type-defaults-node","text":"Tuned match rule `type` defaults to `node` when omitted; valid values are `node` and `pod`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-match-type-defaults-node.json"},{"id":"tuned-operator-manages-profiles","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-operator-manages-profiles.json"},{"id":"tuned-priority-zero-highest","text":"In Tuned recommend rules, priority `0` is the highest priority","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-priority-zero-highest.json"},{"id":"tuned-profile-namespaced-resource","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-profile-namespaced-resource.json"},{"id":"tuned-reapply-sysctl-config","text":"The `.spec.config.tunedConfig.reapply_sysctl` field on a Profile resource controls whether the TuneD daemon reapplies sysctl settings.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-reapply-sysctl-config.json"},{"id":"tuned-required-fields","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/tuned-required-fields.json"},{"id":"two-event-api-versions-exist","text":"Two Event API versions exist in OpenShift/Kubernetes: `v1` (core) and `events.k8s.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/two-event-api-versions-exist.json"},{"id":"two-node-cluster-distinct-topology","text":"Two-node clusters are a distinct topology from both SNO and standard HA (3+2) clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/two-node-cluster-distinct-topology.json"},{"id":"two-node-clusters-not-supported-gpu","text":"Two-node clusters are not supported for GPU workloads — must be 1 node (SNO) or 3+ nodes.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/two-node-clusters-not-supported-gpu.json"},{"id":"ubi-images-freely-redistributable","text":"Red Hat Universal Base Images (UBI) are freely redistributable without a Red Hat subscription; available in standard, init, and minimal variants.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ubi-images-freely-redistributable.json"},{"id":"udn-cr-cannot-be-modified-after-creation","text":"The ClusterUserDefinedNetwork CR and UserDefinedNetwork CR cannot be modified after creation","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-cr-cannot-be-modified-after-creation.json"},{"id":"udn-default-join-subnet-must-be-avoided","text":"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)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-default-join-subnet-must-be-avoided.json"},{"id":"udn-default-mtu-1400","text":"UDN default MTU is 1400; minimum IPv4 MTU is 576; minimum IPv6 MTU is 1280","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-default-mtu-1400.json"},{"id":"udn-dns-resolves-to-default-network","text":"Pod DNS lookups resolve to the pod's IP on the cluster default network, not the UDN","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-dns-resolves-to-default-network.json"},{"id":"udn-do-not-use-openshift-namespaces","text":"UDNs must not be created in `openshift-*` namespaces","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-do-not-use-openshift-namespaces.json"},{"id":"udn-kubelet-health-checks-use-default-network","text":"Kubelet health checks use the default network, not the primary UDN interface — a pod may appear healthy but have broken UDN connectivity","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-kubelet-health-checks-use-default-network.json"},{"id":"udn-layer2-subnets-optional-layer3-mandatory","text":"UDN Layer 2 subnets are optional; Layer 3 subnets are mandatory","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-layer2-subnets-optional-layer3-mandatory.json"},{"id":"udn-layer2-vs-layer3-topology","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-layer2-vs-layer3-topology.json"},{"id":"udn-namespace-label-required","text":"The label `k8s.ovn.org/primary-user-defined-network` must be applied to a namespace before creating a primary UDN","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-namespace-label-required.json"},{"id":"udn-preferred-over-nad-for-segmentation","text":"UserDefinedNetwork is preferred over NetworkAttachmentDefinition for network segmentation for security reasons","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-preferred-over-nad-for-segmentation.json"},{"id":"udn-requires-ovn-kubernetes","text":"User-Defined Networks (UDNs) are only supported with OVN-Kubernetes and do not work with other CNI plugins.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-requires-ovn-kubernetes.json"},{"id":"udn-tech-preview-ocp-417","text":"User-Defined Networks (UDNs) are a Technology Preview feature in OCP 4.17, not supported for production under SLAs","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/udn-tech-preview-ocp-417.json"},{"id":"unbound-pvc-waits-indefinitely","text":"PVCs remain unbound indefinitely if no matching PV exists — they do not fail, they wait.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unbound-pvc-waits-indefinitely.json"},{"id":"unformatted-volumes-auto-formatted","text":"OpenShift automatically formats unformatted volumes based on `fsType`, erasing any existing data.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unformatted-volumes-auto-formatted.json"},{"id":"unidling-only-haproxy-router","text":"Automatic unidling (restoring replicas on incoming traffic) is only supported by the default HAProxy router.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unidling-only-haproxy-router.json"},{"id":"unified-security-from-install-through-api-governance","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unified-security-from-install-through-api-governance.json"},{"id":"unsupported-config-overrides-blocks-upgrades","text":"Setting `unsupportedConfigOverrides` on OpenShift operator resources blocks cluster upgrades and is not supported by Red Hat; it must be removed before upgrading.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unsupported-config-overrides-blocks-upgrades.json"},{"id":"unsupported-field-prefix-no-guarantees","text":"API fields prefixed with `unsupported<FieldName>` have zero compatibility guarantees across or within releases.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unsupported-field-prefix-no-guarantees.json"},{"id":"unsupportedconfigoverrides-blocks-upgrades","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/unsupportedconfigoverrides-blocks-upgrades.json"},{"id":"update-channel-promotion-order","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/update-channel-promotion-order.json"},{"id":"update-channels-production","text":"Production OCP clusters must use `stable-*`, `eus-*`, or `fast-*` update channels; `candidate-*` is not for production","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/update-channels-production.json"},{"id":"update-prereqs-checklist","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/update-prereqs-checklist.json"},{"id":"update-strategy-canary-and-control-plane-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/update-strategy-canary-and-control-plane-model.json"},{"id":"upgradeable-false-blocks-minor-only","text":"When a ClusterOperator's `Upgradeable` condition is `False`, the CVO prevents minor version updates unless forced; patch/z-stream updates are not blocked.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/upgradeable-false-blocks-minor-only.json"},{"id":"upgradeable-to-annotation-unblocks-minor-update","text":"The `upgradeable-to` annotation must be set on the `CloudCredential` resource via `oc annotate cloudcredential cluster cloudcredential.openshift.io/upgradeable-to=<version>` to unblock minor version updates for manually maintained credential clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/upgradeable-to-annotation-unblocks-minor-update.json"},{"id":"upi-no-default-storage-class","text":"User-Provisioned Infrastructure (UPI) requires manual provisioning of load balancer, DNS, and storage; default storage classes are NOT defined.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/upi-no-default-storage-class.json"},{"id":"use-exec-in-wrapper-scripts","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/use-exec-in-wrapper-scripts.json"},{"id":"use-more-secure-service-ca-one-way","text":"The `useMoreSecureServiceCA` field on KubeControllerManager is a one-way toggle — once set to true, it cannot be reverted to false","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/use-more-secure-service-ca-one-way.json"},{"id":"user-api-group-user-openshift-io","text":"OpenShift Users are a separate `user.openshift.io/v1` API resource, distinct from Kubernetes ServiceAccounts","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-api-group-user-openshift-io.json"},{"id":"user-created-automatically-on-first-login","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-created-automatically-on-first-login.json"},{"id":"user-defined-monitoring-not-default","text":"Monitoring for user-defined projects is not enabled by default; a cluster administrator must explicitly enable it after installation","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-defined-monitoring-not-default.json"},{"id":"user-group-api-resources","text":"The `user.openshift.io/v1` API group contains User, Identity, Group, and UserIdentityMapping resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-group-api-resources.json"},{"id":"user-groups-field-deprecated","text":"The `groups` array field on the User object is deprecated; the recommended approach is to create separate Group objects that reference users.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-groups-field-deprecated.json"},{"id":"user-identity-mapping-architecture","text":"Identity objects link external authentication identities to internal User objects; one user can have multiple identities from different providers","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-identity-mapping-architecture.json"},{"id":"user-workload-monitoring-opt-in","text":"User workload monitoring must be explicitly enabled; core platform monitoring is always on by default.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/user-workload-monitoring-opt-in.json"},{"id":"useridentitymapping-maps-user-to-identity","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/useridentitymapping-maps-user-to-identity.json"},{"id":"useridentitymapping-no-list-operation","text":"There is no LIST endpoint for UserIdentityMapping resources, unlike most other API resources.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/useridentitymapping-no-list-operation.json"},{"id":"usernames-unique-with-suffix-on-collision","text":"Usernames in OpenShift must be unique and are derived from the identity provider; if a collision occurs, a numeric suffix may be appended.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/usernames-unique-with-suffix-on-collision.json"},{"id":"useroauthaccesstoken-delete-revokes-token","text":"Users can delete their own access tokens via the UserOAuthAccessToken API to revoke them.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/useroauthaccesstoken-delete-revokes-token.json"},{"id":"useroauthaccesstoken-virtual-resource","text":"UserOAuthAccessToken is a virtual (non-persisted) resource that mirrors OAuthAccessTokens scoped to the token's owner, allowing users to view/manage their own tokens.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/useroauthaccesstoken-virtual-resource.json"},{"id":"v1alpha1-apis-default-tier4","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/v1alpha1-apis-default-tier4.json"},{"id":"validating-admission-policy-uses-cel","text":"ValidatingAdmissionPolicy uses CEL (Common Expression Language) for in-process validation without requiring an external webhook service.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/validating-admission-policy-uses-cel.json"},{"id":"validating-webhook-cannot-modify-objects","text":"ValidatingWebhookConfiguration can only accept or reject requests — it cannot modify objects","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/validating-webhook-cannot-modify-objects.json"},{"id":"validating-webhook-sideeffects-values","text":"ValidatingWebhookConfiguration `sideEffects` accepts values `None`, `NoneOnDryRun`, `Some`, or `Unknown`; dry-run requests are auto-rejected if sideEffects is `Some` or `Unknown`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/validating-webhook-sideeffects-values.json"},{"id":"vdu-chronyd-disabled-ptp-used","text":"Chronyd must be stopped and disabled on vDU cluster nodes; PTP provides time synchronization instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-chronyd-disabled-ptp-used.json"},{"id":"vdu-crun-oci-runtime","text":"crun is enabled as the OCI container runtime for vDU clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-crun-oci-runtime.json"},{"id":"vdu-default-operatorhub-sources-disabled","text":"Default OperatorHub sources must be disabled (`disableAllDefaultSources: true`) on vDU clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-default-operatorhub-sources-disabled.json"},{"id":"vdu-firmware-cstates-c0-c1-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-firmware-cstates-c0-c1-only.json"},{"id":"vdu-firmware-uefi-sriov-vtd-required","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-firmware-uefi-sriov-vtd-required.json"},{"id":"vdu-module-blacklist-irdma-required","text":"`module_blacklist=irdma` is a required kernel argument for vDU clusters.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-module-blacklist-irdma-required.json"},{"id":"vdu-required-operators","text":"Required Operators for vDU workloads on SNO: Node Tuning Operator, PTP Operator, SR-IOV Network Operator, OpenShift Logging Operator, and Local Storage Operator.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-required-operators.json"},{"id":"vdu-sno-minimum-hardware","text":"Minimum hardware for vDU SNO: 4-8 vCPU, 32GB RAM, 120GB storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-sno-minimum-hardware.json"},{"id":"vdu-stalld-service-enabled","text":"The stalld service must be enabled in the Tuned CR for real-time vDU workloads.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-stalld-service-enabled.json"},{"id":"vdu-tuned-include-references-performanceprofile","text":"The Tuned CR `include` line must reference the associated PerformanceProfile name using the pattern `openshift-node-performance-${PerformanceProfile.metadata.name}`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-tuned-include-references-performanceprofile.json"},{"id":"vdu-web-console-disabled","text":"The OpenShift web console must be disabled (`managementState: Removed`) on vDU clusters to reduce resource usage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vdu-web-console-disabled.json"},{"id":"vector-default-log-collector","text":"Vector has replaced Fluentd as the default log collector in OpenShift.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vector-default-log-collector.json"},{"id":"version-coupling-and-update-governance","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/version-coupling-and-update-governance.json"},{"id":"virt-image-provisioning-pipeline","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-image-provisioning-pipeline.json"},{"id":"virt-live-migration-fully-operational","text":"VM live migration is fully operational when RWX storage and dedicated migration network are provisioned.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-live-migration-fully-operational.json"},{"id":"virt-live-migration-operational","text":"VM live migration is fully operational with RWX storage, dedicated Multus network, and no blocking constraints from GPU passthrough or single-node topology.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-live-migration-operational.json"},{"id":"virt-live-migration-storage-and-network-prerequisites","text":"VM live migration requires both RWX storage (RWO blocks migration) and a dedicated Multus network, making it a feature that demands specific infrastructure provisioning.","truth_value":"IN","justification_count":1,"dependent_count":4,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-live-migration-storage-and-network-prerequisites.json"},{"id":"virt-migration-depends-on-cni-and-storage-stack","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-migration-depends-on-cni-and-storage-stack.json"},{"id":"virt-migration-end-to-end-operational","text":"VM live migration is end-to-end operational across the full infrastructure stack — from CNI networking through storage to topology validation — only when no GPU passthrough, IPv6-only, or vTPM constraints apply and the cluster is multi-node.","truth_value":"OUT","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-migration-end-to-end-operational.json"},{"id":"virt-migration-excluded-on-constrained-topologies","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-migration-excluded-on-constrained-topologies.json"},{"id":"virt-migration-requires-full-stack-and-topology","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-migration-requires-full-stack-and-topology.json"},{"id":"virt-requires-governed-infrastructure-stack","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-requires-governed-infrastructure-stack.json"},{"id":"virt-validates-full-governed-platform","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virt-validates-full-governed-platform.json"},{"id":"virtctl-addvolume-persist-flag","text":"The `--persist` flag on `virtctl addvolume` permanently mounts the disk; it applies only to VMs, not VMIs.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virtctl-addvolume-persist-flag.json"},{"id":"virtctl-guestfs-virt-sysprep","text":"`virtctl guestfs` deploys a libguestfs container for VM disk manipulation; `virt-sysprep` seals a VM disk image as a template.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virtctl-guestfs-virt-sysprep.json"},{"id":"virtctl-installed-separately","text":"`virtctl` is installed separately from the OpenShift CLI — downloaded from the web console or via RPM (`kubevirt-virtctl` package on RHEL 8).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/virtctl-installed-separately.json"},{"id":"volume-snapshot-api-objects","text":"OCP supports VolumeSnapshot, VolumeSnapshotContent, and VolumeSnapshotClass API objects for point-in-time storage copies.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volume-snapshot-api-objects.json"},{"id":"volumeattachment-cluster-scoped","text":"VolumeAttachment objects are non-namespaced (cluster-scoped) resources in the `storage.k8s.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumeattachment-cluster-scoped.json"},{"id":"volumeattachment-only-external-attacher-sets-status","text":"Only the external-attacher should set `status.attached` and `attachmentMetadata` on VolumeAttachment — not users or other controllers.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumeattachment-only-external-attacher-sets-status.json"},{"id":"volumeattachment-spec-three-required-fields","text":"VolumeAttachment `spec` requires three sub-fields: `attacher` (CSI driver name), `source` (volume reference), and `nodeName`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumeattachment-spec-three-required-fields.json"},{"id":"volumesnapshot-apis-ga-v1","text":"VolumeSnapshot, VolumeSnapshotClass, and VolumeSnapshotContent are all GA at `snapshot.storage.k8s.io/v1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshot-apis-ga-v1.json"},{"id":"volumesnapshotcontent-api-group","text":"VolumeSnapshotContent is in the `snapshot.storage.k8s.io/v1` API group.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-api-group.json"},{"id":"volumesnapshotcontent-bidirectional-binding","text":"VolumeSnapshotContent requires bidirectional binding: VolumeSnapshotContent references VolumeSnapshot via `volumeSnapshotRef`, and VolumeSnapshot references VolumeSnapshotContent via `spec.volumeSnapshotContentName`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-bidirectional-binding.json"},{"id":"volumesnapshotcontent-cluster-scoped-snapshot-namespaced","text":"VolumeSnapshotContent is cluster-scoped (no namespace), while VolumeSnapshot is namespaced.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-cluster-scoped-snapshot-namespaced.json"},{"id":"volumesnapshotcontent-deletion-policies","text":"VolumeSnapshotContent has two deletion policies: `Retain` (keep physical snapshot) and `Delete` (remove both object and physical snapshot).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-deletion-policies.json"},{"id":"volumesnapshotcontent-restore-size-minimum","text":"When restoring a volume from a snapshot, the volume size must not be smaller than `restoreSize` from the VolumeSnapshotContent status.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-restore-size-minimum.json"},{"id":"volumesnapshotcontent-source-immutable","text":"The VolumeSnapshotContent `source` field is immutable after creation; it uses either `volumeHandle` (dynamic) or `snapshotHandle` (pre-existing), which are mutually exclusive.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/volumesnapshotcontent-source-immutable.json"},{"id":"vpa-adjusts-requests-limits","text":"VerticalPodAutoscaler (VPA) adjusts resource requests and limits on pods rather than scaling replica count.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vpa-adjusts-requests-limits.json"},{"id":"vrf-cni-allows-ip-overlap","text":"The CNI VRF plugin allows overlapping IP addresses with the OpenShift cluster's main network CIDR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-cni-allows-ip-overlap.json"},{"id":"vrf-layer3-only","text":"VRF (Virtual Routing and Forwarding) operates at OSI Layer 3 only and does not affect Layer 2 protocols such as LLDP.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-layer3-only.json"},{"id":"vrf-only-works-with-netdevice-type","text":"VRF functions correctly only when the resource is of type `netdevice`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-only-works-with-netdevice-type.json"},{"id":"vrf-plugin-must-be-second-in-chain","text":"The CNI VRF plugin must be the second plugin in a chained CNI configuration, after the base network plugin (e.g., macvlan)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-plugin-must-be-second-in-chain.json"},{"id":"vrf-requires-so-bindtodevice-not-ip-vrf-exec","text":"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","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-requires-so-bindtodevice-not-ip-vrf-exec.json"},{"id":"vrf-table-param-optional-auto-assigned","text":"The VRF plugin `table` parameter is optional; the CNI plugin auto-assigns a free routing table ID if omitted","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vrf-table-param-optional-auto-assigned.json"},{"id":"vsphere-default-snapshot-limit-3","text":"The default vSphere snapshot limit per block volume in ClusterCSIDriver is 3; increasing above 3 impacts performance.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-default-snapshot-limit-3.json"},{"id":"vsphere-failure-domains-tag-categories","text":"vSphere failure domains require vCenter tag categories named exactly `openshift-region` and `openshift-zone` for region/zone mapping","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-failure-domains-tag-categories.json"},{"id":"vsphere-storage-driver-csi-migration-irreversible","text":"The `vsphereStorageDriver` field set to `CSIWithMigrationDriver` is irreversible and is the current default; the field itself is deprecated","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-storage-driver-csi-migration-irreversible.json"},{"id":"vsphere-supported-install-platform","text":"VMware vSphere is a supported installation platform for OpenShift Container Platform.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-supported-install-platform.json"},{"id":"vsphere-supports-ipi-and-upi","text":"OpenShift supports both installer-provisioned infrastructure (IPI) and user-provisioned infrastructure (UPI) installation methods on vSphere.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-supports-ipi-and-upi.json"},{"id":"vsphere-vgpu-limits","text":"vSphere 7.0 supports max 4 vGPU per VM; vSphere 8.0 supports max 8 vGPU per VM and adds heterogeneous profile support.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/vsphere-vgpu-limits.json"},{"id":"waitforfirstconsumer-delays-binding","text":"`volumeBindingMode: WaitForFirstConsumer` delays PV binding until a pod using the PVC is scheduled, enabling topology-aware provisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/waitforfirstconsumer-delays-binding.json"},{"id":"watch-endpoints-deprecated","text":"Watch-specific API endpoints (e.g., `/watch/...`) are deprecated — the `watch` query parameter on list operations should be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/watch-endpoints-deprecated.json"},{"id":"watch-endpoints-deprecated-use-list-param","text":"Dedicated watch endpoints (e.g., `/watch/apiservices`) are deprecated in favor of using the `watch` query parameter on list operations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/watch-endpoints-deprecated-use-list-param.json"},{"id":"watch-endpoints-deprecated-use-parameter","text":"Watch endpoints (`/watch/...`) are deprecated; the `watch` parameter on list operations should be used instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/watch-endpoints-deprecated-use-parameter.json"},{"id":"watch-endpoints-deprecated-use-query-param","text":"Dedicated `/watch/` API endpoints are deprecated across Kubernetes APIs; the `watch` query parameter on list operations should be used instead.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/watch-endpoints-deprecated-use-query-param.json"},{"id":"watch-endpoints-deprecated-use-watch-param","text":"The dedicated `/watch/` endpoints for User and Identity resources are deprecated; the correct approach is to use the `watch` query parameter on list operations.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/watch-endpoints-deprecated-use-watch-param.json"},{"id":"wavelength-zone-iam-permissions","text":"AWS Wavelength Zones require three IAM permissions: ec2:ModifyAvailabilityZoneGroup, ec2:CreateCarrierGateway, and ec2:DeleteCarrierGateway.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/wavelength-zone-iam-permissions.json"},{"id":"wavelength-zone-requires-carrier-gateway","text":"AWS Wavelength Zones require a carrier gateway for connectivity between the Wavelength Zone and the carrier network; Local Zones do not.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/wavelength-zone-requires-carrier-gateway.json"},{"id":"web-console-admin-developer-perspectives","text":"The OpenShift web console supports both an Administrator perspective and a Developer perspective","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-console-admin-developer-perspectives.json"},{"id":"web-terminal-admin-project-openshift-terminal","text":"Cluster admins' DevWorkspace CRs are always created in the `openshift-terminal` project and cannot choose another","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-admin-project-openshift-terminal.json"},{"id":"web-terminal-devworkspace-dependency","text":"The DevWorkspace Operator is automatically installed as a dependency of the Web Terminal Operator and should not be installed separately","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-devworkspace-dependency.json"},{"id":"web-terminal-network-policy-namespaces","text":"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\"","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-network-policy-namespaces.json"},{"id":"web-terminal-operator-namespace","text":"The Web Terminal Operator is installed in the `openshift-operators` namespace with All namespaces scope","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-operator-namespace.json"},{"id":"web-terminal-operator-ocp47","text":"The embedded web terminal in the console requires the Web Terminal Operator and is available from OCP 4.7+","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-operator-ocp47.json"},{"id":"web-terminal-preinstalled-cli-tools","text":"The Web Terminal includes pre-installed CLI tools: `oc`, `kubectl`, `odo`, `kn`, `tkn`, `helm`, `subctl`","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-preinstalled-cli-tools.json"},{"id":"web-terminal-uninstall-requires-manual-cleanup","text":"Uninstalling the Web Terminal Operator does NOT automatically remove CRDs or managed resources — manual cleanup of DevWorkspace CRDs and webhooks is required","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-uninstall-requires-manual-cleanup.json"},{"id":"web-terminal-webhook-removal-breaks-oc-exec","text":"Removing the `devworkspace-webhook-server` deployment without removing the associated mutating/validating webhooks causes `oc exec` commands to fail cluster-wide","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/web-terminal-webhook-removal-breaks-oc-exec.json"},{"id":"webhook-admission-enforcement-model","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":2,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-admission-enforcement-model.json"},{"id":"webhook-auth-requires-type-none","text":"The `spec.webhookTokenAuthenticator` field on the Authentication resource can only be set when `spec.type` is `None`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-auth-requires-type-none.json"},{"id":"webhook-communication-requires-tls","text":"Communication between the webhook admission plugin and the webhook server must use TLS.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-communication-requires-tls.json"},{"id":"webhook-config-resource-kinds","text":"The two webhook configuration resource kinds are `MutatingWebhookConfiguration` and `ValidatingWebhookConfiguration` in API group `admissionregistration.k8s.io/v1beta1`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-config-resource-kinds.json"},{"id":"webhook-failure-policy-default-fail","text":"The `failurePolicy` for admission webhooks defaults to `Fail`, meaning an unreachable webhook rejects the request","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-failure-policy-default-fail.json"},{"id":"webhook-failure-policy-options","text":"Webhook `failurePolicy` can be set to `Fail` (deny on error) or `Ignore` (accept on error); `Ignore` unconditionally accepts requests when the webhook is unavailable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-failure-policy-options.json"},{"id":"webhook-match-conditions-cel-max-64","text":"Webhook `matchConditions` use CEL expressions to filter requests, with a maximum of 64 conditions per webhook","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-match-conditions-cel-max-64.json"},{"id":"webhook-match-policy-default-equivalent","text":"Webhook `matchPolicy` defaults to `Equivalent`, converting requests across API group versions to match rules","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-match-policy-default-equivalent.json"},{"id":"webhook-max-timeout-13-seconds","text":"The maximum webhook admission plugin timeout is 13 seconds and cannot be changed.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-max-timeout-13-seconds.json"},{"id":"webhook-never-invoked-on-own-kind","text":"Mutating and Validating webhook configurations are never called on admission requests for their own kind to prevent unrecoverable cluster states","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-never-invoked-on-own-kind.json"},{"id":"webhook-reinvocation-policy-ifneeded-idempotent","text":"Webhook `reinvocationPolicy: IfNeeded` re-calls the webhook if other admission plugins mutate the object afterward, and requires the webhook logic to be idempotent","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-reinvocation-policy-ifneeded-idempotent.json"},{"id":"webhook-required-fields","text":"Each admission webhook entry requires four fields: `name`, `clientConfig`, `sideEffects`, and `admissionReviewVersions`","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-required-fields.json"},{"id":"webhook-service-port-default-443","text":"The `port` field in a webhook `clientConfig.service` reference defaults to 443","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-service-port-default-443.json"},{"id":"webhook-timeout-default-10-range-1-30","text":"Admission webhook `timeoutSeconds` defaults to 10 and must be between 1–30 seconds","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-timeout-default-10-range-1-30.json"},{"id":"webhook-token-authenticators-plural-deprecated","text":"The `spec.webhookTokenAuthenticators` (plural) field on the Authentication resource is deprecated and setting it has no effect.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-token-authenticators-plural-deprecated.json"},{"id":"webhook-url-must-use-https","text":"The `url` field in webhook `clientConfig` must use HTTPS; in-cluster webhooks should use the `service` field instead","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhook-url-must-use-https.json"},{"id":"webhooks-called-in-parallel","text":"Webhooks within each admission phase (mutating or validating) are called in parallel, not sequentially; all must approve or the request is denied.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/webhooks-called-in-parallel.json"},{"id":"whereabouts-ipam-cluster-wide","text":"Whereabouts IPAM provides cluster-wide IP address management with overlap detection, unlike host-local which is node-scoped only.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/whereabouts-ipam-cluster-wide.json"},{"id":"whereabouts-ipam-secondary-networks","text":"The Whereabouts CNI plugin provides cluster-wide IPAM for secondary/additional pod networks, typically used with Multus CNI, preventing IP conflicts across nodes","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/whereabouts-ipam-secondary-networks.json"},{"id":"whereabouts-overlapping-range-ip-reservation","text":"OverlappingRangeIPReservation (`whereabouts.cni.cncf.io/v1alpha1`) tracks IP reservations across overlapping IP ranges used by multiple NetworkAttachmentDefinitions, with a required `podref` field","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/whereabouts-overlapping-range-ip-reservation.json"},{"id":"windows-containers-ovn-hybrid-networking","text":"OVN-Kubernetes with hybrid networking is required for Windows container support in OpenShift","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/windows-containers-ovn-hybrid-networking.json"},{"id":"windows-containers-wmco-managed","text":"Windows container support in OpenShift is managed by the Windows Machine Config Operator (WMCO)","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/windows-containers-wmco-managed.json"},{"id":"windows-node-architectural-divergence","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/windows-node-architectural-divergence.json"},{"id":"windows-nodes-not-crio","text":"Windows nodes use the Windows container runtime rather than CRI-O","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/windows-nodes-not-crio.json"},{"id":"windows-nodes-worker-only","text":"Windows nodes in OpenShift function as worker nodes only — control plane nodes must be Linux","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/windows-nodes-worker-only.json"},{"id":"worker-ignition-port-22623","text":"Worker Ignition configs reference the bootstrap/control plane via `https://api.<cluster>:22623/config/worker`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/worker-ignition-port-22623.json"},{"id":"worker-latency-profile-three-values","text":"`workerLatencyProfile` has three values: `Default`, `MediumUpdateAverageReaction`, and `LowUpdateSlowReaction`, progressively tolerating higher network latency between workers and control plane","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/worker-latency-profile-three-values.json"},{"id":"worker-node-csr-approval-required","text":"Pending CSRs must be approved for worker nodes to join the cluster, using `oc get csr` followed by `oc adm certificate approve <csr_name>`.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/worker-node-csr-approval-required.json"},{"id":"workload-availability-separate-product","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-availability-separate-product.json"},{"id":"workload-availability-three-pillars","text":"The three pillars of Workload Availability are remediation (automated recovery), fencing (isolating failed nodes), and maintenance (controlled node drain/downtime).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-availability-three-pillars.json"},{"id":"workload-partitioning-cpupartitioningmode-allnodes","text":"Workload partitioning is enabled by setting `cpuPartitioningMode: AllNodes` in the SiteConfig CR.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-partitioning-cpupartitioningmode-allnodes.json"},{"id":"workload-partitioning-install-time-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-partitioning-install-time-only.json"},{"id":"workload-placement-requires-storage-and-scheduling","text":"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.","truth_value":"IN","justification_count":1,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-placement-requires-storage-and-scheduling.json"},{"id":"workload-type-mapping","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/workload-type-mapping.json"},{"id":"xpaas-images-openshift-suffix","text":"xPaaS middleware images are suffixed with `-openshift` (e.g., `registry.redhat.io/jboss-eap-6/eap64-openshift`).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/xpaas-images-openshift-suffix.json"},{"id":"z-stream-no-breaking-changes","text":"Z-stream releases never break API or AOE compatibility except for critical security issues.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/z-stream-no-breaking-changes.json"},{"id":"zero-trust-cluster-ca-created-at-install","text":"OpenShift creates a cluster CA at installation time as the root of trust for service certificates.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/zero-trust-cluster-ca-created-at-install.json"},{"id":"zero-trust-ipsec-ovn-kubernetes-pod-to-pod","text":"OVN-Kubernetes supports transparent pod-to-pod IPsec encryption and north-south egress IPsec encryption.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/zero-trust-ipsec-ovn-kubernetes-pod-to-pod.json"},{"id":"zero-trust-no-app-code-changes-required","text":"Zero trust capabilities (IPsec, mTLS via mesh, NetworkPolicy) can be added without changing application code.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/zero-trust-no-app-code-changes-required.json"},{"id":"zero-trust-service-cert-26mo-ttl-13mo-rotate","text":"OpenShift service certificates have a 26-month TTL and are automatically rotated at 13 months.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/zero-trust-service-cert-26mo-ttl-13mo-rotate.json"},{"id":"zero-trust-service-mesh-provides-mtls-jwt-spiffe","text":"OpenShift Service Mesh provides transparent mTLS, L4/L7 authorization, JWT request authentication, and SPIFFE attestation.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/zero-trust-service-mesh-provides-mtls-jwt-spiffe.json"},{"id":"ztp-cluster-labels-policy-binding","text":"Cluster labels `common: true`, `group-du-sno: \"\"`, and `sites: \"example-sno\"` control which PolicyGenerator policies bind to which clusters in the ZTP hierarchy.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-cluster-labels-policy-binding.json"},{"id":"ztp-clustergroupupgrade-auto-created-ztp-install-namespace","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-clustergroupupgrade-auto-created-ztp-install-namespace.json"},{"id":"ztp-clusters-app-noncascaded-policies-cascaded-delete","text":"During ZTP upgrade, the `clusters` app uses non-cascaded delete (preserves resources) while the `policies` app uses cascaded delete (removes old policies).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-clusters-app-noncascaded-policies-cascaded-delete.json"},{"id":"ztp-cpu-partitioning-mode-install-time-only","text":"`cpuPartitioningMode: AllNodes` must be set at install time for workload partitioning — it cannot be changed post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-cpu-partitioning-mode-install-time-only.json"},{"id":"ztp-crsuppression-triggers-deprovisioning","text":"The `crSuppression` field in SiteConfig prevents generation of specific CRs (e.g., `BareMetalHost`) to trigger node deprovisioning; removing the suppression and pushing triggers reprovisioning.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-crsuppression-triggers-deprovisioning.json"},{"id":"ztp-done-label-protects-clusters-during-upgrade","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-done-label-protects-clusters-during-upgrade.json"},{"id":"ztp-done-label-signals-completion","text":"The `ztp-done` label is applied to a managed cluster when all ZTP policies become Compliant, signaling ZTP completion.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-done-label-signals-completion.json"},{"id":"ztp-extra-manifests-at-install-more-efficient","text":"Including MachineConfig CRs at install time via extra manifests is more efficient than applying them post-install.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-extra-manifests-at-install-more-efficient.json"},{"id":"ztp-node-deletion-annotation","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-node-deletion-annotation.json"},{"id":"ztp-pattern-edge-fleet-management","text":"Zero Touch Provisioning (ZTP) with GitOps is a common pattern for managing fleets of edge clusters at scale.","truth_value":"IN","justification_count":0,"dependent_count":1,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-pattern-edge-fleet-management.json"},{"id":"ztp-phase-labels-running-done","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-phase-labels-running-done.json"},{"id":"ztp-plugin-v411-daemon-selector-master-only","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-plugin-v411-daemon-selector-master-only.json"},{"id":"ztp-policies-default-inform-remediation","text":"ZTP creates all policies with `remediation action: inform` by default — RHACM reports compliance but TALM enforces the changes, not RHACM directly.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-policies-default-inform-remediation.json"},{"id":"ztp-primary-mechanism-edge-provisioning","text":"GitOps Zero Touch Provisioning (ZTP) is OpenShift's designated approach for provisioning and managing far-edge sites at scale.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-primary-mechanism-edge-provisioning.json"},{"id":"ztp-registries-conf-scoped-by-repository","text":"Registries in the mirror `registries.conf` must be scoped by repository, not by registry.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-registries-conf-scoped-by-repository.json"},{"id":"ztp-secrets-namespace-must-match-cluster-name","text":"BMC credentials secret and pull secret must be in a namespace matching the cluster name from SiteConfig.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-secrets-namespace-must-match-cluster-name.json"},{"id":"ztp-site-generate-e-flag-machineconfig-only","text":"The `-E` flag with `generator install` generates only MachineConfig CRs from the SiteConfig.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-site-generate-e-flag-machineconfig-only.json"},{"id":"ztp-site-generate-two-modes","text":"The `ztp-site-generate` container has two generator modes: `generator install` (Day 0 installation CRs) and `generator config` (Day 2 configuration CRs).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-site-generate-two-modes.json"},{"id":"ztp-siteconfig-inclusiondefault-values","text":"SiteConfig `extraManifests.filter.inclusionDefault` has two values: `include` (default, apply all then selectively exclude) and `exclude` (apply none then selectively include).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-siteconfig-inclusiondefault-values.json"},{"id":"ztp-siteconfig-searchpaths-supersedes-extramanifestpath","text":"`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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-siteconfig-searchpaths-supersedes-extramanifestpath.json"},{"id":"ztp-upgraded-policies-inform-mode-not-auto-pushed","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-upgraded-policies-inform-mode-not-auto-pushed.json"},{"id":"ztp-wave-annotations-same-policy","text":"All CRs in the same ZTP policy must share the same `ztp-deploy-wave` annotation value; fewer policies means faster deployment.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null,"url":"/public/openshift-expert/belief/ztp-wave-annotations-same-policy.json"}],"count":3820}