Add proposal for cluster set level override in MWRS - #155
Conversation
Signed-off-by: ncr38 <navinchandrarai444@gmail.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ncr38 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
| CascadeDeletionPolicy CascadeDeletionPolicy `json:"cascadeDeletionPolicy,omitempty"` | ||
|
|
||
| // New field for clusterSet-level overrides | ||
| ClusterSetOverrides []ClusterSetManifestOverride `json:"clusterSetOverrides,omitempty"` |
There was a problem hiding this comment.
I would name it as Override, and user can choose to override by clusterset, or placement or per cluster. Try to make it extensible enough.
There was a problem hiding this comment.
Sounds good. In that case , We'll need to have this logic to iterate from Coarse Grained selector to Fine Grained selector while creating manifest works as same resource can be selected by two selectors.
Placement Override -> ClusterSet Override -> Cluster Override
There was a problem hiding this comment.
Maybe only separate by type, e.g.
overrides:
overrideStrategy: clustersets
clustersets:
- name: clusterset1
patch: .....
- name: clusterset2
and we can also choose placements
overrides:
overrideStrategy: placements
clustersets:
- name: aws-placement
patch: .....
- name: gke-placement
|
|
||
| type ResourceIdentifier struct { | ||
| APIVersion string `json:"apiVersion,omitempty"` | ||
| Kind string `json:"kind,omitempty"` |
There was a problem hiding this comment.
APIGroup/Version/Resource is preferred. We can reuse the existing resourceIdentifier
There was a problem hiding this comment.
Sure, will use the existing resource identifier.
|
|
||
| type OverrideSpec struct { | ||
| // Metadata overrides (name, namespace, labels, annotations) | ||
| MetadataOverride *MetadataOverride `json:"metadataOverride,omitempty"` |
There was a problem hiding this comment.
What does this for, why it cannot be part of general override?
There was a problem hiding this comment.
Initially thought of allowing template based override in metadataOverride like labels.cluster : {{clusterName}}
There was a problem hiding this comment.
I do not think we need to treat spec and metadata differently.
| MetadataOverride *MetadataOverride `json:"metadataOverride,omitempty"` | ||
|
|
||
| // JSON patch operations for spec modifications | ||
| SpecOverride []JSONPatch `json:"specOverride,omitempty"` |
There was a problem hiding this comment.
I would make it more extensible, someone might want to use json merge patch also.
There was a problem hiding this comment.
Cool, I will introduce Replace , StrategicMerge as two possible strategies for patching things.
There was a problem hiding this comment.
StrategicMerge will be tricky...we can start with JSONPatch/JSONMerge/Replace
| value: 500m | ||
| - op: replace | ||
| path: /spec/template/spec/containers/0/resources/requests/memory | ||
| value: 512Mi |
There was a problem hiding this comment.
what the type of the value it should be? number or string?
| metadataOverride: | ||
| labels: | ||
| environment: production | ||
| tier: high-performance |
There was a problem hiding this comment.
is this part a merge or replace operation?
| - **Multi-environment deployments**: Deploy the same application with environment-specific configurations (prod clusterSet: 5 replicas, staging clusterSet: 1 replica) | ||
| - **ClusterSet capacity optimization**: Adjust resource requests/limits based on clusterSet capacity profiles | ||
| - **Compliance requirements**: Apply different security contexts or labels based on clusterSet compliance levels | ||
| - **Regional customizations**: Use different images or configurations for different geographical clusterSets |
There was a problem hiding this comment.
Another use case would be different configurations in different cloud providers.
3 participants
No description provided.