OSAC Installer

This repository contains Kubernetes/OpenShift deployment configurations for the OSAC platform, providing a fulfillment service framework for clusters and virtual machines.

Note: Throughout this guide, <project-name> refers to your unique OSAC installation name, which is used as both the namespace and resource prefix. Replace it with your chosen project name (e.g., user1, team-a, etc.).

Overview

OSAC (Open Sovereign AI Cloud) provides a streamlined, self-service framework for provisioning and managing OpenShift clusters and virtual machines. This installer repository contains the Kubernetes/OpenShift deployment configurations needed to deploy OSAC components on your infrastructure.

For detailed architecture, workflows, and design documentation, please refer to the OSAC documentation repository.

The OSAC platform provides:

Self-service provisioning for clusters and virtual machines through a governed API
Template-based automation using Red Hat Ansible Automation Platform
Multi-hub support allowing multiple infrastructure hubs to be managed by a single fulfillment service
API access via both gRPC and REST interfaces for integration with custom tools

This installer uses Kustomize to manage deployments, making it easy to customize for different environments.

OSAC Components

The OSAC platform relies on four core components to deliver governed self-service:

Fulfillment Service: The API and frontend entry point used to manage user requests and map them to specific templates.
OSAC Operator: An OpenShift operator residing on the Hub cluster (ACM/OCP-Virt). It orchestrates the lifecycle of clusters and VMs by coordinating between the Fulfillment Service and the automation backend.
Console Proxy: A Kubernetes aggregated API server that provides serial and VNC console access to ComputeInstance VMs. Deployed alongside the operator on each hub.
Automation Backend (AAP): Leverages the Red Hat Ansible Automation Platform to store and execute the custom template logic required for provisioning.

Prerequisites & Setup

System Requirements This solution requires the following platforms to be installed and operational:

Red Hat OpenShift Advanced Cluster Management (RHACM)

Red Hat OpenShift Virtualization (OCP-Virt) - Optional: Only required for VM as a Service (VMaaS) support

Red Hat Ansible Automation Platform (AAP)

A network backend for bare metal provisioning: either ESI (Elastic System Infrastructure) or Netris (see Network Backend Configuration)

Configuration Manifests

The /prerequisites directory contains additional manifests required to configure the target Hub cluster.

⚠️ Important: Cluster-Wide Impact If you are using a shared cluster or are not the primary administrator, do not apply these manifests without consultation. These files modify cluster-wide settings. Please coordinate with the appropriate cluster administrators before proceeding.

📋 Prerequisites Summary

Category	Requirement	Notes / Details
Platform	Red Hat OpenShift Container Platform (OCP) 4.17 or later	Must have cluster admin access to the hub cluster.
Operators	Red Hat Advanced Cluster Management (RHACM) 2.18+ Red Hat OpenShift Virtualization (OCP-Virt) 4.17+ Red Hat Ansible Automation Platform (AAP) 2.5+	These must be installed and running prior to OSAC installation.
CLI Tools	`oc` (OpenShift CLI) v4.17+ `kubectl` (optional) `kustomize` v5.x `git`	Ensure all CLIs are available in your `PATH`.
Container Registry Access	`registry.redhat.io` and `quay.io`	Verify credentials and pull secrets are valid in the target cluster namespace.
Network / DNS	Ingress route configured for OSAC services	Required for external access to fulfillment API and AAP UI.
Authentication / IDM	Organization Identity Provider (e.g., Keycloak, LDAP, RH-SSO)	Used for tenant and user identity mapping.
Storage	Dynamic storage class available (e.g., `ocs-storagecluster-cephfs`, `lvms-storage`)	Required for persistence of operator and AAP components.
Permissions	Cluster-admin access to deploy operators and create CRDs	Limited access users can only deploy into namespaces configured by the admin.
License Files	`license.zip` (AAP subscription)	Must be placed under `overlays/<your-overlay>/files/license.zip`.
Internet Access	Outbound access to GitHub (for fetching submodules, releases)	Required during installation and updates.

