kubernetes-sigs
Provide ability to set annotations on worker nodes
User Story
As an operator I would like to have the ability to set annotations on worker nodes created by CAPI. This is similar to the ability to set labels which is being currently worked on.
Detailed Description
In many cases, annotations are used to set metadata on nodes. For example in OCI, compartment id can be set on nodes which will help in discovery of nodes by cloud provider, as well as lookup vnics. Other providers may also have such use cases.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
/kind feature
@shyamradhakrishnan: This issue is currently awaiting triage.
If CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
For example in OCI, compartment id can be set on nodes which will help in discovery of nodes by cloud provider, as well as lookup vnics.
I'm fine in general with the requirement.
Just a question about this specific case. I don't exactly know what a compartment is, but I wonder if it's the kind of metadata that in some clouds is provided by the cloud-provider running inside of the workload cluster.
/triage accepted /help
I think we should implement label propagation first, and then build on top of it
@fabriziopandini: This request has been marked as needing help from a contributor.
Guidelines
Please ensure that the issue body includes answers to the following questions:
- Why are we solving this issue?
- To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
- Does this issue have zero to low barrier of entry?
- How can the assignee reach out to you for help?
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.
In response to this:
/triage accepted /help
I think we should implement label propagation first, and then build on top of it
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
taints is important too. should that be another issue too or wrapped up with labels or annotations?
Label propagation has been supported by https://github.com/kubernetes-sigs/cluster-api/pull/7173. It would be a good time to step onto annotations. (AFAIK it's not implemented for now)
We may have two questions that need to have consensus:
Q1. Should we only allow annotations with predefined prefixes? Q2. Which annotation value should have precedence if the specified one on the Machine object exists on the corresponding Node object?
For labels, CAPI only allows propagating managed labels. To achieve the original motivation of this PR, I suppose we anyway need to allow arbitrary annotations on Machine objects to be propagated.
In terms of Q2, for labels, ones on Machine objects always have precedence. IMO it would make sense to follow the same policy for annotations as well.
I'm interested in working on implementation and ready to prepare a PR.
@fabriziopandini: The label(s) triage/backlog cannot be applied, because the repository doesn't have them.
In response to this:
/triage backlog
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.