-
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
✨ Implement ManifestWorkReplicaSet RollOut strategy #259
✨ Implement ManifestWorkReplicaSet RollOut strategy #259
Conversation
/hold |
2b5829a
to
8e17ac0
Compare
8e17ac0
to
bf8bf67
Compare
3de8620
to
917c5b1
Compare
Signed-off-by: melserngawy <melserng@redhat.com>
917c5b1
to
ab8273b
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #259 +/- ##
==========================================
+ Coverage 61.06% 61.61% +0.55%
==========================================
Files 129 132 +3
Lines 13771 13956 +185
==========================================
+ Hits 8409 8599 +190
- Misses 4588 4591 +3
+ Partials 774 766 -8
Flags with carried forward coverage won't be shown. Click here to find out more.
☔ View full report in Codecov by Sentry. |
a8b92f9
to
26cd588
Compare
/unhold |
26cd588
to
66a6f4c
Compare
/cc @qiujian16 |
/cc @haoqing0110 |
|
||
// Check for the expected manifestWorkReplicaSetSummary | ||
mwrSetSummary := workapiv1alpha1.ManifestWorkReplicaSetSummary{ | ||
Total: clsPerGroup + int(placement1.Status.NumberOfSelectedClusters), |
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.
What if there's clusters overlap in placement1 and placement2, will the cluster number be counted twice in the summary?
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.
We use the mwrSet name to create the mw , so if a cluster is selected twice in placement1 & placement2 what will happen is;
- For placement1; the cluster will get selected and the mw will be created with ref to placement 1 in its labels as here
- The placement1 Summary will count the cluster
- For placement2; the cluster will also get selected and the mw label ref to placement will be updated to refer to placement2 as here.
- The placement2 Summary will also count the cluster (cause now it is belong to it)
So yes, it will be counted for each placement Summary (as the placement doesn't know if the cluster is selected in another placement) AND will be counted twice in the mwrSet Summary.
I'm not really sure how the logic should be, should we raise error ? should we skip it ? is it okay to count the cluster twice as it is exist in both placements?
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.
My thought is a cluster counted twice makes the meaning of Total confusing to the user, since the actual number of ManifestWorks is less than it.
For addon, one addon only belongs to one placement (the latter one), and use that rollout strategy do rollout. It may not be the same as the mwrSet here, just for reference.
sorry I am stuck by other stuff this week, will go through this PR early next week. |
53b37d2
to
83f47f9
Compare
@@ -37,6 +37,10 @@ const ( | |||
// TODO move this to the api repo | |||
ManifestWorkReplicaSetControllerNameLabelKey = "work.open-cluster-management.io/manifestworkreplicaset" | |||
|
|||
// ManifestWorkReplicaSetPlacementNameLabelKey is the label key on manifestwork to ref to the Placement that select | |||
// the managedCluster on the manifestWorkReplicaSet's PlacementRef. | |||
ManifestWorkReplicaSetPlacementNameLabelKey = "work.open-cluster-management.io/PlacementName" |
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 label key should not have capital in 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.
ops, done
} | ||
for _, mw := range manifestWorks { | ||
// Check if ManifestWorkTemplate changes, ManifestWork will need to be updated. | ||
if !equality.Semantic.DeepEqual(mwrSet.Spec.ManifestWorkTemplate, mw.Spec) { |
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 check is not quite reliable, since there could diff on somefield with empty or nil values. It is better to user the work applier helper.
I think we should always apply, and check the returned updated value to know if if it is updated.
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.
okay, I used the workApplier.ManifestWorkEqual instead.
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.
Add a TODO here: we should have an interface in applier to check whether a mw should be applied.
} | ||
// applied and Progressing conditions return status as Progressing | ||
if apimeta.IsStatusConditionTrue(manifestWork.Status.Conditions, workv1.WorkApplied) || | ||
apimeta.IsStatusConditionTrue(manifestWork.Status.Conditions, workv1.WorkProgressing) { |
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.
do we have a WorkProgressing status right now?
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 don't think so unless you can point me. I checked the manifestWork controllers sounds like there is no WorkProgressing status defined yet. I added comment to clarify that.
clsRolloutStatus.Status = clusterv1alpha1.Succeeded | ||
} | ||
// Degraded condition return status as Failed | ||
if apimeta.IsStatusConditionTrue(manifestWork.Status.Conditions, workv1.WorkDegraded) { |
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.
There is not degraded status defined yet. We should add some note here.
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.
Yes, same there is no degraded status defined. I Considered the Applied condition with False status as Failed, added comments to clarify that.
83f47f9
to
8f69f82
Compare
Signed-off-by: melserngawy <melserng@redhat.com>
8f69f82
to
c182f35
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.
/approve
@haoqing0110 would you take a final look on this?
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qiujian16, serngawy 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 |
LGTM |
Yes, we decided to keep it as it is for now (manifestWork will be associated with the latest placement) cause it can be valid for both ways. Will wait for feedback if any changes is necessary. |
/lgtm |
35680c3
into
open-cluster-management-io:main
Summary
Related issue(s)
Fixes #