Enhancements: Easier installation through componentconfig

[justinsb]

Description

As part of the work to make installation/operation easier being done by sig-cluster-lifecycle, we are going to continue to make configuration more dynamic, through ongoing work on componentconfig.

Progress Tracker

• [ ] Before Alpha
  
  
  
  • [ ] Write and maintain draft quality doc
  
  
  • [ ] During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK
  
  
  • [ ] Design Approval
  
  
  • [ ] [Design Proposal](https://docs.google.com/document/d/1arP4T9Qkp2SovlJZ_y790sBeiWXDO6SG10pZ_UUU-Lc/edit)
  
  
  • [ ] Identify shepherd: @mikedanese, @roberthbailey
  
  
  • [ ] Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS
  
  
  • [ ] Code needs to be disabled by default. Verified by code OWNERS
  
  
  • [ ] Minimal testing
  
  
  • [ ] Minimal docs
    
    
    
    
    
    • cc @kubernetes/docs on docs PR
    
    
    
    • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
    
    
    
    • New apis: _Glossary Section Item_ in the docs repo: kubernetes/kubernetes.github.io
    
    
    
  
  
  • [ ] Update release notes
  
  
• [ ] Before Beta
  
  
  
  • [ ] Testing is sufficient for beta
  
  
  • [ ] User docs with tutorials
  
  
  • _Updated walkthrough / tutorial_ in the docs repo: kubernetes/kubernetes.github.io
  
  
  • cc @kubernetes/docs on docs PR
  
  
  • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  
  
  • [ ] Thorough API review
  
  
  • cc @kubernetes/api
  
  
• [ ] Before Stable
  
  
  
  • [ ] docs/proposals/foo.md moved to docs/design/foo.md
  
  
  • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  
  
  • [ ] Soak, load testing
  
  
  • [ ] detailed user docs and examples
  
  
  • cc @kubernetes/docs
  
  
  • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  
  

_FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers._
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

• Once you get LGTM from a _@kubernetes/feature-reviewers_ member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

• Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
• As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
  and sometimes http://github.com/kubernetes/contrib, or other repos.
• When you are done with the code, apply the "code-complete" label.
• When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
  check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
  testing. They won't do detailed code review: that already happened when your PRs were reviewed.
  When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

• [ ] Write user docs and get them merged in.
• User docs go into http://github.com/kubernetes/kubernetes.github.io.
• When the feature has user docs, please add a comment mentioning @kubernetes/docs.
• When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

[deads2k]

@ncdc

[idvoretskyi]

@justinsb any updates on this issue? Can you provide the actual status of it and update the checkboxes above?

[ncdc]

Related: https://github.com/kubernetes/kubernetes/issues/32215 and https://github.com/kubernetes/kubernetes/pull/34727

[spiffxp]

@justinsb @idvoretskyi this needs an alpha-in-1.5, beta-in-1.5, or stable-in-1.5 label if it's going to be included in release notes for kubernetes 1.5; it has no stage listed in this spreadsheet... if it's not going into 1.5, we should remove it from that spreadsheet (yay multiple information sources)

[mtaufen]

/cc @mtaufen

[roberthbailey]

@mikedanese - can you update this with the current status? We should also turn your google doc into MD and link that PR here.

[ncdc]

I may have some small-to-medium amount of bandwidth to work on this. I think trying to convert the scheduler to use config would be a good next step. Also, it sounds like we need to split out each component's configuration api types into individual api groups, instead of one big componentconfig group.

[roberthbailey]

@ncdc - the current proposal is to use config maps rather than explicit api types. Take a look at https://docs.google.com/document/d/1arP4T9Qkp2SovlJZ_y790sBeiWXDO6SG10pZ_UUU-Lc/edit

w.r.t. the scheduler, can you coordinate with @timothysc as he mentioned during the last cluster lifecycle meeting that he was going to propose to the scheduling sig that we migrate the scheduler in the 1.8 timeframe.

[liggitt]

the current proposal is to use config maps rather than explicit api types.

I don't think that's accurate. Configmaps may be the delivery mechanism, but the content should still be structured and versioned, as an API type

[ncdc]

@roberthbailey what @liggitt wrote - we will be using explicit api types, potentially delivered inside of config maps :) and yes, already coordinating with Tim - we talked about this yesterday, in fact.

