Cozystack Components Reference

Overwriting Component Parameters

You might want to override specific options for the components. To achieve this, modify the corresponding Package resource and specify values in the spec.components section. The values structure follows the values.yaml of the respective system chart in the Cozystack repository.

For example, if you want to enable FRR-K8s mode for MetalLB, look at its values.yaml to understand the available parameters, then modify the cozystack.metallb Package:

apiVersion: cozystack.io/v1alpha1
kind: Package
metadata:
  name: cozystack.metallb
  namespace: cozy-system
spec:
  variant: default
  components:
    metallb:
      values:
        metallb:
          frrk8s:
            enabled: true

Enabling and Disabling Components

Bundles have optional components that need to be explicitly enabled (included) in the installation. Regular bundle components can, on the other hand, be disabled (excluded) from the installation, when you don’t need them.

Use bundles.enabledPackages and bundles.disabledPackages in the Platform Package values. Every entry in those lists is a fully-qualified Package name — the same name you see with kubectl get package. All platform packages live under the cozystack. prefix (for example, cozystack.metallb, cozystack.hetzner-robotlb, cozystack.nfs-driver). Run kubectl get package to see the exact names available on your cluster before editing the Platform Package.

For example, installing Cozystack in Hetzner requires swapping the default load balancer, MetalLB, with one made specifically for Hetzner, called RobotLB:

apiVersion: cozystack.io/v1alpha1
kind: Package
metadata:
  name: cozystack.cozystack-platform
spec:
  variant: isp-full
  components:
    platform:
      values:
        bundles:
          disabledPackages:
            - cozystack.metallb
          enabledPackages:
            - cozystack.hetzner-robotlb
        # rest of the config

Disabling components must be done before installing Cozystack. Applying updated configuration with disabledPackages will not remove components that are already installed. Removing one that is already installed takes two steps. Add its name to disabledPackages in the Platform Package above, then wait for the operator to carry that edit across. The name appears in this output once it has:

kubectl get helmrelease cozystack-platform --namespace cozy-system \
  --output jsonpath='{.spec.values.bundles.disabledPackages}'

Then delete the Package object. kubectl get packages lists the names.

The namespace a component installs into is the exception: the operator applies that one itself, outside the component’s release and with no ownerReference, so the uninstall never had it to remove.

kubectl delete package.cozystack.io <package-name>

Nothing holds a finalizer on the Package, so this command returns as soon as the object is gone and the uninstall it triggers runs afterwards. Wait on the HelmRelease to know the destructive part has finished:

kubectl wait --for=delete helmrelease/<component> --namespace <namespace> --timeout=10m

Deleting the Package while the platform values still render it means the next platform upgrade brings it back, undoing the removal one level up. Nothing reports this at the time: the delete succeeds either way and the Package reappears whenever that upgrade happens to run.

kubectl delete hr is not a lighter-weight version of this. Flux uninstalls the release when the HelmRelease goes away, so it destroys the same CRDs and custom resources, and then the Package recreates the HelmRelease and the chart reinstalls. The workloads come back, the custom resources do not. If you have run it before, those custom resources are already gone and have to be recreated from your own manifests or a backup.