Installation Strategy

OSAC supports two installation methods:

Helm (recommended) — Uses an umbrella Helm chart (charts/osac/) that composes all OSAC component charts into a single deployable unit. Configuration is managed via values files in the values/ directory.
Kustomize (legacy) — Uses Kustomize overlays in the overlays/ directory.

Both methods use Git submodules to import component manifests from each repository. The prerequisites (cert-manager, AAP operator, Authorino, Keycloak, etc.) are the same regardless of which method you choose.

Customizing Your Installation

Although the development overlay will work out of the box, we recommend customizing your overlay by creating a new project-specific configuration. This is especially important when deploying on shared clusters to avoid resource name collisions.

Use Kustomize to manage your environment-specific configurations.

Choose a Project Name: Select a unique name for your OSAC installation (e.g., user1, team-a, dev-env). This will be used as your namespace and resource prefix. In the examples below, we'll use <project-name> as a placeholder.
Initialize the Overlay: Duplicate the development template with your project name:
```
$ cp -r overlays/development overlays/<project-name>
```

Populate Required Files: Ensure your new directory structure matches the following:

overlays/<project-name>/
├── kustomization.yaml      # Edit this to configure your deployment
├── prefixTransformer.yaml  # Edit this to set resource name prefix
└── files/
    └── license.zip         # REQUIRED: Your AAP license file

Update Critical Configuration: You must update these configuration values to match your environment:
- In kustomization.yaml: Update the namespace field to <project-name>
- In prefixTransformer.yaml: Update the prefix field to <project-name>-
- The ca-bundle Bundle is cluster-scoped and shared across overlays. If using setup.sh, it handles the Bundle automatically (creates it on first deploy, patches the namespace selector on subsequent deploys). If deploying manually, patch the Bundle to include your namespace:
```
oc patch bundle ca-bundle --type=json -p '[
  {"op":"add","path":"/spec/target/namespaceSelector/matchExpressions/0/values/-","value":"<project-name>"}
]'
```
  Alternatively, run scripts/ensure-ca-bundle.sh <project-name> which handles both creation and patching.
- In kustomization.yaml: Replace <cluster-name>.<base-domain> in the OSAC_AAP_URL value with your cluster's actual domain (e.g., mgmt.example.devcluster.openshift.com). You can find it by running: oc get ingresses.config/cluster -o jsonpath='{.spec.domain}'
These changes ensure your installation uses a unique namespace and prevents resource name conflicts with other OSAC installations.
Apply Additional Customizations: Modify other settings in your overlay folder as needed (images, patches, etc.).

For more information on structuring overlays and patches, please consult the official Kustomize documentation.

Using Custom Component Versions

By default, the installer uses the latest commit from each submodule (via git submodule update --init --recursive --remote) and the latest container images defined in base/kustomization.yaml.

To test a specific revision of a component, you need to:

Check out the desired code in the submodule:

cd base/<submodule>
git checkout <branch-or-commit>
cd ../..

Build and push a custom container image:

Build the image from the checked-out code and push it to a registry accessible by your cluster.
Override the image in your overlay's kustomization.yaml:
```
images:
  - name: <component-image-name>
    newName: <your-registry>/<your-image>
    newTag: <your-tag>
```
The component image names used in the base are:

Component Image name

Fulfillment Service fulfillment-service

OSAC Operator osac-operator

OSAC AAP osac-aap

OSAC AAP Customization

For osac-aap, in addition to the image override, you must also update the AAP configuration secrets in your overlay's kustomization.yaml:

secretGenerator:
- name: config-as-code-ig
  options:
    disableNameSuffixHash: true
  literals:
    - AAP_EE_IMAGE=<your-registry>/osac-aap:<your-tag>
    - AAP_PROJECT_GIT_URI=<your-git-repo-url>
    - AAP_PROJECT_GIT_BRANCH=<your-branch>

