-
Notifications
You must be signed in to change notification settings - Fork 84
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
Add Patch #44
Add Patch #44
Conversation
/assign @justinsb |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: johnsonj 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 |
Would we want to be able to specify kustomize bases as well? This would allow you to check your overlays/patches into source control and use overlays that are distributed via channels or the operator's file system. |
That seems interesting @stealthybox! I think we need to think about if the patches on the CRD are the 'final assembly' or the a higher level (declaration of the intent?). If they're the sort of final instructions, then I think we can keep I guess we should think about: 'would a user patch the CRD with kustomize' or 'is this CRD an interface into kustomize'? |
declarative.WithObjectTransform(addon.TransformApplicationFromStatus), | ||
declarative.WithManagedApplication(srcLabels), | ||
declarative.WithObjectTransform(addon.ApplyPatches), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is going to be weird if the field is there, but the patches don't actually do anything. Maybe this should be the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is necessary today because the addons package defines the types, so the declarative package can't extract the patch out. We could workaround this with reflection.
I think what we really need is an AddonsReconciler that applies all (or most?) of these transforms.
for _, gk := range uniqueGroupKind(objects) { | ||
componentGroupKinds = append(componentGroupKinds, map[string]interface{}{"group": gk.Group, "kind": gk.Kind}) | ||
} | ||
app.SetNestedSlice(componentGroupKinds, "spec", "componentGroupKinds") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, though why are we doing this? Just to break the dependency on metav1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to do this because the actual metav1.LabelSelector{} couldn't be deep copied (which is why SetNestedFieldNoCopy) was used. That version didn't properly set these values (but the API server accepted it because the CRD was basically untyped).
This lgtm. On the base question, I think we can consider that separately from this PR @stealthybox ? My guess is that the base should be defined by the operator itself - or maybe by a version/channel field in the object, and that we wouldn't expect to allow arbitrary bases. But that's just my guess! |
Thanks @johnsonj /lgtm |
/test pull-declarative-test |
Introduce Patch. An Addon can implement the Patchable interface to accept a set of Patches that are overlaid on the deployment. For example: apiVersion: addons.sigs.k8s.io/v1alpha1 kind: Dashboard metadata: name: dashboard-sample namespace: kube-system spec: patches: - apiVersion: apps/v1beta2 kind: Deployment metadata: name: kubernetes-dashboard namespace: kube-system spec: replicas: 5 This patch will change the replica count of the dashboard deployment. This allows us to provide a break-glass experience for the user to set configuration options while not requiring every configuration option be directly exposed on the CRD. - It's not clear if we want this on all addons. If so, we should graduate it to CommonObject - Patch doesn't work if it happens after the addons.TransformApplicationFromStatus transform. It raises a DeepCopy error. This is a bug. - This patching is equivalent/borrowed from kustomize which is not currently avaliable as a library.
Change the mutation of Application to be based on map[string]interface{} instead of using k8s types (like GroupKind). The k8s types do not properly deserialize.
/test pull-declarative-test |
/ok-to-test |
/retest |
Thanks for rebasing & fixing tests! /lgtm |
Based on functionality added in kubernetes-sigs/kubebuilder-declarative-pattern#44
Based on functionality added in kubernetes-sigs/kubebuilder-declarative-pattern#44
Introduce Patch. An Addon can implement the Patchable interface to
accept a set of Patches that are overlaid on the deployment. For
example:
This patch will change the replica count of the dashboard deployment.
This allows us to provide a break-glass experience for the user to set
configuration options while not requiring every configuration option be
directly exposed on the CRD.
graduate it to CommonObject
currently avaliable as a library.