Skip to content
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
20 tasks
justinsb opened this issue Oct 3, 2016 · 28 comments
Closed
20 tasks

Easier installation through componentconfig #115

justinsb opened this issue Oct 3, 2016 · 28 comments
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. stage/alpha Denotes an issue tracking an enhancement targeted for Alpha status tracked/no Denotes an enhancement issue is NOT actively being tracked by the Release Team
Milestone

Comments

@justinsb
Copy link
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

@deads2k
Copy link
Contributor

deads2k commented Oct 3, 2016

@ncdc

@idvoretskyi idvoretskyi modified the milestone: v1.5 Oct 11, 2016
@idvoretskyi idvoretskyi added the sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. label Oct 13, 2016
@idvoretskyi
Copy link
Member

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

@ncdc
Copy link
Member

ncdc commented Nov 17, 2016

@spiffxp
Copy link
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
Copy link
Contributor

mtaufen commented Dec 2, 2016

/cc @mtaufen

@roberthbailey
Copy link
Contributor

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

@ncdc
Copy link
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
Copy link
Contributor

@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
Copy link
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
Copy link
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
Copy link
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
Copy link
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
Copy link
Member

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

@luxas
Copy link
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?

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 27, 2017
@justaugustus
Copy link
Member

@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
Copy link

/cc @rsdcastro

@luxas
Copy link
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 Denotes an issue tracking an enhancement targeted for Alpha status and removed kind/feature Categorizes issue or PR as related to a new 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 justaugustus added the tracked/yes Denotes an enhancement issue is actively being tracked by the Release Team label Jul 31, 2018
@justaugustus
Copy link
Member

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

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jul 31, 2018
@zparnold
Copy link
Member

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
Copy link
Member

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

@sttts
Copy link
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
Copy link

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
Copy link

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 Denotes an enhancement issue is NOT actively being tracked by the Release Team and removed tracked/yes Denotes an enhancement issue is actively being tracked by the Release Team labels Oct 8, 2018
@deads2k
Copy link
Contributor

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.

@therealmitchconnors
Copy link
Contributor

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

howardjohn pushed a commit to howardjohn/enhancements that referenced this issue Oct 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. stage/alpha Denotes an issue tracking an enhancement targeted for Alpha status tracked/no Denotes an enhancement issue is NOT actively being tracked by the Release Team
Projects
None yet
Development

No branches or pull requests