Troubleshooting Open Integration Deployment Issues

The following table lists the common Open Integration deployment issues and possible resolutions:

Issue	Resolution
Infrastructure creation fails	Verify registry credentials, GitOps repository access, Helm repository access, Kubernetes permissions, namespace, OCI access, and operator prerequisites.
Git registration fails	Verify the URL and protocol, credentials, SSH key path, optional CA certificate path, and network access from the SCM host.
Template upload returns no new commit	The target files already match the SCM starter templates in the selected branch and directory.
Template upload fails	Confirm the git_id, branch name, relative directory, repository write permission, and customer Git network access.
Sync upload rejects files	Check the file extension, file size, and whether the file is empty.
Deployment payload is rejected	Confirm name, infra_id, git_id, branch, relative directory, keystore and truststore paths, passwords, and Coherence fields.
Image builder cannot clone customer Git	Check siebel-openint-git-secrets, the /git-secrets mount, the generated git.json, and the image-builder pod logs.
Image builder cannot find Open Integration files	Confirm that git_openint_branch and git_openint_directory point to committed files in customer Git.
Rerun does not pick up changes	Confirm that the changes were committed and pushed to the saved branch and directory before you submit the bodyless PUT request.
Incremental update does not start a new image builder job	Confirm that the customer Git changes were pushed, Chart.yaml was incremented under <deploy_name>-<deploy_id>/siebel-openint-image-builder, and the Helm chart change was committed and pushed.

Security Considerations:

• Do not include actual Git access tokens, SSH private keys, certificate authority (CA) certificates, Java KeyStore (JKS) passwords, registry passwords, or customer secrets in documentation examples, sample payloads, or source-controlled files.
• For HTTPS Git repositories, ensure SCM mounts access tokens as secret files at runtime and does not store or embed token values in git.json.
• For SSH Git repositories, ensure SCM mounts the SSH private key as /git-secrets/ssh_private_key.
• For HTTPS repositories that use a self-signed or private CA certificate, ensure SCM mounts the CA certificate as /git-secrets/https_trust_source.
• Ensure that the generated git.json file contains runtime metadata and references to secret file locations and does not contain raw secret values.
• Keystore and truststore paths specified in the deployment payload must be accessible to SCM and should reference approved runtime storage locations, such as Sync Utility output paths.
• Store sensitive files and credentials only in approved secret-management or runtime-storage locations. Do not commit them to customer Git repositories or infrastructure Helm chart repositories.