enhancements
enhancements copied to clipboard
kubernetes
Redesign Event API
Feature Description
- One-line feature description (can be used as a release note): Add more structure to Event API and change deduplication logic so Events won't overload the cluster
- Primary contact (assignee): @gmarek
- Responsible SIGs: instrumentation
- KEP: new-event-api-ga-graduation
- Design proposal link (community repo): design goolge doc - design discussions in github are too painful for me
- Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @timothysc @wojtek-t
- Approver (likely from SIG/area to which feature belongs): @bgrant0607 @thockin @countspongebob
- Feature target (which target equals to which milestone):
- Beta: 1.8 [done]
- GA: 1.19 [done]
@gmarek the feature submission deadline has passed (Aug 1). Please, submit a feature exception (https://github.com/kubernetes/features/blob/master/EXCEPTIONS.md) to have this feature present in 1.8 release.
@gmarek as you probably saw in the other feature comments, I am trying to understand how some features didn't get into the features repo before the deadline. This is only for the purpose of improving our release process and notifications for next time, not for blaming or pointing fingers. We're also trying to understand if there was prior work done on the feature, or if it was created after the freeze date.
Yup, there's quite some work done on this, with (big) design doc shared with kubernetes-dev and in-depth discussion on SIG scale. For this we'll probably make it disabled by default, as there's not enough time to let it soak. Is it possible to have a 'quiet' release for things like that? @jdumars
@gmarek that's an interesting question. My personal opinion is to provide as much transparency as possible, so we maintain a bond of trust with our user community. Being as you get to write the release notes, you can add something short there about it. And, thanks for clarifying the feature itself.
Personal perspective on this, largely repeating comments I've made before. But, as this is a case in point...
- SIG PM involvement and feature submissions have been functionally optional, with SIG PM not empowered to actually keep things out of a release.
- There is continued confusion over what is a feature. I echo @jbeda in calling for these to be renamed "efforts". The implication would be 100% coverage, but see my first point.
We had a discussion in SIG Scalability about especially point #2 with no clear resolution. A few of lobbied @gmarek to do the feature submission not withstanding the points above and he agreed to to do.
@jdumars @countspongebob @gmarek the main point to discuss here - is about the formal dates and deadlines, and what will happen if one will avoid them. We have agreed that the feature freeze for 1.8 (https://github.com/kubernetes/features/blob/master/release-1.8/release-1.8.md) is August 1, so all the features have to be submitted to the features repo before this date.
If people, responsible for the release and the overall community feel that this deadline is not mandatory, it can be discussed and removed. From our (PM group) standpoint, the feature freeze is necessary from the high-level point of view (including planning of the roadmap, marketing activities, etc.). But if there are some reasons why we shouldn't have a feature freeze, again, let's discuss them.
PS. It has been a long-discussed question in the community, even before SIG-PM was established. Now it might be a good time to solve it.
@countspongebob
SIG PM involvement and feature submissions have been functionally optional, with SIG PM not empowered to actually keep things out of a release.
SIG PM is not empowered, but release team is. SIG PM is responsible for managing the features on the high level, so we would be able to provide release team with the clearest and transparent information about the feature.
@idvoretskyi - IIUC the exception process is a SIG-PM thing. I haven't heard complains from release team about developing features that are not enabled and don't impact current behavior (plus it's highly unlikely it will be finished in 1.8 timeframe). I'm happy to discuss it as soon as any doubts appear.
Please correct me if I'm wrong - the goal is to track features that will ship in a current release, not the development process that may span across multiple releases. If I'm not mistaken this means that "features" (for lack of the better word) that are disabled and not ready to be enabled don't need to be tracked, right?
Also note that there's not clear what constitutes a 'feature' and where's the border between new feature and 'improvement' that doesn't need a feature repo issue.
Slight OT, but related to shipping features - it was widely acknowledged that @kubernetes/sig-scalability-misc have power to block features which cause performance degradation bad enough to make Kubernetes clusters break our performance SLOs (this is of course decided together with the release team). This is decided close to the release dates, when scale tests on a given release are finished. I'm saying this to make clear that feature repo can't be treated as source of truth about features that will ship in a given release.
FYI, the proposal recently merged:
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/events-redesign.md
PR is also ready for review (not started because of 1.8): kubernetes/kubernetes#49112
@gmarek :wave: Please indicate in the 1.9 feature tracking board whether this feature needs documentation. If yes, please open a PR and add a link to the tracking spreadsheet. Thanks in advance!
The reference links are still ugly as hell (mainly caused by repeated runs due to bot development). But I switched the bot to run under the k8s-publishing-bot user now which cannot close issues anymore. @github please fix your reference mechanism 🙏
Has anyone shown this issue to GitHub?? The number of spurious closures is ridiculous. 😕 xref: https://github.com/kubernetes/test-infra/issues/5032 Edit: I see stts has above... 😕
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
@gmarek 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
This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.
If so, please ensure that this issue is up-to-date with ALL of the following information:
- One-line feature description (can be used as a release note):
- Primary contact (assignee):
- Responsible SIGs:
- Design proposal link (community repo):
- Link to e2e and/or unit tests:
- Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
- Approver (likely from SIG/area to which feature belongs):
- Feature target (which target equals to which milestone):
- Alpha release target (x.y)
- Beta release target (x.y)
- Stable release target (x.y)
Set the following:
- Description
- Assignee(s)
- Labels:
- stage/{alpha,beta,stable}
- sig/*
- kind/feature
Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.
Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.
In addition, please be aware of the following relevant deadlines:
- Docs deadline (open placeholder PRs): 8/21
- Test case freeze: 8/28
Please make sure all PRs for features have relevant release notes included as well.
Happy shipping!
P.S. This was sent via automation
Hi This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:
- Docs (open placeholder PRs): 11/8
- Code Slush: 11/9
- Code Freeze Begins: 11/15
- Docs Complete and Reviewed: 11/27
Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet
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
@gmarek Hello - I’m the enhancement’s lead for 1.14 and I’m checking in on this issue to see what work (if any) is being planned for the 1.14 release. Enhancements freeze is Jan 29th and I want to remind that all enhancements must have a KEP
Implementation tracking issue: https://github.com/kubernetes/kubernetes/issues/56514