How will k8s.io/component-base be different from k8s.io/utils aka https://github.com/kubernetes/utils/?

@pohly k8s.io/utils cannot depend on kube libraries. In contrast, component-base builds on-top of client-go and apimachinery.

/stage alpha
I'm going to take a guess that this is planned for alpha based on https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/0032-create-a-k8s-io-component-repo.md#timeframe-and-implementation-order referencing v1alpha1

@luxas are there any open PRs in k/k that need to be merged (in addition to the one referenced above) for this to be in 1.14? Code freeze is 3/7 and if the PRs are not able to merge by then this issue will be removed from the milestone.

Got it. We have a few things in the pipeline, but not all PRs intended to be merged published yet. We'll let you all know how it goes closer to the deadline. However, this is not as critical as a feature in the sense that it's a step-by-step refactor, so it can "stop" at any time and just continue when the next cycle opens, without disrupting anything.

@luxas looking over the KEP for this enhancement I don't see any testing plans - can someone help PR in testing plans for this enhancement? This information is helpful for knowing readiness of this feature for the release and is specifically useful for CI Signal.

If we don't have testing plans this enhancement will be at risk for being included in the 1.14 release

Hey @luxas Just a friendly reminder we're looking for a PR against k/website (branch dev-1.14) due by Friday, March 1. It would be great if it's the start of the full documentation, but even a placeholder PR is acceptable. Let me know if you have any questions!

@luxas Friendly ping on the call to action in the previous two comments. Thanks

This is an ongoing refactor, where (IMO) neither of the comments above apply, as this is not a "normal" feature/enhancement. This issue was created purely for visibility reasons. That said, we've moved some packages, but not all of those we want yet. This effort will span many releases, with no user-facing changes (hence no docs). There is no dedicated "testing plan" for this either, as the Go files will "just" be tested with normal unit tests as any other files in the repo.

Does this make sense to you? Thanks!

@luxas Some questions I have based on what I see in the KEP (I will ping #sig-cluster-lifecycle as I think you may not be super available)

• What parts of the KEP are done? The timeframe and implementation order lead me to believe ComponentConfig should exist and be used, with all common flag parsing moved to k8s.io/component-base/cli. Is this the case?
• I need to understand if any of this refactored or moved code is being exercised as part of our release-blocking jobs, or if that isn't intended to happen for quite some time
• There was a step that claimed a k8s.io/sample-component repo would exist, with documentation on how to consume k8s.io/component-base. Is this the case?
• If I migrate an existing cluster from 1.13 to 1.14, will this enhancement impact my upgrade or downgrade process at all?

Response on #sig-cluster-lifecycle by @mtaufen after I pinged, with some liberties edited in for the benefit of markdown formatting:

I want @luxas and @sttts to weigh in and correct anything I get wrong below, but to the best of my knowledge:

1. ComponentConfig being used is an incremental migration on a per-component basis. Not sure how much progress each component has made, or if any have tried to move their APIs to beta this cycle (each should have an independent enhancements issue for that if they are working on it). The part in that KEP is about moving some of the core pieces to a standard location. The flag parsing was moved in Move flag util pkgs to k8s.io/component-base/cli kubernetes#73408, for example.
2. If it's code that has moved, it should still be exercised in whatever test jobs were exercising it before (component-base is a staging repo so it's tantamount to moving code to another directory, internally).
3. I don't think sample-component exists yet.
4. Assuming we did everything right, moved code should not result in behavioral changes. Going by the links in the wg-component-standard meeting notes, these are the related PRs that have merged for 1.14:
   • Move flag util pkgs to k8s.io/component-base/cli kubernetes#73408
   • Move of logs out of apiserver and into component-base kubernetes#72890
   • Break out common API testing functionality from pkg/master kubernetes#72580
   • [*-controller-manager]get rid of copied fields in the options and using componentconfig fields kubernetes#70472
   • Implement the --controllers flag fully for the cloud-controller manager kubernetes#68283

So in sum: Some parts of that 1.14 goal in the KEP look done, some not. Since the whole thing is a bundle of incremental work anyway I (personally) don't think any unfinished parts of the 1.14 goal are worth blocking the release on. @luxas or @sttts can correct me if there's unfinished release-critical work remaining for 1.14, though.

Summarizing followup chat in the same place:

• it sounds like it's too early to discuss this in the context of "extensibility" and "stability"
• it be worth revisiting once we actually have more ComponentConfig's, at present it seems like maybe only kublet and kube-scheduler use them

Based on the above, I am inclined to suggest we punt this out of v1.14, as it doesn't appear to be landing in a way that could be called "complete" even for alpha. Further, I would suggest we /hold any further PR's that attempt to land after code freeze.

Given conversation in slack, this thread and the release meeting this item is being removed from the 1.14 milestone

