Object patching architecture
Patch application infrastructure
To apply object patches on the cluster we make use of the patch-operator. The patch-operator is deployed via Commodore component patch-operator.
By default, the adhoc-configurations
component creates a service account and clusterrolebinding to use with the patches managed by the component.
Users can choose to bring their own ServiceAccount or ClusterRoleBinding, by setting component parameters patches.serviceaccount.create
and patches.clusterrolebinding.create
to False
respectively.
Patch input format
The input format for object patches are patch-operator Patch
objects.
To remove some of the more tedious bits of writing Patch
objects, the component provides some extra plumbing to ensure provided Patch
objects work smoothly with the patch-operator deployed in the cluster.
The next section provides a detailed description of the processing that the component does for Patch
objects.
The component also has limited support for transforming |
Patch processing by the component
Using a Commodore postprocessing filter, the adhoc-configurations
component will ensure that:
-
The name of each
Patch
object is prefixed withadhoc-configurations-
. -
The
apiVersion
of allPatch
resources matches the version of patch-operator which is deployed on the cluster. -
The namespace of all
Patch
resources is set to the namespace in which the patch-operator runs. -
The field
spec.serviceAccountRef
of allPatch
resources is set to the ServiceAccount managed by (or provided to) the component.
Additionally, the postprocessing filter will transform legacy ResourceLocker
resources provided in the abbreviated format supported by previous component versions into equivalent Patch
resources by transforming field patches
from a list to an object with autogenerated keys.
This feature is only provided to make migration to patch-operator easier and users are encouraged to update their patch specifications to the format expected by patch-operator.