-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support patching installer manifests #2499
base: master
Are you sure you want to change the base?
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 2uasimojo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test e2e |
677edab
to
6e54c52
Compare
786df32
to
61ae998
Compare
This is going well:
mycdc looks like: apiVersion: hive.openshift.io/v1
kind: ClusterDeploymentCustomization
metadata:
name: mycdc
namespace: efried
spec:
installerManifestPatches:
- manifestSelector:
glob: cluster-api/*/*machine*.yaml
patches:
- op: add
path: /metadata/labels
valueJSON: |
{"efried.openshift.io/foo": "bar"} The installmanager logs include:
and a sample manifest in the in-progress provision pod was correctly patched: apiVersion: cluster.x-k8s.io/v1beta1
kind: Machine
metadata:
creationTimestamp: null
labels:
efried.openshift.io/foo: bar # <=== L@@K
name: efried416-ttb8s-master-0
spec:
bootstrap:
dataSecretName: efried416-ttb8s-master
clusterName: efried416-ttb8s
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSMachine
name: efried416-ttb8s-master-0
status:
bootstrapReady: false
infrastructureReady: false |
I just need to test the clusterpool path (and maybe noodle how the error conditions manifest) and we'll be good to land this. |
/cc @abraverm |
In Clusterpool we do reservation of the CDC, should this mechanism somewhat migrate/copied to CD controller? |
For pool inventory, reserving CDCs makes sense because they're intended to enable exclusive/unique settings such as reserved IP addresses. And manifest-patching CDCs used for clusterpool inventory will still be subject to reservation as usual. But for this use case -- CDs' CustomizationRef-named CDCs -- I think we explicitly want manifest patching to be usable by multiple CDs without restriction. Does that make sense? |
4c36dc3
to
ea46045
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2499 +/- ##
==========================================
- Coverage 46.26% 42.90% -3.36%
==========================================
Files 279 279
Lines 32913 33075 +162
==========================================
- Hits 15227 14191 -1036
- Misses 16406 17691 +1285
+ Partials 1280 1193 -87
|
With this change, you can use new API field `ClusterDeployment.Spec.Provisioning.CustomizationRef` to point to a ClusterDeploymentCustomization (hereinafter "CDC") object in the same namespace as the ClusterDeployment (CD). ClusterDeploymentCustomizations: CDC accepts a new subfield, `Spec.InstallerManifestPatches`, which consists of: - `Glob`: a string representing a file glob, relative to the installer working directory, matching one or more manifest files. - `Patches`: a list of `PatchEntity` representing RFC6902 JSON patches to apply to the matched manifest(s). Also, I got really annoyed having to type out `clusterdeploymentcustomizations` on the CLI, so I added abbreviation `cdc` to the schema. ClusterPools: CDC was already being used by ClusterPool-owned CDs to allow patching the install-config generated from the template referred to by `ClusterPool.Spec.InstallConfigSecretTemplateRef`. With this change, ClusterPool-owned CDs can start using manifest patches in two ways (not mutually exclusive): - Patches specific to the CD can be included in the `InstallerManifestPatches` field of the existing Inventory CDCs. - Patches applicable to all CDs in the pool can be provided by a CDC referenced via a new ClusterPool.Spec.CustomizationRef field. HIVE-1793
ea46045
to
4239df0
Compare
@2uasimojo: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
With this change, you can use new API field
ClusterDeployment.Spec.Provisioning.CustomizationRef
to point to a ClusterDeploymentCustomization (hereinafter "CDC") object in the same namespace as the ClusterDeployment (CD).ClusterDeploymentCustomizations:
CDC accepts a new subfield,
Spec.InstallerManifestPatches
, which consists of:Glob
: a string representing a file glob, relative to the installer working directory, matching one or more manifest files.Patches
: a list ofPatchEntity
representing RFC6902 JSON patches to apply to the matched manifest(s).Also, I got really annoyed having to type out
clusterdeploymentcustomizations
on the CLI, so I added abbreviationcdc
to the schema.ClusterPools:
CDC was already being used by ClusterPool-owned CDs to allow patching the install-config generated from the template referred to by
ClusterPool.Spec.InstallConfigSecretTemplateRef
. With this change, ClusterPool-owned CDs can start using manifest patches in two ways (not mutually exclusive):InstallerManifestPatches
field of the existing Inventory CDCs.HIVE-1793