-
Notifications
You must be signed in to change notification settings - Fork 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
clustermesh: fix a few issues in the new mcs api service controller #32555
Conversation
9735e3f
to
dd3b8f1
Compare
/test |
CC: @giorio94 |
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 you elaborate more about how this annotation is used within the service importing/exporting flow? Currently it is very hard to follow it.
Sure! Will try to explain it a bit better on the commit description/code comment but in the meantime here is an explanation: This mcsapi implementation relies on a derived service that inherits mainly from the ServiceImport object. The spec of this derived service (named As the derived service is already the aggregated/conflict resolved version we need to somehow have a way to find which cluster has what property before aggregating them, this is maybe a bit unclear in this PR because this part is not present yet. The aggregation/conflict resolution will be in another controller whose job is to create ServiceImport. I made already good progress on this but I need to polish it a bit more and I wanted to split a bit the review load (but then I realized that it made this PR a bit unclear sorry). |
@MrFreezeex Hi, thanks for your clarification!
Ok, then my next question is we could get this disaggregated information from ServiceExport + the actual exported service. Then why do we need to introduce this new annotation? |
I second Yutaro's comment, here. It would be nice to have a diagram (maybe linked to the original issue) which depicts the flows you are thinking about, both in terms of what users would do, and what Cilium will automatically do to reconcile the information. That would help a lot in being able to properly review this PR (and the follow-ups), as we are otherwise missing the context about the next steps, and it becomes difficult to provide useful comments. |
0eb759c
to
96c5712
Compare
@giorio94 @YutaroHayakawa @joamaki thanks for the feedback, I will try to create a dedicated CFP issue with some schema of what the |
96c5712
to
76e1e29
Compare
/test |
Hi! Since we are having a separate discussion for how data should be shared across clusters to allow automatic ServiceImport creation I dropped the second commit about that and only kept the first one which brought a few fixes. I wanted to keep same PR so that the assigned reviewers don't change (although now it should probably be a sig-clustermesh only change), hopefully that's ok 😅. |
76e1e29
to
2f9a818
Compare
This commit does 3 small fixes: - Use the correct upstream MCS-API controller. The controller used is now the ones that sync the service IP to the ServiceImport resources. The rest of the controllers are Cilium specific and will (or already is) be implemented soon. - Also add a shortcut on creation to save a delete/recreate on of the derived service if there is no ServiceImport and the local is headless. - Fix the watch on Services to also issue a reconcile if the locally exported Service has changed Signed-off-by: Arthur Outhenin-Chalandre <arthur@cri.epita.fr>
2f9a818
to
5afd286
Compare
/test |
/ci-e2e |
/ci-runtime |
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.
These cleanup changes look good to me, thanks!
And sorry for the delay in reviewing the CFP, I plan to share my comments by today.
Jussi's concern has been addressed, and his review is no longer strictly required, given that all changes are clustermesh-related only now. Marking as ready to merge to unblock. |
Please ensure your pull request adheres to the following guidelines:
description and a
Fixes: #XXX
line if the commit addresses a particularGitHub issue.
Fixes: <commit-id>
tag, thenplease add the commit author[s] as reviewer[s] to this issue.
This commit does 3 small fixes:
is now the ones that sync the service IP to the ServiceImport resources.
The rest of the controllers are Cilium specific and will (or already is)
be implemented soon.
of the derived service if there is no ServiceImport and the local is
headless.
exported Service has changed
Related to #27902