[kubernetes/kubernetes] Move ClientConnectionConfiguration struct to its own api group (#54318)
Andy Goldstein
As we are working towards configuring all server components with configuration files instead of command line flags, most or all of them are going to need to be configured to talk to the apiserver. We should make sure there is a single struct definition for the client configuration. Currently, in the componentconfig api group, we have ClientConnectionConfiguration, and it's only used by the KubeProxyConfiguration right now. We have multiple PRs in flight related to configuration APIs:
#53645 - move KubeProxyConfiguration out of componentconfig and into its own api group
#52562 - convert kube-scheduler to use a configuration file
The first PR, if merged, will move ClientConnectionConfiguration from componentconfig to kubeproxyconfig.k8s.io.
The second PR also needs to use ClientConnectionConfiguration, and ultimately needs to have the new scheduler config structs in their own new api group.
I propose we create another api group, something like kubeconfig.k8s.io, to house the ClientConnectionConfiguration struct, so it can be shared by multiple API groups needing to specify client connection configuration details.
WDYT?
@kubernetes/sig-api-machinery-api-reviews @jbeda @smarterclayton @deads2k @liggitt @sttts @luxas @mikedanese @mtaufen @timothysc
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Labels Incomplete
Action required: This issue requires label changes. If the required changes are not made within 2 days, the issue will be moved out of the v1.9 milestone.
kind: Must specify exactly one of kind/bug, kind/cleanup or kind/feature.
priority: Must specify exactly one of priority/critical-urgent, priority/important-longterm or priority/important-soon.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
@ncdc @kubernetes/sig-api-machinery-misc
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 6 days, the issue will be moved out of the v1.9 milestone.
sig/api-machinery: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Andy Goldstein
@ironcladlou since you're working on the scheduler config
Peter (XiangPeng) Zhao
FYI: Move KubeSchedulerConfiguration out of componentconfig API group #54211
@guangxuli
Clayton Coleman
move from Kubeconfig or are people going to want to do big refactors?
Unrelated note - has someone queued up making kubectl explain works with
the new server config types? Not being able to see config docs sucks.
On Oct 20, 2017, at 11:46 PM, Peter (XiangPeng) Zhao <
notifi...@github.com> wrote:
FYI: Move KubeSchedulerConfiguration out of componentconfig API group #54211
@guangxuli <https://github.com/guangxuli>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABG_p9N-D7dNx280Z7pnaN7T0Y1Fz_cEks5suWkrgaJpZM4QBFYT>
.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 5 days, the issue will be moved out of the v1.9 milestone.
sig/api-machinery: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Andy Goldstein
@smarterclayton I did the ones for KubeProxyConfiguration and I hope they're reasonable, but I wouldn't say they have much use elsewhere.
As to docs on the config, I have #52198... I hadn't even considered doing this via kubectl explain, but I think that's potentially much nicer. WDYT?
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 4 days, the issue will be moved out of the v1.9 milestone.
sig/api-machinery: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Timothy St. Clair
I'm a +1 for consolidating the data, but I question the long term utility of using the api for what are essentially command line args vs. a versioned config file.
/cc @mikedanese
David Eads
If we created a Kubeconfig group, are there unopinionated structs we can
move from Kubeconfig or are people going to want to do big refactors?
The kubeconfig structs are fairly generic. I'm not sure we'd bring in the authProvider bits since support for those requires tight integration, but the basic connection information isn't specific.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
@ncdc @kubernetes/sig-architecture-misc
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 3 days, the issue will be moved out of the v1.9 milestone.
sig/architecture: Issue will be escalated to these SIGs if needed.
priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Daniel Smith
This looks like an API change, not an API Machinery change? Feel free to reset the label if I misunderstood.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
@ncdc @kubernetes/sig-architecture-misc
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 2 days, the issue will be moved out of the v1.9 milestone.
sig/architecture: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
@ncdc @kubernetes/sig-architecture-misc
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 1 day, the issue will be moved out of the v1.9 milestone.
sig/architecture: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Josh Berkus
Should this be moved out of 1.9? The attached PRs for this issue don't seem to be near resolution.
Kubernetes Submit Queue
[MILESTONENOTIFIER] Milestone Issue Needs Approval
@ncdc @kubernetes/sig-architecture-misc
Action required: This issue must have the status/approved-for-milestone label applied by a SIG maintainer. If the label is not applied within 0 days, the issue will be moved out of the v1.9 milestone.
sig/architecture: Issue will be escalated to these SIGs if needed.priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts.kind/feature: New functionality.
—
Andy Goldstein
I chatted with @luxas briefly yesterday and this probably isn't critical for either of those PRs, so I'm removing the 1.9 milestone. These config structs aren't using protobuf (since we want human-readable/writeable config files), so if we happen to move the structs somewhere else, the json tags would remain the same.
Lucas Käldström
This will probably alpha in v1.9 anyway, right?
I'm fine with that
Mike Danese
What part of ClientConnectionConfiguration is not expressable in a kubeconfig yet?
Mike Danese
ref #30395
Andy Goldstein
Upon further reflection, I don't think we need a new api group for this. We just need a common package that component configuration api groups (kubeproxy, scheduler, etc) can import and use.
Lucas Käldström
@ncdc Go for it 😄!
This would be something like metav1 for kubeconfigs, right?
Gavin
@ncdc What's progress about creating a common package that put the common configuration? Need i start this work.
Andy Goldstein
@guangxuli sorry for the delayed response - I've been battling the flu.
We need to decide where to put it. Something like pkg/configapi maybe? I'm also wondering about how we deal with conversions between api versions for the actual config apis like kubeproxy. If we do this, ideally we'd just have a single package that has the common structs, and that could be referenced by both the internal and versioned component config api packages.
@liggitt do you have any recommendations?
Gavin
@ncdc that's ok, pay attention to your health.
fejta-bot
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
fejta-bot
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
/remove-lifecycle stale
fejta-bot
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
k8s-ci-robot
Closed #54318.
Lucas Käldström
/remove-lifecycle rotten
Lucas Käldström
Reopened #54318.
fejta-bot
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
fejta-bot
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
fejta-bot
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
k8s-ci-robot
@fejta-bot: Closing this issue.
In response to this:
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
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.
k8s-ci-robot
Closed #54318.
Lucas Käldström
This has been fixed, we just forgot to close it. Good that the bot now closed it 👍