{"results":[{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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},{"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}],"count":333,"limit":20,"offset":0}