[mtaufen]

As others have mentioned here, components should ultimately expose explicit, versioned configuration API types from their independent trees (e.g. pkg/kubelet/apis). How you choose to deliver objects that satisfy these types to your component is up to you - use a file or files on disk, or use a ConfigMap, or whatever is appropriate for that component.

[idvoretskyi]

@mikedanese I've noticed that active work is ongoing for this feature; also it has been added to 1.7 features spreadsheet. Are you expecting to have this feature delivered for 1.7 or later? I would remind you that feature freeze and code freeze for 1.7 have already passed.
cc @kubernetes/sig-cluster-lifecycle-feature-requests

[mikedanese]

I expect that this feature will be implemented over the next couple releases. What's done is merged for 1.7.

[luxas]

@roberthbailey @ncdc @sttts I think we should open targeted issues for the different components (i.e. filing an issue for graduating the kube-proxy ComponentConfig to GA, separately from the scheduler)

@kubernetes/sig-cluster-lifecycle-feature-requests @kubernetes/sig-api-machinery-feature-requests WDYT?

[roberthbailey]

That makes sense to me. Each sub-issue can be owned by the SIG that is actually doing the migration.

It's too bad there isn't a way to explicitly mark one github issue as blocking another. We'll have to do the dependency analysis manually and close this umbrella issue once each component that we care about has migrated over.

[idvoretskyi]

@justinsb @mikedanese @kubernetes/sig-cluster-lifecycle-feature-requests any progress on this feature?

[errordeveloper]

There has been progress, but I don't have exact details at hand, but @roberthbailey may be able to summarise.

[justaugustus]

@justinsb @mikedanese @roberthbailey @kubernetes/sig-cluster-lifecycle-feature-requests Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

[rsdcastro]

/cc @rsdcastro

[luxas]

There have been great progress on this lately, the KEP for this has been accepted.
The initial PRs for this will be merged in the v1.12 timeframe.

[justaugustus]

Thanks for the update! I've added this to the 1.12 tracking sheet.
/kind feature

[zparnold]

Hey there! @justinsb I'm the wrangler for the Docs this release. Is there any chance I could have you open up a docs PR against the release-1.12 branch as a placeholder? That gives us more confidence in the feature shipping in this release and gives me something to work with when we start doing reviews/edits. Thanks! If this feature does not require docs, could you please update the features tracking spreadsheet to reflect it?

[jimangel]

@jbeda @stts @luxas @thockin Bump for docs ☝️

[sttts]

We do not change the user facing interface for componentconfig in 1.12. Hence, this won't need doc changes.

[claurence]

Kubernetes 1.13 is going to be a 'stable' release since the cycle is only 10 weeks. We encourage no big alpha features and only consider adding this feature if you have a high level of confidence it will make code slush by 11/09. Are there plans for this enhancement to graduate to alpha/beta/stable within the 1.13 release cycle? If not, can you please remove it from the 1.12 milestone or add it to 1.13?

We are also now encouraging that every new enhancement aligns with a KEP. If a KEP has been created, please link to it in the original post. Please take the opportunity to develop a KEP

[kacole2]

@luxas @sttts and updates from @claurence's post if there are plans to graduate in 1.13? Thanks!

[deads2k]

I think this has been superceded by https://github.com/kubernetes/community/blob/master/keps/sig-cluster-lifecycle/0014-20180707-componentconfig-api-types-to-staging.md . If I've made a mistake, feel free to re-open, but that KEP is a cross component effort to resolve this.

[therealmitchconnors]

The k8s community repo has been reorganized. The KEP for component config can now be found here:
https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/0014-20180707-componentconfig-api-types-to-staging.md