New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easier installation through componentconfig #115

Closed
justinsb opened this Issue Oct 3, 2016 · 27 comments

Comments

@justinsb
Member

justinsb commented Oct 3, 2016

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
    • 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

This comment has been minimized.

deads2k commented Oct 3, 2016

@idvoretskyi

This comment has been minimized.

Member

idvoretskyi commented Nov 15, 2016

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

@ncdc

This comment has been minimized.

Member

ncdc commented Nov 17, 2016

@spiffxp

This comment has been minimized.

Member

spiffxp commented Nov 19, 2016

@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)

@idvoretskyi idvoretskyi modified the milestones: next-milestone, v1.5 Nov 23, 2016

@mtaufen

This comment has been minimized.

Contributor

mtaufen commented Dec 2, 2016

/cc @mtaufen

@roberthbailey

This comment has been minimized.

Member

roberthbailey commented Jun 7, 2017

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

@ncdc

This comment has been minimized.

Member

ncdc commented Jun 7, 2017

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

This comment has been minimized.

Member

roberthbailey commented Jun 7, 2017

@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

This comment has been minimized.

Member

liggitt commented Jun 7, 2017

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

This comment has been minimized.

Member

ncdc commented Jun 7, 2017

@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

This comment has been minimized.

Contributor

mtaufen commented Jun 7, 2017

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

This comment has been minimized.

Member

idvoretskyi commented Jun 8, 2017

@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

This comment has been minimized.

Member

mikedanese commented Jun 13, 2017

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

@luxas

This comment has been minimized.

Member

luxas commented Oct 27, 2017

@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?

@idvoretskyi

This comment has been minimized.

Member

idvoretskyi commented Jan 22, 2018

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

@errordeveloper

This comment has been minimized.

Member

errordeveloper commented Jan 22, 2018

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

@justaugustus

This comment has been minimized.

Member

justaugustus commented Apr 16, 2018

@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

This comment has been minimized.

rsdcastro commented Apr 17, 2018

@luxas

This comment has been minimized.

Member

luxas commented Jul 30, 2018

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.

@luxas luxas added stage/alpha and removed kind/feature labels Jul 30, 2018

@luxas luxas added this to the v1.12 milestone Jul 30, 2018

@luxas luxas assigned jbeda, sttts, luxas and thockin and unassigned justinsb Jul 30, 2018

@justaugustus

This comment has been minimized.

Member

justaugustus commented Jul 31, 2018

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

@zparnold

This comment has been minimized.

Member

zparnold commented Aug 20, 2018

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

This comment has been minimized.

Member

jimangel commented Aug 27, 2018

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

@sttts

This comment has been minimized.

Contributor

sttts commented Aug 27, 2018

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

@claurence

This comment has been minimized.

claurence commented Oct 5, 2018

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

This comment has been minimized.

Contributor

kacole2 commented Oct 8, 2018

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

@kacole2 kacole2 added tracked/no and removed tracked/yes labels Oct 8, 2018

@deads2k

This comment has been minimized.

deads2k commented Oct 11, 2018

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.

@deads2k deads2k closed this Oct 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment