Skip to main content
Version: Weekly Build

Install Steps and Profiles

Install steps

Skip steps make the installer resumable and allow it to work with prerequisites that are already installed or managed outside OMS. They are also useful when rerunning only a later phase after changing configuration. A skipped step is not validated or replaced by OMS, so skip it only when its result is already present or intentionally unnecessary; skipping a required prerequisite can make a later step fail.

Use --skip-steps for a single invocation, with multiple names separated by commas. To persist skips across future runs, add them to config.yaml:

operations:
skip:
- load-container-images

The supported skip names are:

StepWhat skipping it bypasses
copy-dependenciesCopying packaged installation dependencies to the target hosts
extract-dependenciesExtracting the packaged dependencies on the target hosts
load-container-imagesLoading images bundled in the deprecated full installer package; current lite packages pull images from GHCR, so skip this step
sopsInstalling the SOPS dependency used for encrypted installation secrets
dockerInstalling and configuring Docker on the target hosts
postgresInstalling and configuring the PostgreSQL instance described by the install configuration
cephInstalling and configuring the Ceph cluster and OSDs
kubernetesInstalling and configuring the Codesphere-managed k0s cluster
argocdThe Argo CD bootstrap portion of the cluster-dependencies phase
set-up-clusterConfiguring cluster-level dependencies after the base infrastructure is ready
ms-backendsInstalling the managed-service backend components
codesphereDeploying the Codesphere platform itself

warning

The full installer package is deprecated. Current installations should use installer-lite.tar.gz and skip load-container-images. The step remains available only for compatibility with legacy full packages.

Phases

The combined oms install codesphere command installs in this order:

  1. Copies and extracts dependencies.
  2. Skips loading bundled container images because the nodes pull them from GHCR.
  3. Installs SOPS and the container runtime dependencies.
  4. Installs or configures PostgreSQL.
  5. Installs and configures Ceph.
  6. Installs and configures k0s when Kubernetes is Codesphere-managed.
  7. Installs Argo CD, cluster dependencies, and managed-service backends.
  8. Installs the Codesphere platform.

The installation can also be run as separate infra, dependencies, and platform phases when operational change control requires distinct checkpoints — see oms install codesphere infra --help, oms install codesphere dependencies --help, and oms install codesphere platform --help.

Install configuration profiles

The profile controls the default Codesphere software footprint, allowing the installation to fit differently sized infrastructure. It does not provision machines or automatically decide how many PostgreSQL, Ceph, control-plane, or worker nodes to use. The wizard or command flags must still describe the actual topology and IP addresses.

The profiles currently behave as follows:

ProfileIntended useMonitoringKubernetes resource behaviorOther differences
dev or developmentSmall development and sandbox installationsLoki, Grafana, and Grafana Alloy are disabledApplies the noRequests resource profile described belowDatacenter name defaults to dev
minimalPOC installations that need the normal monitoring stack with a reduced scheduling footprintLoki, Grafana, and Grafana Alloy are enabledApplies the same noRequests resource profileDatacenter name defaults to dev; CloudNativePG operator, Barman Cloud plugin, and RGW load balancer are enabled
prod or productionProduction installationsLoki, Grafana, and Grafana Alloy are enabledDoes not apply the reduced-resource overrides; charts retain their normal resource and replica defaultsDatacenter name defaults to production

The noRequests resource profile used by dev and minimal removes CPU and memory requests from Codesphere services and supporting charts. It also reduces several supporting components to one replica, including ingress controllers, Loki components, RGW load balancer, and managed-service backends. Selected core Codesphere services retain two replicas, but their resource requests are set to zero. This makes the Kubernetes scheduler accept a smaller cluster, but it removes resource guarantees and reduces failure tolerance. Do not interpret successful scheduling with this profile as proof that the hosts have enough real CPU or memory under load.

All profiles start with the same common infrastructure defaults, including Codesphere-managed Kubernetes, installed PostgreSQL, Ceph, LoadBalancer gateways, disabled MetalLB, and placeholder localhost addresses. They also start with the standard workspace and hosting plan defaults. Replace all placeholder topology, domain, registry, and secrets values during the wizard or configuration review.

Use production for the production baseline and minimal for the POC topology. Use dev only when disabling the bundled monitoring components is appropriate.