AAP_EE_IMAGE: The Execution Environment image used by AAP to run automation jobs. This should match the container image override above.
AAP_PROJECT_GIT_URI: The Git repository URL for the AAP project (playbooks and configuration).
AAP_PROJECT_GIT_BRANCH: The Git branch to use for the AAP project.

Obtaining an AAP License (Subscription Manifest)

The AAP license is a Subscription Manifest (a .zip file), not a key file. To obtain it:

Log in to the Red Hat Customer Portal.
Navigate to Subscriptions > Subscription Allocations.
Create or select an allocation: If you haven't created one, click "New Subscription Allocation" and set the type (usually "Satellite 6.x").
Add entitlements: Click on your allocation, go to the Subscriptions tab, and add your Ansible Automation Platform subscriptions.
Download: Click Export Manifest to download the .zip file.

Place the downloaded license.zip file in overlays/<project-name>/files/. You will also upload this manifest into the AAP controller UI after deployment.

Pre-Installation Steps

Before deploying OSAC, complete the following steps to prepare your environment.

1. Initialize Submodules

The OSAC installer relies on external components managed as Git submodules. Before running Kustomize, you must pull the manifest files into your local directory:

$ git submodule update --init --recursive --remote

2. Populate Local Secrets

Ensure your overlay contains the necessary secret files that are excluded from Git:

AAP License: Place license.zip in overlays/<project-name>/files/.
Quay Pull Secret: Place quay-pull-secret.json in overlays/<project-name>/files/.

Deploying OSAC Components

Option A: Automated Setup (Recommended)

The scripts/setup.sh script automates the entire installation process, including:

Installing prerequisite operators (cert-manager, trust-manager, Authorino, Keycloak, AAP)
Optionally installing LVMS (storage service), MetalLB (ingress service), Multicluster Engine (MCE + infrastructure operator), and OpenShift Virtualization (CNV)
Setting up the CA issuer and network attachment definitions
Deploying OSAC components (via Helm or Kustomize)
Waiting for the AAP bootstrap job to complete
Creating the hub access kubeconfig and registering the hub with the fulfillment service

To run the automated setup:

# Helm mode (default) — uses values/development.yaml
$ ./scripts/setup.sh

# Or customize the namespace and values file
$ INSTALLER_NAMESPACE=<project-name> VALUES_FILE=values/development.yaml ./scripts/setup.sh

# Kustomize mode (legacy)
$ DEPLOY_MODE=kustomize INSTALLER_KUSTOMIZE_OVERLAY=<project-name> ./scripts/setup.sh

# Install with all optional services (storage, ingress, virtualization, MCE)
$ EXTRA_SERVICES=true INSTALLER_NAMESPACE=<project-name> ./scripts/setup.sh

Variable	Default	Description
`KUBECONFIG`	`~/.kube/config`	Path to the target cluster's kubeconfig file
`DEPLOY_MODE`	`helm`	Deployment method: `helm` or `kustomize`
`INSTALLER_NAMESPACE`	`osac` (helm) / from overlay (kustomize)	Target namespace for the OSAC deployment
`VALUES_FILE`	`values/development.yaml`	Helm values file to use (helm mode only)
`INSTALLER_KUSTOMIZE_OVERLAY`	`development`	Kustomize overlay directory (kustomize mode only)
`EXTRA_SERVICES`	`false`	Enable all optional services (sets all below to `true`)
`INGRESS_SERVICE`	`false`	Install MetalLB as the ingress/LoadBalancer service
`STORAGE_SERVICE`	`false`	Install LVMS and create a default StorageClass (`lvms-vg1`)
`VIRT_SERVICE`	`false`	Install OpenShift Virtualization
`MCE_SERVICE`	`false`	Install Multicluster Engine and infrastructure operator

AAP Configuration

The automation backend (AAP) is configured via two env files in your overlay's files/ directory:

osac-aap-configuration.env — non-sensitive settings (network class, domains, connection details). Tracked in git with ESI defaults; customize for your environment.
osac-aap-secrets.env — sensitive credentials (passwords, SSH keys, AWS keys). Gitignored, you create this file.

Edit these files to match your environment, then run setup.sh — the script applies them automatically via scripts/aap-configuration.sh.

See docs/aap-configuration.md for the full variable reference.

Network Backend Configuration (CaaS)

By default the network backend is ESI. To switch to Netris, set NETWORK_CLASS=netris in your overlay's osac-aap-configuration.env and fill in the Netris-specific connection details and credentials.

See docs/network-backend.md for Netris-specific variables and the NETRIS_RESOURCE_CLASS_MAP format.

DNS Backend Configuration (CaaS)

DNS record management uses a pluggable backend. The default is AWS Route 53 (DNS_CLASS=dns.route53.dns), which requires AWS credentials in osac-aap-secrets.env. No changes are needed for existing deployments.

To use a different DNS provider, set DNS_CLASS to a custom backend driver role in your overlay's osac-aap-configuration.env.

See docs/dns-backend.md for backend details, the interface contract, and how to add a new provider.

Note: The script requires osac to be installed and available in your PATH (see OSAC CLI: Setup & Usage below for installation instructions).

The script will wait for all components to be ready before proceeding to the next step. Once it completes successfully, OSAC is fully operational.

Option B: Manual Helm Installation

If you prefer to install step-by-step, follow the process below. The prerequisites are the same as Option C (Kustomize) — only the final deploy step differs.

1. Install Prerequisites

OSAC requires several operators to be present on the cluster. The prerequisite manifests are located in the prerequisites/ directory. Install them in order:

# cert-manager
oc apply -k prerequisites/cert-manager/
oc wait --for=condition=Available deployment/cert-manager -n cert-manager --timeout=300s
oc wait --for=condition=Available deployment/cert-manager-webhook -n cert-manager --timeout=300s

# trust-manager
oc apply -f prerequisites/trust-manager.yaml
oc wait --for=condition=Available deployment/trust-manager -n cert-manager --timeout=300s

# CA issuer
oc apply -f prerequisites/ca-issuer.yaml

# Authorino operator
oc apply -f prerequisites/authorino-operator.yaml

# Keycloak
oc apply -k prerequisites/keycloak/
oc wait --for=condition=Available deployment/keycloak-service -n keycloak --timeout=600s

# AAP operator
oc apply -f prerequisites/aap-installation.yaml

Wait for each operator to be ready before proceeding. See prerequisites/README.md for details on optional components (LVMS, MetalLB, MCE, OpenShift Virtualization).

2. Initialize Submodules

git submodule update --init --recursive --remote

3. Build Chart Dependencies

helm dependency build charts/osac/

4. Configure Values

Copy and customize a values file for your environment:

cp values/development.yaml values/<project-name>.yaml
# Edit values/<project-name>.yaml to set:
#   - operator.aap.url: your AAP controller URL
#   - service.auth.issuerUrl: your Keycloak realm URL
#   - service.idp.url: your Keycloak base URL
#   - service.database.connection: your PostgreSQL connection details

5. Validate (Dry-Run)

# Lint the chart
helm lint charts/osac/

# Render templates without deploying
helm template osac charts/osac/ --values values/<project-name>.yaml > /dev/null

6. Deploy

helm upgrade --install osac charts/osac/ \
  --namespace <project-name> \
  --create-namespace \
  --values values/<project-name>.yaml \
  --timeout 40m \
  --wait

7. Verify

# Check deployment status
helm status osac -n <project-name>

# Check running pods
kubectl get pods -n <project-name>

# Monitor the AAP bootstrap job (runs as a post-install hook)
kubectl logs -f job/osac-aap-bootstrap -n <project-name>

8. Post-Install

After the AAP bootstrap job completes, run the post-install scripts:

INSTALLER_NAMESPACE=<project-name> ./scripts/prepare-aap.sh
INSTALLER_NAMESPACE=<project-name> ./scripts/prepare-fulfillment-service.sh
INSTALLER_NAMESPACE=<project-name> ./scripts/prepare-tenant.sh

Upgrading

helm upgrade osac charts/osac/ \
  --namespace <project-name> \
  --values values/<project-name>.yaml \
  --timeout 40m \
  --wait

Uninstalling

helm uninstall osac -n <project-name>

Note: CRDs are preserved after uninstall (they have the helm.sh/resource-policy: keep annotation). To remove them manually: oc delete crd -l app.kubernetes.io/part-of=osac

Makefile Targets

For convenience, the Makefile provides developer targets:

make helm-deps       # Build chart dependencies
make helm-lint       # Lint the umbrella chart
make helm-template   # Dry-run render all templates
make helm-validate   # Lint + template (full validation)
make helm-deploy     # Deploy to current cluster
make helm-undeploy   # Uninstall from current cluster
make sync-charts     # Update submodules + rebuild dependencies
make setup           # Run setup.sh with DEPLOY_MODE=helm

Option C: Manual Kustomize Installation (Legacy)

If you prefer to install step-by-step using Kustomize, or need to install individual prerequisites, follow the manual process below.

Install Required Operators

OSAC requires several operators to be present on the cluster. The prerequisite manifests are located in the prerequisites/ directory. You can check if an operator is already installed by running oc get crd <crd-name>.

# Install cert-manager
$ oc apply -k prerequisites/cert-manager

# Install trust-manager
$ oc apply -f prerequisites/trust-manager.yaml

# Install CA issuer
$ oc apply -f prerequisites/ca-issuer.yaml

# Install Authorino operator
$ oc apply -f prerequisites/authorino-operator.yaml

# Install Keycloak
$ oc apply -k prerequisites/keycloak/

# Install AAP operator
$ oc apply -f prerequisites/aap-installation.yaml

# Install MetalLB (optional - ingress/LoadBalancer service)
$ oc apply -f prerequisites/metallb/metallb-operator.yaml
# Wait for MetalLB operator to be ready, then apply config:
$ oc apply -f prerequisites/metallb/metallb-config.yaml

# Install LVMS (optional - storage service)
$ oc apply -f prerequisites/lvms/lvms-operator.yaml
# Wait for LVMS operator to be ready, then apply config:
$ oc apply -f prerequisites/lvms/lvms-config.yaml
# Set lvms-vg1 as default StorageClass:
$ oc annotate sc lvms-vg1 storageclass.kubernetes.io/is-default-class=true --overwrite

# Install Multicluster Engine (optional - MCE + infrastructure operator)
$ oc apply -f prerequisites/mce/mce-operator.yaml
# Wait for MCE operator to be ready, then create MultiClusterEngine and AgentServiceConfig:
$ oc apply -f prerequisites/mce/mce-config.yaml

# Install OpenShift Virtualization (optional - CNV/KubeVirt)
$ oc apply -f prerequisites/cnv/cnv-operator.yaml
# Wait for CNV operator to be ready, then apply HyperConverged config:
$ oc apply -f prerequisites/cnv/cnv-config.yaml

Tip: Wait for each operator deployment to become available before proceeding to the next. For example: oc wait --for=condition=Available deployment/cert-manager -n cert-manager --timeout=300s

Apply the Kustomize Overlay

Once all prerequisites are ready, deploy OSAC:

# Deploy OSAC components
$ oc apply -k overlays/<project-name>

Monitor Progress

# Monitor pod creation and startup
$ watch oc get -n <project-name> pods

Several pods restart during initialization. The OpenShift job named aap-bootstrap restarts several times before completing. This is expected behavior.

Once the aap-bootstrap job completes, OSAC is ready for use.

Alternative: Install with Wait Option

# Wait for all deployments to be ready (blocking command)
$ oc wait --for=condition=Available deployment --all -n <project-name> --timeout=600s

OSAC CLI: Setup & Usage

To install the CLI and register a hub, follow these steps:

1. Install the Binary

Download the latest release and make it executable.

# Adjust URL for the latest version as needed
$ curl -L -o osac \
    https://github.com/osac-project/fulfillment-service/releases/latest/download/osac_Linux_x86_64
