How to link modulator objects to the relevant workload objects #452
MikeSpreitzer
started this conversation in
General
Replies: 1 comment
-
For summarization prescriptions, the possibility of multiple applying to one workload object does not seem bad to me. I even think it could be a positive good. (Of course, each summarization prescription would produce its own distinct collection of summary objects.). I can imagine a user wanting to maintain a few styles of summarization, each applying to a collection of workload objects, without those collections necessarily being disjoint. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Customization and summarization prescriptions are modulators that apply to workload objects. What is the best interface for saying which modulators apply to which workload objects?
In the current customization API, the answer is that annotations in the workload objects (a) enable parameter expansion and/or (b) refer to a Customizer object. This approach has the advantage that it is syntactically impossible to have overlaps or conflicts. A given workload object says how it is customized, end of story. The disadvantage of this approach is that applying customization to a workload object requires specific content in that object. This means that an object that is imported from a third-party source, such as a Helm chart, is potentially problematic. I say potentially because some import mechanisms allow modifications; in particular, you will find Helm charts that support adding annotations when those charts are instantiated.
Last year's proposal for summarization (https://docs.google.com/document/d/1yY-XgOtCnOPKpVdxdPVhH5ixRN6IWQQe0s3lip1ID0Y --- accessible to members of https://groups.google.com/g/kubestellar-dev) takes the same approach.
A possible alternate approach is external binding. The simplest version of this for customization would have a Customizer object include a predicate that selects which workload objects it applies to. A more articulated version of this would have two kinds of objects, one that prescribes customization and one that uses predicates (like in EdgePlacement) to bind customizations with workload objects. Both versions of this introduce the issue that more than one customization prescription can apply to a given workload object. This is not wrong, just complex. We would need to define a predictable, and usefully controllable, order in which the customizations get applied to a given object. This is the approach taken in karmada, for example.
Beta Was this translation helpful? Give feedback.
All reactions