-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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 MHCClass spec and details to proposal #5511
📖 Add MHCClass spec and details to proposal #5511
Conversation
a104275
to
e4fdb47
Compare
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.
a good description of MHCClass, thanks
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
thanks @killianmuldoon. This seems reasonable to me, dropped some comments. |
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.
Can you update the example ClusterClass defined in l756-l799 to include machine health checks and may be add a comment above them saying the value will be defaulted (if you are going with the empty object example)?
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
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 generally makes sense to me, i do think we should be crafting the API in a way that makes adding future integrations in consistent manner. added a thought inline
// MachineHealthCheckClass defines a MachineHealthCheck for each | ||
// ControlPlaneClass and MachineDeploymentClass in this ClusterClass. | ||
// +optional | ||
MachineHealthCheck *MachineHealthCheckClass `json:"machineHealthCheck,omitempty"` |
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.
instead of adding this as a top level entry, i wonder about having a field for "lifecycle integrations" or similar, to accommodate a future where we include more components?
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.
That's a good idea, but I guess we'd want to be clear that we're definitely looking to add more integrations (and that they'd be limited to lifecycle integrations instead of something else).
I don't think we have an answer on this yet. I'll open an issue to cover whether and which integrations we should be thinking about for clusterClass.
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 think we should be specific here and keep it as is.
I think we can always add other features with additional individual fields and if we want to group them at some point we can deprecate + merge.
For now it would be very speculative as we don't know how/if other features are added.
- ClusterResourceSet seems to be out-of-scope of ClusterClass at the moment (as it's orthogonal to ClusterClass and applies across multiple clusters)
- Autoscaler:
- labels can be already added today with our metadata fields
- deploying the autoscaler itself seems to rather fit into ClusterAddons bucket (Security Self Assessment: [STRIDE-INFODISCLOSE-1] RFE cluster addons #5491)
Overall ClusterClass itself is all about the cluster lifecycle, so I'm not sure an additional field/level like integrations
or lifecycleIntegrations
would add a lot of benefit and depending on which and how we add additional features the field name might not fit.
So I would suggest, let's choose the best field name / structure we can right now, and potentially improve it over time, once we know how/if other features are added.
@elmiko WDYT?
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.
@sbueringer i think your reasoning makes good sense. i would be happy to see the integration defined better in an enhancement that comes out of #5491.
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.
Could we move this definition under WorkersClass
? And specify that this one will be applied to each one of the MachineDeployment classes unless they supply their own configuration/overrides?
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 think the most straightforward implementation is to define this on the lowest levels. If we want overriding behaviour later on we can introduce the higher level workerClass MHC.
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.
Having the MHC Class top level can be confusing to users, because it's one level above ControlPlane so folks might think that there is some layering in place.
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.
+1 to have MHC only inside CP and MD for the first iteration (and thus to remove it from here)
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
|
8cc4fce
to
b1e509e
Compare
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
4d54a51
to
92e0441
Compare
lgtm pending squash from my side |
92e0441
to
1949797
Compare
1949797
to
3f4e9e4
Compare
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.
a couple of nits
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
6de3d3b
to
ffcda0b
Compare
docs/proposals/202105256-cluster-class-and-managed-topologies.md
Outdated
Show resolved
Hide resolved
ffcda0b
to
4bebddb
Compare
/test pull-cluster-api-verify-main |
Signed-off-by: killianmuldoon <kmuldoon@vmware.com>
4bebddb
to
1eb6d00
Compare
/lgtm |
/lgtm |
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.
+1 from me, thanks for all the hard work @killianmuldoon
Thanks! |
@@ -291,6 +305,42 @@ type LocalObjectTemplate struct { | |||
// offered by a provider. | |||
Ref *corev1.ObjectReference `json:"ref"` | |||
} | |||
|
|||
// MachineHealthCheckClass defines a MachineHealthCheck for a group of Machines. | |||
type MachineHealthCheckClass struct { |
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.
The fields below seem to be mostly duplicates of the fields in MachineHealthCheckSpec
. Are we concerned this might cause some trouble long-term for maintenance? How do we ensure the two don't diverge? What if a new feature is added to one place but not the other? Have we considered sharing a common struct so they can share the fields that are in both places or making one a subset of the other?
Please let me know if this comment feels out of scope. I realize this is a pattern that exists in other places in ClusterClasses, which is why this may be a bigger discussion.
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.
+1 to start working on some guidelines for common structs, given that this was discussed also in last week office hours
I don't want to hold this proposal on the discussion of sharing fields vs. duplicating but I feel it's a conversation we should have. Overall the proposal is sound and nothing jumps at me. /lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini 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 |
What this PR does / why we need it:
This PR adds information to the ClusterClass proposal describing how MachineHealthChecks can be added to the API so that clusters stamped from a particular ClusterClass have MachineHealthChecks generated for them from a common spec.
This proposal also introduces full defaulting for a MachineHealthChecks generated from a ClusterClass meaning that the check itself needs only be added as an empty struct to the ClusterClass in order to get a standard MHC configuration generated.
C/F #5125