Add cluster name to aggregated SI status on local SI creation #1521
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
...instead of when local EPS is synced to the broker. This can cause inconsistency if another service instance is unexported on another cluster simultaneously. The scenario is: - a service is exported on C2 - the service is then exported on C1. The local SI is created and it's observed that the aggregated SI on the broker already exists. - the service on C2 is unexported and the aggregated SI is deleted b/c its cluster status is now empty. - the local EPS on C1 is synced to the broker. At this point, it tries to update the aggregated SI with the cluster info but it no longer exists. There’s a couple ways to address it. 1) Do create-or-update when merging the local cluster info on EPS creation. The downside is that this wouldn’t do the service type conflict checking although the possibility that the SI was re-created by another cluster with a different service type in that window would be remote. 2) Add the cluster name to the aggregated SI cluster status when created on local SI creation. This would’ve prevented C1 from deleting the aggregated SI b/c C2's name would’ve been present in the cluster status. I didn’t do it this way for consistency so the cluster name and port info are added atomically and after the EPS has been successfully exported to ensure it’s ready for use if a consumer observes the cluster info present. But this isn’t a requirement. The consensus is #2. Signed-off-by: Tom Pantelis <[email protected]>
tpantelis
requested review from
aswinsuryan,
Oats87,
skitt,
sridhargaddam and
vthapar
as code owners
|
🤖 Created branch: z_pr1521/tpantelis/aggregated_si_cluster_status |
vthapar
approved these changes
Mar 22, 2024
vthapar
approved these changes
Mar 26, 2024
dfarrell07
approved these changes
Mar 27, 2024
|
🤖 Closed branches: [z_pr1521/tpantelis/aggregated_si_cluster_status] |
tpantelis
added a commit
to tpantelis/submariner-website
that referenced
this pull request
Mar 28, 2024
Release notes for submariner-io/lighthouse#1521 Signed-off-by: Tom Pantelis <[email protected]>
tpantelis
added a commit
to tpantelis/lighthouse
that referenced
this pull request
Apr 2, 2024
…1521-upstream-release-0.17
tpantelis
added a commit
to submariner-io/submariner-website
that referenced
this pull request
Apr 2, 2024
Release notes for submariner-io/lighthouse#1521 Signed-off-by: Tom Pantelis <[email protected]>
tpantelis
added a commit
to tpantelis/lighthouse
that referenced
this pull request
Apr 2, 2024
…1521-upstream-release-0.16
tpantelis
added a commit
to tpantelis/lighthouse
that referenced
this pull request
Apr 2, 2024
…1521-upstream-release-0.17
tpantelis
added a commit
to tpantelis/submariner-website
that referenced
this pull request
Jul 8, 2024
Release notes for submariner-io/lighthouse#1521 Signed-off-by: Tom Pantelis <[email protected]>
tpantelis
added a commit
to submariner-io/submariner-website
that referenced
this pull request
Jul 9, 2024
Release notes for submariner-io/lighthouse#1521 Signed-off-by: Tom Pantelis <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...instead of when local EPS is synced to the broker. This can cause inconsistency if another service instance is unexported on another cluster simultaneously. The scenario is:
There’s a couple ways to address it.
Do create-or-update when merging the local cluster info on EPS creation. The downside is that this wouldn’t do the service type conflict checking although the possibility that the SI was re-created by another cluster with a different service type in that window would be remote.
Add the cluster name to the aggregated SI cluster status when created or updated on local SI creation. In the above scenario, this would’ve prevented C1 from deleting the aggregated SI b/c C2's name would’ve been present in the cluster status. I didn’t do it this way for consistency so the cluster name and port info are added atomically and after the EPS has been successfully exported to ensure it’s ready for use if a consumer observes the cluster info present. But this isn’t a requirement.
The consensus is 2).