Adding maxAvailableComponentSets to estimator interface #6765
Conversation
karmada-bot
added
the
kind/feature
Summary of ChangesHello @mszacillo, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the estimator framework by introducing a specialized interface for handling multi-component workloads. By creating a new Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
karmada-bot
added
the
size/S
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new ComponentSetEstimator interface to support replica estimation for multi-component workloads. This is a good approach as it extends the existing ReplicaEstimator without introducing breaking changes. The comments for existing interfaces and methods have also been improved for clarity.
I have one suggestion regarding the signature of the new MaxAvailableComponentSets method to ensure it can correctly handle multi-component requirements.
|
Hi @RainbowMango, I've currently listed the return type as |
mszacillo
force-pushed
the
replica-estimator
branch
from
519747c to
398e5e9
Compare
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6765 +/- ##
==========================================
+ Coverage 45.73% 45.82% +0.09%
==========================================
Files 689 690 +1
Lines 57152 57250 +98
==========================================
+ Hits 26136 26235 +99
- Misses 29384 29389 +5
+ Partials 1632 1626 -6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
pkg/estimator/client/interface.go
Outdated
| // ComponentSetEstimator extends ReplicaEstimator to handle multi-component workloads, | ||
| // where all components in a set must be scheduled together. | ||
| type ComponentSetEstimator interface { | ||
| ReplicaEstimator | ||
| // MaxAvailableComponentSets returns the maximum number of complete multi-component sets (in terms of replicas) that each cluster can host. | ||
| MaxAvailableComponentSets(ctx context.Context, clusters []*clusterv1alpha1.Cluster, components []*workv1alpha2.Component) ([]workv1alpha2.TargetCluster, error) | ||
| } |
There was a problem hiding this comment.
- The interface can have its own structure, it doesn't have to rely on the structure defined in the ResourceBinding API.
- We do need to think about how to let the ResourceBinding hold the
setconcept more straightforwardly. - I suggest having a struct to hold the request and response, respectively. That makes room for extending more parameters, like we are likely to have a field like
reserved resourcesto tell estimator implementations to reserve some resources before the estimation.
| // ComponentSetEstimator extends ReplicaEstimator to handle multi-component workloads, | |
| // where all components in a set must be scheduled together. | |
| type ComponentSetEstimator interface { | |
| ReplicaEstimator | |
| // MaxAvailableComponentSets returns the maximum number of complete multi-component sets (in terms of replicas) that each cluster can host. | |
| MaxAvailableComponentSets(ctx context.Context, clusters []*clusterv1alpha1.Cluster, components []*workv1alpha2.Component) ([]workv1alpha2.TargetCluster, error) | |
| } | |
| // ComponentSetEstimator extends ReplicaEstimator to handle multi-component workloads, | |
| // where all components in a set must be scheduled together. | |
| type ComponentSetEstimator interface { | |
| // MaxAvailableComponentSets returns, for each cluster, the maximum number of complete multi-component sets it can host. | |
| // The input is provided via a request struct to allow future extensibility, and the result reflects number of sets per cluster. | |
| MaxAvailableComponentSets(ctx context.Context, req *ComponentSetEstimationRequest) ([]ComponentSetEstimationResponse, error) | |
| } | |
| // ComponentSetEstimationRequest carries input parameters for estimating multi-component set availability per cluster. | |
| // Fields can be extended over time without changing the method signature. | |
| type ComponentSetEstimationRequest struct { | |
| // Clusters are the candidate clusters to estimate against. | |
| Clusters []*clusterv1alpha1.Cluster | |
| // Components are the components that form a multi-component workload. | |
| Components []*workv1alpha2.Component | |
| // Namespace is the namespace of the workload being estimated. | |
| // It is used by the accurate estimator to check the quota configurations | |
| // in the target member cluster. This field is required for quota-aware estimation. | |
| Namespace string | |
| } | |
| // ComponentSetEstimationResponse represents how many complete component sets a cluster can accommodate. | |
| type ComponentSetEstimationResponse struct { | |
| // Name is the cluster name. | |
| Name string | |
| // Sets is the maximum number of complete component sets that can be scheduled on the cluster. | |
| Sets int32 | |
| } |
There was a problem hiding this comment.
In addition, can we put the MaxAvailableComponentSets method into the legacy type ReplicaEstimator interface?
All we need to do is let the current estimator implementations(general-estimator and scheduler-estimator) to implement the new method. (Sure, we can have a dummy implementation in this PR.)
There was a problem hiding this comment.
We do need to think about how to let the ResourceBinding hold the set concept more straightforwardly.
To me set can just be an internal concept to the implementers of MaxAvailableComponentSets. At the end of the day, a set is comprised of replicas - why not just convert the unit of sets into replicas after the calculation if complete?
I suggest having a struct to hold the request and response, respectively. That makes room for extending more parameters, like we are likely to have a field like reserved resources to tell estimator implementations to reserve some resources before the estimation.
Sounds good! I wasn't sure if this was within the scope of the ticket, but happy to include this.
In addition, can we put the MaxAvailableComponentSets method into the legacy type ReplicaEstimator interface?
I had separated the interfaces specifically so I wouldn't need to make dummy implementations haha, but yes I can also do this if it makes this logically easier to follow.
There was a problem hiding this comment.
Updated - I've taken your suggestion to add the ComponentSetEstimationRequest to make the inputs more easily extensible. I also added back the MaxAvailableComponentSets into the original ReplicaEstimator interface and marked the implementations as TODO.
There was a problem hiding this comment.
Let me know if you have further questions / comments.
I think it's doable, at least for now, if you mean the number of replicas for each cluster (just one cluster for multiple components workload) is always |
No, the extended idea(should have another proposal before starting) is not in the scope. Currently we are still focusing on implementing the proposal. |
Something like that would work yes - as long as the maxSet calculation unit is consistent, the scheduler would still be able to make stack-ranked decisions on which cluster has the most available resources. |
mszacillo
force-pushed
the
replica-estimator
branch
from
398e5e9 to
bf30e9b
Compare
karmada-bot
added
size/M
Signed-off-by: mszacillo <[email protected]>
mszacillo
force-pushed
the
replica-estimator
branch
from
bf30e9b to
3c5bdfe
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: RainbowMango 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 |
karmada-bot
added
the
approved
4 participants
What type of PR is this?
/kind feature
What this PR does / why we need it:
Introduces a new method
MaxAvailableComponentSetswhich will return a list of TargetClusters, where the replica # will correspond to the total number of component sets for multiple-component CRDs.I decided to add the new method as a part of a separate interface called
ComponentSetEstimator. This was done because if you add theMaxAvailableComponentSets, all downstream implementers ofReplicaEstimatorwill expect an implementation ofMaxAvailableComponentSets.By adding a separate extended interface, other estimators (such as GeneralEstimator) can keep their implementations of ReplicaEstimator, and only estimators that support multi-component workloads will implement ComponentSetEstimator.
Which issue(s) this PR fixes:
Part of #6734
Does this PR introduce a user-facing change?: