-
Notifications
You must be signed in to change notification settings - Fork 94
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
🌱 placement support decision groups #200
🌱 placement support decision groups #200
Conversation
89a6de6
to
59e5c68
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #200 +/- ##
==========================================
+ Coverage 59.91% 60.14% +0.23%
==========================================
Files 128 128
Lines 13241 13376 +135
==========================================
+ Hits 7933 8045 +112
- Misses 4568 4585 +17
- Partials 740 746 +6
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
59e5c68
to
d721dd5
Compare
…nagement-io#200) Signed-off-by: Wei Liu <liuweixa@redhat.com>
d721dd5
to
05c277b
Compare
05c277b
to
21892ee
Compare
/assign @qiujian16 @serngawy |
// ScheduleResult is the result for a certain schedule. | ||
type scheduleResult struct { | ||
feasibleClusters []*clusterapiv1.ManagedCluster | ||
scheduledDecisions []clusterapiv1beta1.ClusterDecision |
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 actually think the scheduledDecisions here should be []*clusterapiv1.ManagedCluster,
And you should have a process like
- schedule
- generateDecision
- bind
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.
Change to []*clusterapiv1.ManagedCluster and update the placement decision generate and update flow.
}) | ||
|
||
// generate placement decisions, group index starts from 0, decision name index starts from 1 for readability. | ||
pds, groupStatus := c.generatePlacementDecisionsAndStatus(placement, decisionGroup, decisionGroupIndex, placementDecisionIndex+1) |
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 weird. the two should at least start with the same index
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.
change to start from 0.
assertNumberOfDecisions(placementName, namespace, 0, 1) | ||
}) | ||
|
||
ginkgo.It("Should update the decision group once clusters belong to labelselector clusterset are added/deleted", func() { |
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 also have a static group field? should we also test it?
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.
Updated the case.
a754dca
to
d5af93d
Compare
d5af93d
to
dd41ad5
Compare
9b14b19
to
37c85a6
Compare
// The group length depends on ClustersPerDecisionGroup. | ||
if len(clusterNames) > 0 { | ||
matched := []clusterapiv1beta1.ClusterDecision{} | ||
for _, cluster := range clusters { |
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.
why we do not directly iterate the clusterNames, but still iterate cluster?
can we do something like
for len(clusterNames) > 0 {
clusterList := clusterNames.List()
resultNumber := len(clusterList)
if length < resultNumber {
resultNumber = length
}
matched := []clusterapiv1beta1.ClusterDecision{}
for i:=0; i<resultNumber; i++ {
matched = append(matched, clusterapiv1beta1.ClusterDecision{
ClusterName: clusterList[i],
})
delete(clusterNames, clusterList[i])
}
decisionGroup := clusterDecisionGroup{
decisionGroupName: "",
clusterDecisions: matched,
}
groups = append(groups, decisionGroup)
}
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.
why we do not directly iterate the clusterNames, but still iterate cluster?
This is to ensure the dynamic group clusters are always in the same order. The above suggestion looks good.
One question is, when the group length is 0, do we expect it to be the same as 100%, or expect no group (all the clusters not selected by the decision group will not be shown in the placement decision)? or we expect the length to be at least 1?
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.
should be 100% I think
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.
actual I do not think it could be 0, we should validate on API.
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.
Update code, and will update the api in another PR.
37c85a6
to
24e0ec5
Compare
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haoqing0110, qiujian16 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 |
Signed-off-by: haoqing0110 <qhao@redhat.com>
Signed-off-by: haoqing0110 <qhao@redhat.com>
Signed-off-by: haoqing0110 <qhao@redhat.com>
Signed-off-by: haoqing0110 <qhao@redhat.com>
Signed-off-by: haoqing0110 <qhao@redhat.com>
Signed-off-by: haoqing0110 <qhao@redhat.com>
24e0ec5
to
38a2716
Compare
/lgtm |
Summary
Related issue(s)
#236