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
Patchobject is prefixed withadhoc-configurations-. -
The
apiVersionof allPatchresources matches the version of patch-operator which is deployed on the cluster. -
The namespace of all
Patchresources is set to the namespace in which the patch-operator runs. -
The field
spec.serviceAccountRefof allPatchresources 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.