docs: record what the upstream cluster name refers to - #343
Draft
ecv wants to merge 1 commit into
Draft
Conversation
The upstream cluster name label is the operator's record of the owning project, but nothing said so. Under the Milo provider the multicluster key is the name of the Project the cluster was discovered from; that fact lives in the milo module, not here, so reading this repo alone leaves the label looking like cluster plumbing with no project in it. The gap had already produced a wrong belief in tree. The extension server cache derives project names from exactly this label while carrying a TODO saying the project label is not available yet, which reads as a gap where there is none. Key changes: - Document on UpstreamOwnerClusterNameLabel what the name refers to per discovery mode, and that no project UID is available - Point UpstreamClusterNameFromLabel at that description, since it documented the encoding but not the meaning - Drop the stale TODO on ProjectNames and reference the label's description
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
meta.datumapis.com/upstream-cluster-nameis the operator's record of the owning project, and nothing in this repo said so. Under the Milo provider the multicluster key is the name of theProjectthe cluster was discovered from. That fact lives in the milo module, so reading NSO alone leaves the label looking like cluster plumbing with no project in it.That gap produced #339, which proposed adding a project label the operator already writes, and #340, which implemented it. Both closed. The belief was also already in tree:
extensionserver/cachederives project names from exactly this label while carrying a TODO saying the project label is not available yet, which reads as a gap where there is none.UpstreamOwnerClusterNameLabelnow documents what the name refers to per discovery mode (project name under Milo, the literalsingleotherwise) and that no project UID is available from the key.UpstreamClusterNameFromLabelpoints at that description. It documented thecluster-prefix, the slash encoding, and the legacy leading-slash form in detail, and never the referent.ProjectNamesTODO is dropped.Comments only, no behaviour change.
Test plan
go build ./...,gofmt, package tests for the two touched packages