KEP-1815: Add ComponentConfig ObjectMeta KEP

[phenixblue]

• Cleanup some things in README
• Update title
• Update KEP with issue number

[mtaufen]

/assign

[mtaufen]

/wg component-standard

[olemarkus]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[phenixblue]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[phenixblue]

/remove-lifecycle stale

[kikisdeliveryservice]

Hi all,

This PR has been open for 2.5 years. Will this KEP move forward or should it be closed and revisited?

Thanks!
Kirsten
SIG-Arch Enhancements Subproject

[phenixblue]

The working group has been disbanded so I'm not sure what it would take to move this forward. If someone else wants to try and push it forward I can help provide context. Otherwise I think it can be closed.

[olemarkus]

I am still interested in seeing this go in. And from what I can understand, this does not require much of a code change, nor does it have much risk. I am not familiar with the KEP process or whar it would take to get this in, but happy to help out any way I can.

[neolit123]

fwiw, in kubeadm's latest cc we decided to not add this. the only known use case was kustomize patching of cc files pre-passing them with --config to kubeadm, which is possible with manual edits to add "name". the embedded objectmeta also conflicted with a kubeadm clusterconfiguration "name".

the stock objectmeta has a lot of fields and the use cases for them are still not very clear to me. it would make some sense if we treat a cc object as a k8s object managed by controller.

[olemarkus]

The kOps use case is a bit narrow, but kops cli has a few command similar to kubectl apply that takes server configurations and saves them in the kOps state store. We use labels to determine things like which cluster the resource belongs to. So technically, a single file can update multiple clusters. Or files can update a different cluster than the current kube context. We'd like people to be able to bring their own CCs, but this is somewhat hard without making a lot of assumptions about what the user is trying to do.

As far as I know, for CC, it is only labels that we would be interested in. Possibly annotations as well (e.g to say ignore various validations or mutations kOps would do to ensure a working configuration).

[neolit123]

understood.
iirc, parts of the discussion on the kep was that the stock objectmeta is just not suitable for cc. perhaps we need a,more scoped one (and standardized). cluster api created their own similar object / struct for this.

potentialy a topic for the sig mailing list /zoom call if you wish to open the discussion.

[olemarkus]

I may have been too hastly. I can see we'd like to have metadata.name at least for KubeletConfiguration to allow different nodes to have different configurations. So that is most of ObjectMeta?

[neolit123]

name, labels, annotations are the known use cases to me.

[phenixblue]

Yeah, the intent was to closely mirror what was done in cluster-api

[olemarkus]

Namespace can definitely be skipped, and we I don't see that having both labels and annotations would serve any purpose.

Since selectors doesn't make that much sense for this, I'd be happy to have only annotations and name be in scope for now. I am also happy to do a separate smaller object as suggested in the KEP.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closed this PR.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Reopen this PR with /reopen
• Mark this PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.