I'm the enhancement lead for 1.15. Please let me know if this issue will have any work involved for this release cycle and update the original post reflect it. Otherwise it will not be tracked. Thanks!

@luxas I'm one of the 1.16 Enhancement Shadows. Is this feature going to be graduating alpha/beta/stable stages in 1.16? Please let me know so it can be added to the 1.16 Tracking Spreadsheet. If it's not graduating, I will remove it from the milestone and change the tracked label.

Once coding begins or if it already has, please list all relevant k/k PRs in this issue so they can be tracked properly.

Milestone dates are Enhancement Freeze 7/30 and Code Freeze 8/29.

Thank you.

assigning @stealthybox as the contact and lead of this feature as per the discussion on slack with @sttts

@mrbobbytables
i will leave it this outside of the milestone, until further notice from @stealthybox

i personally think that while a KEP made sense to present the overall approach, this should not have been tracked as a common k8s feature. it's code re-organization and refactor, probably won't have e2e tests or k/website docs, but may have some k/component-base docs and some overall alpha/beta/GA state of the repo.

Updated link to KEP (old one is broken): https://github.com/kubernetes/enhancements/blob/master/keps/sig-cluster-lifecycle/wgs/0032-create-a-k8s-io-component-repo.md

Hey there @stealthybox @mtaufen , 1.17 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating to alpha/beta/stable in 1.17?

The current release schedule is:

• Monday, September 23 - Release Cycle Begins
• Tuesday, October 15, EOD PST - Enhancements Freeze
• Thursday, November 14, EOD PST - Code Freeze
• Tuesday, November 19 - Docs must be completed and reviewed
• Monday, December 9 - Kubernetes 1.17.0 Released

If you do, I'll add it to the 1.17 tracking sheet (https://bit.ly/k8s117-enhancement-tracking). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Did you come to a consensus on whether to track this as a single PR? In that case, you can make it as an Umbrella which can track other KEPs that can be defined into graduation stages (alpha/beta/stable).

Thanks!

I think our answer from 1.16 is unchanged - this is a super-KEP that is too broad to be tracked in a single milestone.

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

/remove-lifecycle stale

Hi @stealthybox -- 1.18 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating to alpha|beta|stable in 1.18?

The current release schedule is:
Monday, January 6th - Release Cycle Begins
Tuesday, January 28th EOD PST - Enhancements Freeze
Thursday, March 5th, EOD PST - Code Freeze
Monday, March 16th - Docs must be completed and reviewed
Tuesday, March 24th - Kubernetes 1.18.0 Released

To be included in the release, this enhancement must have a merged KEP in the implementable status. The KEP must also have graduation criteria and a Test Plan defined.
If you would like to include this enhancement, once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍
We'll be tracking enhancements here: http://bit.ly/k8s-1-18-enhancements
Thanks!

As a reminder @stealthybox :

Tuesday, January 28th EOD PST - Enhancements Freeze

Enhancements Freeze is in 7 days. If you seek inclusion in 1.18 please update as requested above.

Thanks!

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

/remove-lifecycle stale

/lifecycle frozen

Enhancement issues opened in kubernetes/enhancements should never be marked as frozen.
Enhancement Owners can ensure that enhancements stay fresh by consistently updating their states across release cycles.

/remove-lifecycle frozen

Hi @luxas @stealthybox
1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

In order to have this part of the release:

The KEP PR must be merged in an implementable state
The KEP must have test plans
The KEP must have graduation criteria.

The current release schedule is:

Monday, April 13: Week 1 - Release cycle begins
Tuesday, May 19: Week 6 - Enhancements Freeze
Thursday, June 25: Week 11 - Code Freeze
Thursday, July 9: Week 14 - Docs must be completed and reviewed
Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

Please let me know and I'll add it to the 1.19 tracking sheet (http://bit.ly/k8s-1-19-enhancements). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

As a reminder, enhancements freeze is tomorrow May 19th EOD PST. In order to be included in 1.19 all KEPS must be implementable with graduation criteria and a test plan.

Thanks.

Unfortunately the deadline for the 1.19 Enhancement freeze has passed. For now this is being removed from the milestone and 1.19 tracking sheet. If there is a need to get this in, please file an enhancement exception.

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

/remove-lifecycle stale

Hi @stealthybox

Enhancements Lead here. Are there any plans for this 1.20?

Thanks!
Kirsten

Perhaps this should be marked as external, given it is about work on an external repository (even if published from k/k/staging).

Whatever we can do to avoid future confusion. Maybe we even just close this issue. The KEP merged, we created the repo, and lots of things have been refactored into it. I would like to see some focus on getting the shared APIs in component-base graduated beyond v1alpha1, but future work can be covered by future KEPs. This issue keeps causing confusion for enhancement leads because the scope is too broad to easily determine done/not-done (and that categorization doesn't necessarily make sense, this is an area, not a feature).

ok, let's proceed to close this.
individual tracking issues can be created for future items.