$ chmod +x osac

# Optional: Move to your path
$ sudo mv osac /usr/local/bin/

2. Log in to the Service

Authenticate with the fulfillment API. You will need the route address and a valid token generation script.

$ osac login \
    --address <your-fulfillment-route-url> \
    --token-script "oc create token fulfillment-controller -n <project-name> \
    --duration 1h --as system:admin" \
    --insecure

Tip: Retrieve your route URL using: oc get routes -n <project-name>

3. Register the Hub

To allow the OSAC operator to communicate with the fulfillment service, you must obtain the kubeconfig and register the hub. The script located at scripts/create-hub-access-kubeconfig.sh demonstrates how to generate the kubeconfig for a hub.

# Generate the kubeconfig
$ ./scripts/create-hub-access-kubeconfig.sh

# Register the Hub
$ osac create hub \
    --kubeconfig=kubeconfig.hub-access \
    --id <hub-name> \
    --namespace <project-name>

Note: Refer to base/fulfillment-service/hub-access/README.md for more information

4. Use the CLI

Once configured, you can use the OSAC CLI to manage clusters and virtual machines. For detailed usage instructions and command reference, see the OSAC CLI documentation.

Accessing Ansible Automation Platform

After deployment, you can access the AAP web interface to monitor jobs and manage automation:

Get the AAP URL

$ oc get route -n <project-name> | grep osac-aap

AAP routes will contain 'osac-aap' in the name.

Note: The main AAP URL will be something like: https://osac-aap-<project-name>.apps.your-cluster.com

Get the AAP Admin Password

# Extract the admin password
$ oc extract secret/osac-aap-admin-password -n <project-name> --to -

Login to AAP

Open the AAP controller URL in your browser
Username: admin
Password: (from the previous step)

Create an AAP API Token for the OSAC Operator

The OSAC operator requires an API token to communicate with AAP. The scripts/prepare-aap.sh script automates this by authenticating with the AAP gateway using the admin password and creating a write-scoped token. The automated setup script (setup.sh) calls this automatically.

For manual deployments, run it after the AAP bootstrap job completes:

$ INSTALLER_NAMESPACE=<project-name> ./scripts/prepare-aap.sh

This script will:

Retrieve the AAP admin password from the osac-aap-admin-password secret
Create an API token via the AAP gateway (/api/gateway/v1/tokens/)
Store the token in a osac-aap-api-token secret
Set the correct OSAC_AAP_URL on the operator deployment

Using AAP Interface

From the AAP web interface, you can:

Monitor cluster provisioning jobs and their status
View automation execution logs and troubleshoot failures
Manage job templates and automation workflows
Configure additional automation tasks
View inventory and host information

Tearing Down OSAC

To completely remove an OSAC deployment and all its prerequisites, use the teardown script:

# Using defaults (namespace: osac-devel, overlay: development)
$ ./scripts/teardown.sh

# Or specify your namespace and overlay
$ INSTALLER_NAMESPACE=<project-name> INSTALLER_KUSTOMIZE_OVERLAY=<project-name> ./scripts/teardown.sh

# Include all optional services in teardown (must match what was used during setup)
$ EXTRA_SERVICES=true \
    INSTALLER_NAMESPACE=<project-name> INSTALLER_KUSTOMIZE_OVERLAY=<project-name> ./scripts/teardown.sh

# Or selectively match what was used during setup
$ INGRESS_SERVICE=true STORAGE_SERVICE=true \
    INSTALLER_NAMESPACE=<project-name> INSTALLER_KUSTOMIZE_OVERLAY=<project-name> ./scripts/teardown.sh

The script removes resources in reverse order:

