-
Notifications
You must be signed in to change notification settings - Fork 16
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
docs: managementv3 cluster support strategy #357
Merged
salasberryfin
merged 1 commit into
rancher:main
from
salasberryfin:adr-managementv3-clusters
Feb 1, 2024
Merged
docs: managementv3 cluster support strategy #357
salasberryfin
merged 1 commit into
rancher:main
from
salasberryfin:adr-managementv3-clusters
Feb 1, 2024
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
salasberryfin
added
the
kind/documentation
Improvements or additions to documentation
label
Jan 25, 2024
salasberryfin
force-pushed
the
adr-managementv3-clusters
branch
2 times, most recently
from
January 25, 2024 09:09
2e3bca9
to
cb9f670
Compare
salasberryfin
changed the title
"docs: managementv3 cluster support strategy"
docs: managementv3 cluster support strategy
Jan 25, 2024
salasberryfin
force-pushed
the
adr-managementv3-clusters
branch
from
January 26, 2024 17:06
cb9f670
to
bcd3549
Compare
I updated the ADR document and the PR description based on the feedback. Thanks @Danil-Grigorev @richardcase. |
4 tasks
salasberryfin
force-pushed
the
adr-managementv3-clusters
branch
from
January 29, 2024 09:42
bcd3549
to
eaea22b
Compare
Signed-off-by: Carlos Salas <carlos.salas@suse.com>
salasberryfin
force-pushed
the
adr-managementv3-clusters
branch
from
January 30, 2024 15:05
eaea22b
to
ef88764
Compare
Danil-Grigorev
approved these changes
Jan 30, 2024
richardcase
approved these changes
Jan 31, 2024
furkatgofurov7
approved these changes
Jan 31, 2024
Thanks for the comments and reviews folks. |
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.
What this PR does / why we need it:
This ADR is a proposal on how support for
management.cattle.io/v3
clusters is implemented, based on investigation during the development process.The main point of concern here is how we manage cluster naming. Since
management.cattle.io/v3
clusters are required to have a name that satisfies the stringc-
followed by exactly five characters, we cannot use the display name (the one that appears in Rancher dashboard) as we do withprovisioning.cattle.io/v1
clusters (where name and display name are the same).Creating a randomized 5-character suffix presents the challenge of not being able to track the resource while reconciling like we do in the existing
provisioning.cattle.io/v1
import controller, since we fetch the cluster onName
andNamespace
(refer to here).A reasonable alternative is to compute the SHA256 hash of the display name and then truncate the result to fit in the 5-character prefix of the name. This would make it easy and cheap to deterministically get the resource name based on the display name. The problem with this approach is that we could potentially encounter collisions if the number of clusters is large.We will be tracking the cluster based on two new labels that will be applied to all
management.cattle.io/v3
Rancher clusters that uniquely reference the CAPI cluster that owns the resource. Using this approach, we can leverage the built-in functionality of Kubernetes by passing the fieldGenerateName
with the prefixc-
so that it randomly generates a 5 character suffix that satisfies the regular expression, and retries if a name collision occurs.Which issue(s) this PR fixes:
Fixes #361
Special notes for your reviewer:
Checklist: