Known issues and limitations

Edit online

This section provides information about known issues and limitations that you might encounter using IBM® Sovereign Core. Information and a workaround is provided to help you to resolve any issues.

Known Issues

Table 1. Pipeline and Deployment
Issue Symptoms Workaround
ArgoCD pipeline Service tasks fail, health state degrade, and health check pods terminate Pipeline failure ArgoCD
Webhook connection Pipeline run fails with an internal webhook connection error Resolving pipeline run failure with webhook connection error
Table 2. IBM Verify Identity Access (IVIA)
Issue Symptoms Workaround
IVIA configuration service instability Installation pipelines and pods fail because ofivia-config service IVIA configuration service instability
IVIA deployment failures (partial or stale state) Service job cannot sync, database migration failures, corrupted application state in Argo CD, or setup job returns invalid status code response Resolving IVIA deployment failures with partial or stale state includes full cleanup and redeployment steps.
IVIA runtime configuration failures Setup job returns an invalid status code response requiring targeted recovery Resolving IVIA runtime configuration failures includes targeted recovery steps and links to full cleanup procedure.
Table 3. Observability
Issue Symptoms Workaround
ODF configuration StorageCluster remains in Progressing state, Network connectivity issues, and common error messages ODF external storage
TempoStack Tempo pods fail, OpenTelemetry Collector pod returns 403 errors, Tempo pods enter CrashLoopBackOff, and sizing issues Tempo tracing issues
ACM observability Observability stack deploys to managed clusters, existing policies issues ACM observability label-based deployment
ClusterLogForwarder namespace configuration Increased log volume ClusterLogForwarder namespace filter configuration
ACM Policy status unknown Policy status displays as "unknown" on the hub cluster and is not being propagated from the managed cluster (spoke) Observability ACM and Perses issues
Perses Datasource missing Perses Datasource resource is not found in the observability namespace, preventing proper monitoring and visualization Observability ACM and Perses issues
LokiStack Loki ingester pod fails to reach ready state or in crash loop status, missing CA bundle, pending or degraded state, and sizing issues LokiStack issues
Network observability pod netobserv-ebpf agent pods andflowlogs-pipeline pods remain in the ContainerCreating state Network observability pod issues for ContainerCreating state
NetObserv plugin Cannot access the NetBox URL, cannot allocate IP from prefix. Secrets, prefix, and tenant not found NetObserv plugin ContainerCreating error
SystemMemoryExceedsReservation alerts Repeated SystemMemoryExceedsReservation alerts, system components consuming nearly all allocated systemReserved memory, and system memory usage of approximately 1.2–1.4 GiB exceeds 95% of reserved memory SystemMemoryExceedsReservation alerts
Table 4. Services
Issue Symptoms Workaround
AI inference service Argo CD errors and external model provider limitation AI inference service issues and limitations
Datastore service PostgreSQL pod does not start, PostgreSQL layer cannot connect, Postgres Operator deployment fails to reach running state, and redeployment fails Datastore service issues
AI agent service The documentation agent cannot load a PDF of over 150 pages. Upload only PDFs of less than 150 pages to ensure the agent works.
Table 5. Compliance center
Issue Symptoms Workaround
CVE data visibility CVE data may not be visible immediately after installation, and the vulnerabilities view appears empty even when the Red Hat plugin is enabled and configured correctly Compliance Center CVE visibility issues
Compliance mappings missing for 20 catalogs Mapped assessments cannot be created for 20 affected catalogs, and these catalogs do not appear as available options when creating mapped assessments Compliance mappings pending publication for 20 catalogs
Other known issues include the following:

Limitations

Installation and deployment limitations

DHCP not supported for cluster nodes

Limitation: Dynamic Host Configuration Protocol (DHCP) is not supported for cluster nodes. Static IP addressing must be used for all cluster nodes.

Failed pods from previous deployment attempts are not automatically cleaned

Limitation: During deployment operations in the Sovereign Platform, when pods fail during initial deployment attempts but the deployment eventually succeeds, the failed pods are not automatically cleaned.

Symptoms: This results in multiple pods showing "Error" status in the cluster, even though the application is running correctly with healthy pods.

User Experience: Users see multiple failed pods in their cluster monitoring, causing confusion and concern about deployment health.

Resolution: This is a known limitation of the current deployment process. Users need to understand that failed pods from previous deployment attempts are expected behavior and do not indicate a problem with the current deployment state. The presence of these error-state pods does not affect the functionality of the successfully deployed application.

Storage limitations

LVM and CEPH storage for non-production deployments only

Limitation: LVM and CEPH storage are not supported in IBM Sovereign Core for production environments. These storage solutions are suitable for non-production deployments only. For production environments, use alternative storage solutions that meet the performance and reliability requirements.

Authentication and security limitations

SSL certificates required for API and Ingress
Limitation: Valid SSL certificates must be provided for both API and Ingress endpoints:
  • API Certificate: private key and full certificate for api.<cluster-name>.<base-domain>
  • Ingress Certificate: private key and full certificate for *.apps.<cluster-name>.<base-domain>
Services do not automatically reload certificates

Limitation: Services in IBM Sovereign Core do not have a hot reload mechanism for certificates stored in secrets. When certificates are rotated or updated, the services do not automatically pick up the new certificates.

Impact: After certificate rotation, administrators must manually restart the affected pods to ensure they use the updated certificates.

Resolution: Use the pod restart script described in the certificate rotation documentation. For more information, see Rotate certificates on demand.

Clair vulnerability scanner uses HTTP for internal communication
Limitation: Clair, when managed by the Quay Operator, is architecturally designed to run on HTTP (port 8089) internally. It cannot be directly configured for HTTPS because:
  • The Clair application natively listens only on HTTP
  • No TLS certificates are provisioned or configured for Clair
  • The operator-managed deployment lacks built-in HTTPS support
Risk Assessment: The HTTP-only internal communication presents minimal security risk in this context because:
  • Network Isolation: Clair operates within the Kubernetes cluster's internal network, isolated from external access
  • Service-to-Service Communication: Traffic between Quay and Clair travels over internal Kubernetes services, not exposed to external networks
  • Defense in Depth: External access is already secured via HTTPS through the Red Hat OpenShift route
Architecture: Red Hat's recommended architecture follows a layered security approach:
  • External Layer: HTTPS via Red Hat OpenShift route (encrypted, authenticated)
  • Internal Layer: HTTP between Quay and Clair (isolated, cluster-internal)
Note: While HTTP lacks encryption, the risk is mitigated by cluster network isolation. The security boundary is at the cluster edge (HTTPS route), not between internal services. This is an accepted trade-off in Red Hat's design, prioritizing operational simplicity over encrypting already-isolated internal traffic.