StorageClass OSAC labels
Kustomize overlay resources and project namespace
Keycloak (before storage, since its PVCs depend on the storage class)
AAP operator
Multicluster Engine and AgentServiceConfig (if MCE_SERVICE=true)
LVMS storage service (if STORAGE_SERVICE=true)
MetalLB ingress service (if INGRESS_SERVICE=true)
OpenShift Virtualization (if VIRT_SERVICE=true)
Authorino operator
CA issuer, trust-manager, and cert-manager
Stale API services cleanup
NetworkAttachmentDefinition
Local kubeconfig.hub-access file

The script waits for all namespaces to be fully deleted before completing.

Warning: This removes all prerequisite operators and their namespaces. If other workloads on the cluster depend on these operators (e.g., cert-manager, MetalLB), do not run this script. Instead, manually delete only the OSAC-specific resources:
$ oc delete -k overlays/<project-name>
$ oc delete namespace <project-name>

Troubleshooting

Common Issues

cert-manager not ready: Ensure cert-manager operator is installed and running
Certificate issues: Check cert-manager logs and certificate status
ImagePullBackOff errors: Verify registry credentials in files/quay-pull-secret.json and image string

Debug Commands

# Check certificate status
$ oc describe certificate -n <project-name>

# Check certificate issuer status
$ oc describe issuer -n <project-name>

# Check pod events
$ oc describe pod -n <project-name> <pod-name>

# Check service endpoints
$ oc get endpoints -n <project-name>

# Check secrets
$ oc get secrets -n <project-name>

# View component logs
$ oc logs -n <project-name> deployment/fulfillment-service -c server --tail=100
$ oc logs -n <project-name> deployment/<project-name>-controller-manager --tail=100

# Get all events in namespace
$ oc get events -n <project-name> --sort-by=.metadata.creationTimestamp

Support

For issues and questions:

Check the troubleshooting section above
Review component logs for error messages
Verify prerequisites are properly installed
Open issues in the respective component repositories

License

This project is licensed under the Apache License 2.0.

Name		Name	Last commit message	Last commit date
Latest commit History 234 Commits
.github		.github
base		base
charts/osac		charts/osac
docs		docs
overlays		overlays
prerequisites		prerequisites
scripts		scripts
values		values
.gitignore		.gitignore
.gitmodules		.gitmodules
.pre-commit-config.yaml		.pre-commit-config.yaml
.yamllint.yaml		.yamllint.yaml
AGENTS.md		AGENTS.md
CLAUDE.md		CLAUDE.md
LICENSE		LICENSE
Makefile		Makefile
OSAC-CLI-HOWTO.md		OSAC-CLI-HOWTO.md
OWNERS		OWNERS
README.md		README.md

Component	Image name
Fulfillment Service	`fulfillment-service`
OSAC Operator	`osac-operator`
OSAC AAP	`osac-aap`

Folders and files

Latest commit

History

Repository files navigation

OSAC Installer

Overview

OSAC Components

Prerequisites & Setup

📋 Prerequisites Summary

Installation Strategy

Customizing Your Installation

Using Custom Component Versions

OSAC AAP Customization

Obtaining an AAP License (Subscription Manifest)

Pre-Installation Steps

1. Initialize Submodules

2. Populate Local Secrets

Deploying OSAC Components

Option A: Automated Setup (Recommended)

AAP Configuration

Network Backend Configuration (CaaS)

DNS Backend Configuration (CaaS)

Option B: Manual Helm Installation

1. Install Prerequisites

2. Initialize Submodules

3. Build Chart Dependencies

4. Configure Values

5. Validate (Dry-Run)

6. Deploy

7. Verify

8. Post-Install

Upgrading

Uninstalling

Makefile Targets

Option C: Manual Kustomize Installation (Legacy)

Install Required Operators

Apply the Kustomize Overlay

Monitor Progress

OSAC CLI: Setup & Usage

1. Install the Binary

2. Log in to the Service

3. Register the Hub

4. Use the CLI

Accessing Ansible Automation Platform

Get the AAP URL

Get the AAP Admin Password

Login to AAP

Create an AAP API Token for the OSAC Operator

Using AAP Interface

Tearing Down OSAC

Troubleshooting

Common Issues

Debug Commands

Support

License

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages