Parameters

The parent key for all of the following parameters is adhoc_configurations.

`argocd_ignore_differences`

type	object
default	`{}`

This parameter allows users to configure ArgoCD to ignore certain differences for resources managed by the component.

The component ignores the object keys, and uses the non-null values as entries for .spec.ignoreDifferences of the ArgoCD application resource.

See the ArgoCD documentation for all available features of ArgoCD’s diffing customization.

`manifests_path`

type	string
default	`manifests/${cluster:name}`

Base directory in which the ad-hoc manifests are saved in the tenant repo.

The component will copy any files saved at the path indicated by manifests_path in the tenant repo to the cluster catalog.

`patch_subdirectories`

type: list
default: []

A list of subdirectories of manifests_path in which the component should search for Patch resources. This allows users to store partial Patch resources in a subdirectory of manifests_path without having to manage the patch-operator RBAC themselves.

`patches`

Section to configure ServiceAccount and ClusterRoleBinding which will be used for object patches.

`serviceaccount`

type	dict
default	`create: true name: adhoc-configurations-manager`

The ServiceAccount to create (or use if create is false). When create is false, a ServiceAccount with the given name must exist in the namespace in which the patch-operator is installed.

`clusterrolebinding`

type	dict
default	`create: true clusterrole_name: cluster-admin`

Configuration for ClusterRoleBinding. The ClusterRoleBinding will only be created if field create is true. Otherwise the user needs to ensure that the ServiceAccount used for the Patch objects has sufficient permissions to apply the patches.

The ClusterRoleBinding will refer to a ClusterRole with name clusterrole_name. The component won’t create a ClusterRole, but instead expects that the referenced role exists already.

Examples

Shared manifests for all clusters of a tenant

If you don’t specify ${cluster:name} in the manifests_path, all files in <manifests_path> will be copied to the cluster catalog.

applications:
  - adhoc-configurations

parameters:
  adhoc_configurations:
    manifests_path: manifests

Different base directory

applications:
  - adhoc-configurations

parameters:
  adhoc_configurations:
    manifests_path: customizations/${cluster:name}

Shared and per-cluster manifests

To have both shared and per-cluster manifests for a tenant, you can use symlinks to make the shared manifests available in all cluster directories.

Assuming that you are using the default location of manifests/${cluster:name} in the tenant repository, you can use a structure like the one shown below to have a mix of shared and per-cluster manifests.

t-tenant-id-0011/
├── c-cluster-id-1234.yml
├── c-cluster-id-5678.yml
├── common.yml
└── manifests
    ├── common
    │   ├── rbac.yaml
    │   └── test.yaml
    └── c-cluster-id-1234
    │   ├── networkpolicies.yaml (1)
    │   └── rbac.yaml -> ../common/rbac.yaml (2)
    └── c-cluster-id-5678
        ├── networkpolicies.yaml (1)
        └── rbac.yaml -> ../common/rbac.yaml (2)

1	Per-cluster networkpolicy configurations
2	Symlink pointing to the shared RBAC configuration in `manifests/common`.

Note that the files in manifests/common aren’t directly copied to the catalog by Commodore. They’re only considered if they’re symlinked to a cluster’s directory.