Closed jcrowthe closed 4 years ago
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
/sig multicluster
Part of the concept of a "cluster registry" includes the idea that clusters may either be homogenous or heterogeneous. For the latter, this raises a need to register all clusters in one place in a way that will keep track of each clusters' differences.
This is a feature request to support the addition of custom metadata to the registry CRD. This metadata should be somewhat "free-form", where the end user may define custom key/value pairs which include more information useful to the user.
This feature is similar in many ways like the native kubernetes
annotations
object, where a user may attach custom key/value pairs to each object instantiation. However, I'd recommend against using native annotations directly for this purpose. A strong example of "why not" is found inIngress
objects -- annotations were used (and abused) because the Ingress spec did not accommodate custom needs. Instead of going down that route, I'd recommend making custom metadata into a first class citizen inside theCluster
CRD.Some examples of metadata a team might want to include:
This feature request is particularly useful when a team operates >10 clusters (which I believe aligns perfectly with the intent of this project). In my team's particular use case, we already run hundreds of clusters and only intend a 2-3x increase in the immediate future.
Hopefully this request is well described. If not, feel free to ask questions!