From 671d9f60bcb406c0d023af9821a668a80a875df6 Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Thu, 21 Jan 2021 14:24:36 +0800
Subject: [PATCH 01/12] copy template

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../1668-trace-popagating/README.md           | 594 ++++++++++++++++++
 .../1668-trace-popagating/kep.yaml            |  51 ++
 2 files changed, 645 insertions(+)
 create mode 100644 keps/sig-instrumentation/1668-trace-popagating/README.md
 create mode 100644 keps/sig-instrumentation/1668-trace-popagating/kep.yaml

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
new file mode 100644
index 00000000000..c94210c87fb
--- /dev/null
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -0,0 +1,594 @@
+<!--
+**Note:** When your KEP is complete, all of these comment blocks should be removed.
+
+To get started with this template:
+
+- [ ] **Pick a hosting SIG.**
+  Make sure that the problem space is something the SIG is interested in taking
+  up. KEPs should not be checked in without a sponsoring SIG.
+- [ ] **Create an issue in kubernetes/enhancements**
+  When filing an enhancement tracking issue, please make sure to complete all
+  fields in that template. One of the fields asks for a link to the KEP. You
+  can leave that blank until this KEP is filed, and then go back to the
+  enhancement and add the link.
+- [ ] **Make a copy of this template directory.**
+  Copy this template into the owning SIG's directory and name it
+  `NNNN-short-descriptive-title`, where `NNNN` is the issue number (with no
+  leading-zero padding) assigned to your enhancement above.
+- [ ] **Fill out as much of the kep.yaml file as you can.**
+  At minimum, you should fill in the "Title", "Authors", "Owning-sig",
+  "Status", and date-related fields.
+- [ ] **Fill out this file as best you can.**
+  At minimum, you should fill in the "Summary" and "Motivation" sections.
+  These should be easy if you've preflighted the idea of the KEP with the
+  appropriate SIG(s).
+- [ ] **Create a PR for this KEP.**
+  Assign it to people in the SIG who are sponsoring this process.
+- [ ] **Merge early and iterate.**
+  Avoid getting hung up on specific details and instead aim to get the goals of
+  the KEP clarified and merged quickly. The best way to do this is to just
+  start with the high-level sections and fill out details incrementally in
+  subsequent PRs.
+
+Just because a KEP is merged does not mean it is complete or approved. Any KEP
+marked as `provisional` is a working document and subject to change. You can
+denote sections that are under active debate as follows:
+
+```
+<<[UNRESOLVED optional short context or usernames ]>>
+Stuff that is being argued.
+<<[/UNRESOLVED]>>
+```
+
+When editing KEPS, aim for tightly-scoped, single-topic PRs to keep discussions
+focused. If you disagree with what is already in a document, open a new PR
+with suggested changes.
+
+One KEP corresponds to one "feature" or "enhancement" for its whole lifecycle.
+You do not need a new KEP to move from beta to GA, for example. If
+new details emerge that belong in the KEP, edit the KEP. Once a feature has become
+"implemented", major changes should get new KEPs.
+
+The canonical place for the latest set of instructions (and the likely source
+of this file) is [here](/keps/NNNN-kep-template/README.md).
+
+**Note:** Any PRs to move a KEP to `implementable`, or significant changes once
+it is marked `implementable`, must be approved by each of the KEP approvers.
+If none of those approvers are still appropriate, then changes to that list
+should be approved by the remaining approvers and/or the owning SIG (or
+SIG Architecture for cross-cutting KEPs).
+-->
+# KEP-NNNN: Your short, descriptive title
+
+<!--
+This is the title of your KEP. Keep it short, simple, and descriptive. A good
+title can help communicate what the KEP is and should be considered as part of
+any review.
+-->
+
+<!--
+A table of contents is helpful for quickly jumping to sections of a KEP and for
+highlighting any additional information provided beyond the standard KEP
+template.
+
+Ensure the TOC is wrapped with
+  <code>&lt;!-- toc --&rt;&lt;!-- /toc --&rt;</code>
+tags, and then generate with `hack/update-toc.sh`.
+-->
+
+<!-- toc -->
+- [Release Signoff Checklist](#release-signoff-checklist)
+- [Summary](#summary)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+  - [Non-Goals](#non-goals)
+- [Proposal](#proposal)
+  - [User Stories (Optional)](#user-stories-optional)
+    - [Story 1](#story-1)
+    - [Story 2](#story-2)
+  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
+  - [Risks and Mitigations](#risks-and-mitigations)
+- [Design Details](#design-details)
+  - [Test Plan](#test-plan)
+  - [Graduation Criteria](#graduation-criteria)
+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
+  - [Version Skew Strategy](#version-skew-strategy)
+- [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)
+  - [Feature Enablement and Rollback](#feature-enablement-and-rollback)
+  - [Rollout, Upgrade and Rollback Planning](#rollout-upgrade-and-rollback-planning)
+  - [Monitoring Requirements](#monitoring-requirements)
+  - [Dependencies](#dependencies)
+  - [Scalability](#scalability)
+  - [Troubleshooting](#troubleshooting)
+- [Implementation History](#implementation-history)
+- [Drawbacks](#drawbacks)
+- [Alternatives](#alternatives)
+- [Infrastructure Needed (Optional)](#infrastructure-needed-optional)
+<!-- /toc -->
+
+## Release Signoff Checklist
+
+<!--
+**ACTION REQUIRED:** In order to merge code into a release, there must be an
+issue in [kubernetes/enhancements] referencing this KEP and targeting a release
+milestone **before the [Enhancement Freeze](https://git.k8s.io/sig-release/releases)
+of the targeted release**.
+
+For enhancements that make changes to code or processes/procedures in core
+Kubernetes—i.e., [kubernetes/kubernetes], we require the following Release
+Signoff checklist to be completed.
+
+Check these off as they are completed for the Release Team to track. These
+checklist items _must_ be updated for the enhancement to be released.
+-->
+
+Items marked with (R) are required *prior to targeting to a milestone / release*.
+
+- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
+- [ ] (R) KEP approvers have approved the KEP status as `implementable`
+- [ ] (R) Design details are appropriately documented
+- [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
+- [ ] (R) Graduation criteria is in place
+- [ ] (R) Production readiness review completed
+- [ ] (R) Production readiness review approved
+- [ ] "Implementation History" section is up-to-date for milestone
+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
+- [ ] Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
+
+<!--
+**Note:** This checklist is iterative and should be reviewed and updated every time this enhancement is being considered for a milestone.
+-->
+
+[kubernetes.io]: https://kubernetes.io/
+[kubernetes/enhancements]: https://git.k8s.io/enhancements
+[kubernetes/kubernetes]: https://git.k8s.io/kubernetes
+[kubernetes/website]: https://git.k8s.io/website
+
+## Summary
+
+<!--
+This section is incredibly important for producing high-quality, user-focused
+documentation such as release notes or a development roadmap. It should be
+possible to collect this information before implementation begins, in order to
+avoid requiring implementors to split their attention between writing release
+notes and implementing the feature itself. KEP editors and SIG Docs
+should help to ensure that the tone and content of the `Summary` section is
+useful for a wide audience.
+
+A good summary is probably at least a paragraph in length.
+
+Both in this section and below, follow the guidelines of the [documentation
+style guide]. In particular, wrap lines to a reasonable length, to make it
+easier for reviewers to cite specific portions, and to minimize diff churn on
+updates.
+
+[documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
+-->
+
+## Motivation
+
+<!--
+This section is for explicitly listing the motivation, goals, and non-goals of
+this KEP.  Describe why the change is important and the benefits to users. The
+motivation section can optionally provide links to [experience reports] to
+demonstrate the interest in a KEP within the wider Kubernetes community.
+
+[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
+-->
+
+### Goals
+
+<!--
+List the specific goals of the KEP. What is it trying to achieve? How will we
+know that this has succeeded?
+-->
+
+### Non-Goals
+
+<!--
+What is out of scope for this KEP? Listing non-goals helps to focus discussion
+and make progress.
+-->
+
+## Proposal
+
+<!--
+This is where we get down to the specifics of what the proposal actually is.
+This should have enough detail that reviewers can understand exactly what
+you're proposing, but should not include things like API designs or
+implementation. What is the desired outcome and how do we measure success?.
+The "Design Details" section below is for the real
+nitty-gritty.
+-->
+
+### User Stories (Optional)
+
+<!--
+Detail the things that people will be able to do if this KEP is implemented.
+Include as much detail as possible so that people can understand the "how" of
+the system. The goal here is to make this feel real for users without getting
+bogged down.
+-->
+
+#### Story 1
+
+#### Story 2
+
+### Notes/Constraints/Caveats (Optional)
+
+<!--
+What are the caveats to the proposal?
+What are some important details that didn't come across above?
+Go in to as much detail as necessary here.
+This might be a good place to talk about core concepts and how they relate.
+-->
+
+### Risks and Mitigations
+
+<!--
+What are the risks of this proposal, and how do we mitigate? Think broadly.
+For example, consider both security and how this will impact the larger
+Kubernetes ecosystem.
+
+How will security be reviewed, and by whom?
+
+How will UX be reviewed, and by whom?
+
+Consider including folks who also work outside the SIG or subproject.
+-->
+
+## Design Details
+
+<!--
+This section should contain enough information that the specifics of your
+change are understandable. This may include API specs (though not always
+required) or even code snippets. If there's any ambiguity about HOW your
+proposal will be implemented, this is the place to discuss them.
+-->
+
+### Test Plan
+
+<!--
+**Note:** *Not required until targeted at a release.*
+
+Consider the following in developing a test plan for this enhancement:
+- Will there be e2e and integration tests, in addition to unit tests?
+- How will it be tested in isolation vs with other components?
+
+No need to outline all of the test cases, just the general strategy. Anything
+that would count as tricky in the implementation, and anything particularly
+challenging to test, should be called out.
+
+All code is expected to have adequate tests (eventually with coverage
+expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines]
+when drafting this test plan.
+
+[testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
+-->
+
+### Graduation Criteria
+
+<!--
+**Note:** *Not required until targeted at a release.*
+
+Define graduation milestones.
+
+These may be defined in terms of API maturity, or as something else. The KEP
+should keep this high-level with a focus on what signals will be looked at to
+determine graduation.
+
+Consider the following in developing the graduation criteria for this enhancement:
+- [Maturity levels (`alpha`, `beta`, `stable`)][maturity-levels]
+- [Deprecation policy][deprecation-policy]
+
+Clearly define what graduation means by either linking to the [API doc
+definition](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning)
+or by redefining what graduation means.
+
+In general we try to use the same stages (alpha, beta, GA), regardless of how the
+functionality is accessed.
+
+[maturity-levels]: https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions
+[deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
+
+Below are some examples to consider, in addition to the aforementioned [maturity levels][maturity-levels].
+
+#### Alpha -> Beta Graduation
+
+- Gather feedback from developers and surveys
+- Complete features A, B, C
+- Tests are in Testgrid and linked in KEP
+
+#### Beta -> GA Graduation
+
+- N examples of real-world usage
+- N installs
+- More rigorous forms of testing—e.g., downgrade tests and scalability tests
+- Allowing time for feedback
+
+**Note:** Generally we also wait at least two releases between beta and
+GA/stable, because there's no opportunity for user feedback, or even bug reports,
+in back-to-back releases.
+
+#### Removing a Deprecated Flag
+
+- Announce deprecation and support policy of the existing flag
+- Two versions passed since introducing the functionality that deprecates the flag (to address version skew)
+- Address feedback on usage/changed behavior, provided on GitHub issues
+- Deprecate the flag
+
+**For non-optional features moving to GA, the graduation criteria must include 
+[conformance tests].**
+
+[conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md
+-->
+
+### Upgrade / Downgrade Strategy
+
+<!--
+If applicable, how will the component be upgraded and downgraded? Make sure
+this is in the test plan.
+
+Consider the following in developing an upgrade/downgrade strategy for this
+enhancement:
+- What changes (in invocations, configurations, API use, etc.) is an existing
+  cluster required to make on upgrade, in order to maintain previous behavior?
+- What changes (in invocations, configurations, API use, etc.) is an existing
+  cluster required to make on upgrade, in order to make use of the enhancement?
+-->
+
+### Version Skew Strategy
+
+<!--
+If applicable, how will the component handle version skew with other
+components? What are the guarantees? Make sure this is in the test plan.
+
+Consider the following in developing a version skew strategy for this
+enhancement:
+- Does this enhancement involve coordinating behavior in the control plane and
+  in the kubelet? How does an n-2 kubelet without this feature available behave
+  when this feature is used?
+- Will any other components on the node change? For example, changes to CSI,
+  CRI or CNI may require updating that component before the kubelet.
+-->
+
+## Production Readiness Review Questionnaire
+
+<!--
+
+Production readiness reviews are intended to ensure that features merging into
+Kubernetes are observable, scalable and supportable; can be safely operated in
+production environments, and can be disabled or rolled back in the event they
+cause increased failures in production. See more in the PRR KEP at
+https://git.k8s.io/enhancements/keps/sig-architecture/1194-prod-readiness.
+
+The production readiness review questionnaire must be completed and approved
+for the KEP to move to `implementable` status and be included in the release.
+
+In some cases, the questions below should also have answers in `kep.yaml`. This
+is to enable automation to verify the presence of the review, and to reduce review
+burden and latency.
+
+The KEP must have a approver from the
+[`prod-readiness-approvers`](http://git.k8s.io/enhancements/OWNERS_ALIASES)
+team. Please reach out on the
+[#prod-readiness](https://kubernetes.slack.com/archives/CPNHUMN74) channel if
+you need any help or guidance.
+
+-->
+
+### Feature Enablement and Rollback
+
+_This section must be completed when targeting alpha to a release._
+
+* **How can this feature be enabled / disabled in a live cluster?**
+  - [ ] Feature gate (also fill in values in `kep.yaml`)
+    - Feature gate name:
+    - Components depending on the feature gate:
+  - [ ] Other
+    - Describe the mechanism:
+    - Will enabling / disabling the feature require downtime of the control
+      plane?
+    - Will enabling / disabling the feature require downtime or reprovisioning
+      of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled).
+
+* **Does enabling the feature change any default behavior?**
+  Any change of default behavior may be surprising to users or break existing
+  automations, so be extremely careful here.
+
+* **Can the feature be disabled once it has been enabled (i.e. can we roll back
+  the enablement)?**
+  Also set `disable-supported` to `true` or `false` in `kep.yaml`.
+  Describe the consequences on existing workloads (e.g., if this is a runtime
+  feature, can it break the existing applications?).
+
+* **What happens if we reenable the feature if it was previously rolled back?**
+
+* **Are there any tests for feature enablement/disablement?**
+  The e2e framework does not currently support enabling or disabling feature
+  gates. However, unit tests in each component dealing with managing data, created
+  with and without the feature, are necessary. At the very least, think about
+  conversion tests if API types are being modified.
+
+### Rollout, Upgrade and Rollback Planning
+
+_This section must be completed when targeting beta graduation to a release._
+
+* **How can a rollout fail? Can it impact already running workloads?**
+  Try to be as paranoid as possible - e.g., what if some components will restart
+   mid-rollout?
+
+* **What specific metrics should inform a rollback?**
+
+* **Were upgrade and rollback tested? Was the upgrade->downgrade->upgrade path tested?**
+  Describe manual testing that was done and the outcomes.
+  Longer term, we may want to require automated upgrade/rollback tests, but we
+  are missing a bunch of machinery and tooling and can't do that now.
+
+* **Is the rollout accompanied by any deprecations and/or removals of features, APIs, 
+fields of API types, flags, etc.?**
+  Even if applying deprecation policies, they may still surprise some users.
+
+### Monitoring Requirements
+
+_This section must be completed when targeting beta graduation to a release._
+
+* **How can an operator determine if the feature is in use by workloads?**
+  Ideally, this should be a metric. Operations against the Kubernetes API (e.g.,
+  checking if there are objects with field X set) may be a last resort. Avoid
+  logs or events for this purpose.
+
+* **What are the SLIs (Service Level Indicators) an operator can use to determine 
+the health of the service?**
+  - [ ] Metrics
+    - Metric name:
+    - [Optional] Aggregation method:
+    - Components exposing the metric:
+  - [ ] Other (treat as last resort)
+    - Details:
+
+* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**
+  At a high level, this usually will be in the form of "high percentile of SLI
+  per day <= X". It's impossible to provide comprehensive guidance, but at the very
+  high level (needs more precise definitions) those may be things like:
+  - per-day percentage of API calls finishing with 5XX errors <= 1%
+  - 99% percentile over day of absolute value from (job creation time minus expected
+    job creation time) for cron job <= 10%
+  - 99,9% of /health requests per day finish with 200 code
+
+* **Are there any missing metrics that would be useful to have to improve observability 
+of this feature?**
+  Describe the metrics themselves and the reasons why they weren't added (e.g., cost,
+  implementation difficulties, etc.).
+
+### Dependencies
+
+_This section must be completed when targeting beta graduation to a release._
+
+* **Does this feature depend on any specific services running in the cluster?**
+  Think about both cluster-level services (e.g. metrics-server) as well
+  as node-level agents (e.g. specific version of CRI). Focus on external or
+  optional services that are needed. For example, if this feature depends on
+  a cloud provider API, or upon an external software-defined storage or network
+  control plane.
+
+  For each of these, fill in the following—thinking about running existing user workloads
+  and creating new ones, as well as about cluster-level services (e.g. DNS):
+  - [Dependency name]
+    - Usage description:
+      - Impact of its outage on the feature:
+      - Impact of its degraded performance or high-error rates on the feature:
+
+
+### Scalability
+
+_For alpha, this section is encouraged: reviewers should consider these questions
+and attempt to answer them._
+
+_For beta, this section is required: reviewers must answer these questions._
+
+_For GA, this section is required: approvers should be able to confirm the
+previous answers based on experience in the field._
+
+* **Will enabling / using this feature result in any new API calls?**
+  Describe them, providing:
+  - API call type (e.g. PATCH pods)
+  - estimated throughput
+  - originating component(s) (e.g. Kubelet, Feature-X-controller)
+  focusing mostly on:
+  - components listing and/or watching resources they didn't before
+  - API calls that may be triggered by changes of some Kubernetes resources
+    (e.g. update of object X triggers new updates of object Y)
+  - periodic API calls to reconcile state (e.g. periodic fetching state,
+    heartbeats, leader election, etc.)
+
+* **Will enabling / using this feature result in introducing new API types?**
+  Describe them, providing:
+  - API type
+  - Supported number of objects per cluster
+  - Supported number of objects per namespace (for namespace-scoped objects)
+
+* **Will enabling / using this feature result in any new calls to the cloud 
+provider?**
+
+* **Will enabling / using this feature result in increasing size or count of 
+the existing API objects?**
+  Describe them, providing:
+  - API type(s):
+  - Estimated increase in size: (e.g., new annotation of size 32B)
+  - Estimated amount of new objects: (e.g., new Object X for every existing Pod)
+
+* **Will enabling / using this feature result in increasing time taken by any 
+operations covered by [existing SLIs/SLOs]?**
+  Think about adding additional work or introducing new steps in between
+  (e.g. need to do X to start a container), etc. Please describe the details.
+
+* **Will enabling / using this feature result in non-negligible increase of 
+resource usage (CPU, RAM, disk, IO, ...) in any components?**
+  Things to keep in mind include: additional in-memory state, additional
+  non-trivial computations, excessive access to disks (including increased log
+  volume), significant amount of data sent and/or received over network, etc.
+  This through this both in small and large cases, again with respect to the
+  [supported limits].
+
+### Troubleshooting
+
+The Troubleshooting section currently serves the `Playbook` role. We may consider
+splitting it into a dedicated `Playbook` document (potentially with some monitoring
+details). For now, we leave it here.
+
+_This section must be completed when targeting beta graduation to a release._
+
+* **How does this feature react if the API server and/or etcd is unavailable?**
+
+* **What are other known failure modes?**
+  For each of them, fill in the following information by copying the below template:
+  - [Failure mode brief description]
+    - Detection: How can it be detected via metrics? Stated another way:
+      how can an operator troubleshoot without logging into a master or worker node?
+    - Mitigations: What can be done to stop the bleeding, especially for already
+      running user workloads?
+    - Diagnostics: What are the useful log messages and their required logging
+      levels that could help debug the issue?
+      Not required until feature graduated to beta.
+    - Testing: Are there any tests for failure mode? If not, describe why.
+
+* **What steps should be taken if SLOs are not being met to determine the problem?**
+
+[supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
+[existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos
+
+## Implementation History
+
+<!--
+Major milestones in the lifecycle of a KEP should be tracked in this section.
+Major milestones might include:
+- the `Summary` and `Motivation` sections being merged, signaling SIG acceptance
+- the `Proposal` section being merged, signaling agreement on a proposed design
+- the date implementation started
+- the first Kubernetes release where an initial version of the KEP was available
+- the version of Kubernetes where the KEP graduated to general availability
+- when the KEP was retired or superseded
+-->
+
+## Drawbacks
+
+<!--
+Why should this KEP _not_ be implemented?
+-->
+
+## Alternatives
+
+<!--
+What other approaches did you consider, and why did you rule them out? These do
+not need to be as detailed as the proposal, but should include enough
+information to express the idea and why it was not acceptable.
+-->
+
+## Infrastructure Needed (Optional)
+
+<!--
+Use this section if you need things from the project/SIG. Examples include a
+new subproject, repos requested, or GitHub details. Listing these here allows a
+SIG to get the process for these resources started right away.
+-->
diff --git a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
new file mode 100644
index 00000000000..81b23e5d84f
--- /dev/null
+++ b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
@@ -0,0 +1,51 @@
+title: KEP Template
+kep-number: NNNN
+authors:
+  - "@jane.doe"
+owning-sig: sig-xyz
+participating-sigs:
+  - sig-aaa
+  - sig-bbb
+status: provisional|implementable|implemented|deferred|rejected|withdrawn|replaced
+creation-date: yyyy-mm-dd
+reviewers:
+  - TBD
+  - "@alice.doe"
+approvers:
+  - TBD
+  - "@oscar.doe"
+prr-approvers:
+  - TBD
+  - "@bob.doe"
+see-also:
+  - "/keps/sig-aaa/1234-we-heard-you-like-keps"
+  - "/keps/sig-bbb/2345-everyone-gets-a-kep"
+replaces:
+  - "/keps/sig-ccc/3456-replaced-kep"
+
+# The target maturity stage in the current dev cycle for this KEP.
+stage: alpha|beta|stable
+
+# The most recent milestone for which work toward delivery of this KEP has been
+# done. This can be the current (upcoming) milestone, if it is being actively
+# worked on.
+latest-milestone: "v1.19"
+
+# The milestone at which this feature was, or is targeted to be, at each stage.
+milestone:
+  alpha: "v1.19"
+  beta: "v1.20"
+  stable: "v1.22"
+
+# The following PRR answers are required at alpha release
+# List the feature gate name and the components for which it must be enabled
+feature-gates:
+  - name: MyFeature
+    components:
+      - kube-apiserver
+      - kube-controller-manager
+disable-supported: true
+
+# The following PRR answers are required at beta release
+metrics:
+  - my_feature_metric

From 076f6773fb8c2380625e162a93e364fb82923a25 Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Thu, 21 Jan 2021 14:34:59 +0800
Subject: [PATCH 02/12] Draft a new KEP trace-popagating

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../1668-trace-popagating/README.md           | 348 +++++++-----------
 .../1668-trace-popagating/kep.yaml            |  48 ++-
 2 files changed, 158 insertions(+), 238 deletions(-)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
index c94210c87fb..de30e285801 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -1,96 +1,31 @@
-<!--
-**Note:** When your KEP is complete, all of these comment blocks should be removed.
-
-To get started with this template:
-
-- [ ] **Pick a hosting SIG.**
-  Make sure that the problem space is something the SIG is interested in taking
-  up. KEPs should not be checked in without a sponsoring SIG.
-- [ ] **Create an issue in kubernetes/enhancements**
-  When filing an enhancement tracking issue, please make sure to complete all
-  fields in that template. One of the fields asks for a link to the KEP. You
-  can leave that blank until this KEP is filed, and then go back to the
-  enhancement and add the link.
-- [ ] **Make a copy of this template directory.**
-  Copy this template into the owning SIG's directory and name it
-  `NNNN-short-descriptive-title`, where `NNNN` is the issue number (with no
-  leading-zero padding) assigned to your enhancement above.
-- [ ] **Fill out as much of the kep.yaml file as you can.**
-  At minimum, you should fill in the "Title", "Authors", "Owning-sig",
-  "Status", and date-related fields.
-- [ ] **Fill out this file as best you can.**
-  At minimum, you should fill in the "Summary" and "Motivation" sections.
-  These should be easy if you've preflighted the idea of the KEP with the
-  appropriate SIG(s).
-- [ ] **Create a PR for this KEP.**
-  Assign it to people in the SIG who are sponsoring this process.
-- [ ] **Merge early and iterate.**
-  Avoid getting hung up on specific details and instead aim to get the goals of
-  the KEP clarified and merged quickly. The best way to do this is to just
-  start with the high-level sections and fill out details incrementally in
-  subsequent PRs.
-
-Just because a KEP is merged does not mean it is complete or approved. Any KEP
-marked as `provisional` is a working document and subject to change. You can
-denote sections that are under active debate as follows:
-
-```
-<<[UNRESOLVED optional short context or usernames ]>>
-Stuff that is being argued.
-<<[/UNRESOLVED]>>
-```
-
-When editing KEPS, aim for tightly-scoped, single-topic PRs to keep discussions
-focused. If you disagree with what is already in a document, open a new PR
-with suggested changes.
-
-One KEP corresponds to one "feature" or "enhancement" for its whole lifecycle.
-You do not need a new KEP to move from beta to GA, for example. If
-new details emerge that belong in the KEP, edit the KEP. Once a feature has become
-"implemented", major changes should get new KEPs.
-
-The canonical place for the latest set of instructions (and the likely source
-of this file) is [here](/keps/NNNN-kep-template/README.md).
-
-**Note:** Any PRs to move a KEP to `implementable`, or significant changes once
-it is marked `implementable`, must be approved by each of the KEP approvers.
-If none of those approvers are still appropriate, then changes to that list
-should be approved by the remaining approvers and/or the owning SIG (or
-SIG Architecture for cross-cutting KEPs).
--->
-# KEP-NNNN: Your short, descriptive title
-
-<!--
-This is the title of your KEP. Keep it short, simple, and descriptive. A good
-title can help communicate what the KEP is and should be considered as part of
-any review.
--->
-
-<!--
-A table of contents is helpful for quickly jumping to sections of a KEP and for
-highlighting any additional information provided beyond the standard KEP
-template.
-
-Ensure the TOC is wrapped with
-  <code>&lt;!-- toc --&rt;&lt;!-- /toc --&rt;</code>
-tags, and then generate with `hack/update-toc.sh`.
--->
+# KEP-1668: Trace information popagation
 
 <!-- toc -->
 - [Release Signoff Checklist](#release-signoff-checklist)
 - [Summary](#summary)
 - [Motivation](#motivation)
+  - [Definitions](#definitions)
   - [Goals](#goals)
   - [Non-Goals](#non-goals)
 - [Proposal](#proposal)
-  - [User Stories (Optional)](#user-stories-optional)
-    - [Story 1](#story-1)
-    - [Story 2](#story-2)
-  - [Notes/Constraints/Caveats (Optional)](#notesconstraintscaveats-optional)
+  - [Architecture](#architecture)
+  - [Trace context propagation](#trace-context-propagation)
+  - [Mutating admission webhook](#mutating-admission-webhook)
   - [Risks and Mitigations](#risks-and-mitigations)
 - [Design Details](#design-details)
+  - [In-tree changes](#in-tree-changes)
+    - [Trace Utility Package](#trace-utility-package)
+    - [Add Go context to parameter list](#add-go-context-to-parameter-list)
+  - [Out-of-tree changes](#out-of-tree-changes)
+    - [Mutating webhook](#mutating-webhook)
+  - [Behaviors with and without Mutating webhook](#behaviors-with-and-without-mutating-webhook)
+    - [with Mutating webhook](#with-mutating-webhook)
+    - [without Mutating webhook](#without-mutating-webhook)
   - [Test Plan](#test-plan)
   - [Graduation Criteria](#graduation-criteria)
+    - [Alpha](#alpha)
+    - [Beta](#beta)
+    - [GA](#ga)
   - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
   - [Version Skew Strategy](#version-skew-strategy)
 - [Production Readiness Review Questionnaire](#production-readiness-review-questionnaire)
@@ -146,82 +81,47 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 
 ## Summary
 
-<!--
-This section is incredibly important for producing high-quality, user-focused
-documentation such as release notes or a development roadmap. It should be
-possible to collect this information before implementation begins, in order to
-avoid requiring implementors to split their attention between writing release
-notes and implementing the feature itself. KEP editors and SIG Docs
-should help to ensure that the tone and content of the `Summary` section is
-useful for a wide audience.
-
-A good summary is probably at least a paragraph in length.
-
-Both in this section and below, follow the guidelines of the [documentation
-style guide]. In particular, wrap lines to a reasonable length, to make it
-easier for reviewers to cite specific portions, and to minimize diff churn on
-updates.
-
-[documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
--->
+This KEP proposes to propagate trace context across components and across a series of related objects originating from an user request. It lays the foundation for enhancing relevant but scattered logs with the trace information as common identifiers.
 
 ## Motivation
 
-<!--
-This section is for explicitly listing the motivation, goals, and non-goals of
-this KEP.  Describe why the change is important and the benefits to users. The
-motivation section can optionally provide links to [experience reports] to
-demonstrate the interest in a KEP within the wider Kubernetes community.
+Current logging for a series of related messages lacks common identifiers that can be commonly found in other distributed systems. (such as [Global Request IDs](https://specs.openstack.org/openstack/oslo-specs/specs/pike/global-req-id.html)  in openstack) This makes debugging, auditing, reproducing problems, analyzing root cause via logs across components hard, administrators and developers have to match logs by basically using timestamps and object's name as hints which may takes a huge cost especially in a scenario with a large number of requests occur in a short period of time.
 
-[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
--->
+### Definitions
+
+**Span**: The smallest unit of a trace.  It has a start and end time, and is attached to a single trace.
+
+**Trace**: A collection of Spans which represents a single process.
+
+**Trace Context**: A reference to a Trace that is designed to be propagated across component boundaries.  Sometimes referred to as the "Span Context".  It is can be thought of as a pointer to a parent span that child spans can be attached to.
 
 ### Goals
 
-<!--
-List the specific goals of the KEP. What is it trying to achieve? How will we
-know that this has succeeded?
--->
+- Trace context received by the API Server as part of [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) can be propagated to kubernetes components
+- A set of objects with relationship(OwnerRef/Non-ownerRef) can be linked by this trace information
 
 ### Non-Goals
 
-<!--
-What is out of scope for this KEP? Listing non-goals helps to focus discussion
-and make progress.
--->
+- Generate new trace context(Span)
+- Replace/change existing logging, metrics, or the events API
+- Add additional telemetry to any components which is already done by [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647). 
+- Run any additional OpenTelemetry components (such as the OpenTelemetry collector, which the  [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) KEP uses)
 
 ## Proposal
 
-<!--
-This is where we get down to the specifics of what the proposal actually is.
-This should have enough detail that reviewers can understand exactly what
-you're proposing, but should not include things like API designs or
-implementation. What is the desired outcome and how do we measure success?.
-The "Design Details" section below is for the real
-nitty-gritty.
--->
+### Architecture
 
-### User Stories (Optional)
+### Trace context propagation
 
-<!--
-Detail the things that people will be able to do if this KEP is implemented.
-Include as much detail as possible so that people can understand the "how" of
-the system. The goal here is to make this feel real for users without getting
-bogged down.
--->
+To link work done across components as belonging to the same action(user request), we must pass trace context across process boundaries. In traditional distributed systems, this context can be passed down through RPC metadata or HTTP headers. Kubernetes, however, due to its watch-based nature, requires us to attach trace context directly to the target object.
 
-#### Story 1
+In this proposal, we choose to propagate this trace context as object annotations called `trace.kubernetes.io/context`
 
-#### Story 2
+###  Mutating admission webhook
 
-### Notes/Constraints/Caveats (Optional)
+For trace context to be correlated as part of the same action, we must extract the trace context from the incomming request and embed it in target objects. To accomplish this, we have introduced an [out-of-tree mutating admission webhook](https://github.com/Hellcatlk/mutating-trace-admission-controller/tree/trace-ot).
 
-<!--
-What are the caveats to the proposal?
-What are some important details that didn't come across above?
-Go in to as much detail as necessary here.
-This might be a good place to talk about core concepts and how they relate.
--->
+The proposed in-tree changes will utilize the span context annotation injected into objects with this webhook.
 
 ### Risks and Mitigations
 
@@ -239,89 +139,113 @@ Consider including folks who also work outside the SIG or subproject.
 
 ## Design Details
 
-<!--
-This section should contain enough information that the specifics of your
-change are understandable. This may include API specs (though not always
-required) or even code snippets. If there's any ambiguity about HOW your
-proposal will be implemented, this is the place to discuss them.
--->
+### In-tree changes
 
-### Test Plan
+#### Trace Utility Package
 
-<!--
-**Note:** *Not required until targeted at a release.*
+This package will be able to retrieved span from the span context embedded in the `trace.kubernetes.io/context` object annotation. This package will facilitate propagating traces through kubernetes objects. The exported functions include:
 
-Consider the following in developing a test plan for this enhancement:
-- Will there be e2e and integration tests, in addition to unit tests?
-- How will it be tested in isolation vs with other components?
+```go
+// WithObject returns a context attached with a Span retrieved from object annotation, it doesn't start a new span
+func WithObject(ctx context.Context, obj meta.Object) (context.Context, error)
+```
 
-No need to outline all of the test cases, just the general strategy. Anything
-that would count as tricky in the implementation, and anything particularly
-challenging to test, should be called out.
+When controllers create/update/delete an object A based on another B, we propagate context from B to A. Below is an example to show how deployment propagate trace context  to replicaset.
+
+```diff
+ func (dc *DeploymentController) getNewReplicaSet(d *apps.Deployment, rsList, oldRSs []*apps.ReplicaSet, createIfNotExisted bool) (*apps.ReplicaSet, error) {
++       ctx := httptrace.WithObject(context.Background(), d)
+        existingNewRS := deploymentutil.FindNewReplicaSet(d, rsList)
+@@ -220,7 +227,8 @@ func (dc *DeploymentController) getNewReplicaSet(d *apps.Deployment, rsList, old
+        // hash collisions. If there is any other error, we need to report it in the status of
+        // the Deployment.
+        alreadyExists := false
+-       createdRS, err := dc.client.AppsV1().ReplicaSets(d.Namespace).Create(context.TODO(), &newRS, metav1.CreateOptions{})
++       createdRS, err := dc.client.AppsV1().ReplicaSets(d.Namespace).Create(ctx, &newRS, metav1.CreateOptions{})
+```
 
-All code is expected to have adequate tests (eventually with coverage
-expectations). Please adhere to the [Kubernetes testing guidelines][testing-guidelines]
-when drafting this test plan.
+#### Add Go context to parameter list
+In OpenTelemetry's Go implementation,  span context is passed down through Go context. This will necessitate the threading of context across more of the Kubernetes codebase, which is a [desired outcome regardless](https://github.com/kubernetes/kubernetes/issues/815). In alpha stage,  we need to change some APIs by adding `ctx context.Context` to parameter list whose parameters doesn't contain context.Context yet. Below APIs will be impacted so far.
 
-[testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
--->
+| APIs                          | file name                                                    |
+| ----------------------------- | ------------------------------------------------------------ |
+| createPods()                  | pkg/controller/controller_utils.go                           |
+| CreatePodsWithControllerRef() | pkg/controller/controller_utils.go<br />pkg/controller/replication/conversion.go<br />pkg/controller/daemon/daemon_controller.go<br />pkg/controller/replication/conversion.go |
 
-### Graduation Criteria
 
-<!--
-**Note:** *Not required until targeted at a release.*
+### Out-of-tree changes
 
-Define graduation milestones.
+#### Mutating webhook
+We use mutating admission controller(aka webhook)  to change/update the object annotation. It takes advantages of:
 
-These may be defined in terms of API maturity, or as something else. The KEP
-should keep this high-level with a focus on what signals will be looked at to
-determine graduation.
+- Ease of use. Using client-go with a context.Context is easier than adding an annotation. The webhook takes care of writing the annotation.
+- Object to object context propagation. Without the mutating admission controller, we can only associate actions from a single object. With the mutating admission controller, the logging metadata would be added for objects modified by controllers of the initial object (e.g. metadata added to a deployment annotation would appear in pod logs).
 
-Consider the following in developing the graduation criteria for this enhancement:
-- [Maturity levels (`alpha`, `beta`, `stable`)][maturity-levels]
-- [Deprecation policy][deprecation-policy]
+This mutating admission webhook extracts  a `span context` from incoming request, and then stores it into object annotation`trace.kubernetes.io/context` with base64 encoded version of [this wire format](https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#trace-context). The webhook can be configured to inject context into only target object types.
 
-Clearly define what graduation means by either linking to the [API doc
-definition](https://kubernetes.io/docs/concepts/overview/kubernetes-api/#api-versioning)
-or by redefining what graduation means.
+below is a key/value pair example in object annotation :
 
-In general we try to use the same stages (alpha, beta, GA), regardless of how the
-functionality is accessed.
+| key               | value(encoded)                       | origin value(decoded)                                   | description                                                  |
+| ---------------------------- | ------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| trace.kubernetes.io/context | 0/3kO3imLJzu3N54RTuOEUDbc2C0poIMAA== | 00-ca057eae1a26b66314fe3e361eedc5ca-3696483da6bfdcea-00 |it consists of `<version>-<traceid>-<spanid>-<flag>`. <br />A corresponding http header field is like `traceparent: 00-ca057eae1a26b66314fe3e361eedc5ca-3696483da6bfdcea-00` which is a w3c specific [trace-context](https://w3c.github.io/trace-context/#traceparent-header ). <br />|
 
-[maturity-levels]: https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions
-[deprecation-policy]: https://kubernetes.io/docs/reference/using-api/deprecation-policy/
+### Behaviors with and without Mutating webhook
+Since the mutating webhook is optional for users, we will explain the different behaviors between with and without mutating webhook.
 
-Below are some examples to consider, in addition to the aforementioned [maturity levels][maturity-levels].
+#### with Mutating webhook
 
-#### Alpha -> Beta Graduation
+**kubectl request**:
 
-- Gather feedback from developers and surveys
-- Complete features A, B, C
-- Tests are in Testgrid and linked in KEP
+- APIServer uses otel to start a new Span
+- APIServer uses otel to propagate `span context` to the other end(webhook)
+- Webhook persists `span context` to object
 
-#### Beta -> GA Graduation
+**controllers request:**
 
-- N examples of real-world usage
-- N installs
-- More rigorous forms of testing—e.g., downgrade tests and scalability tests
-- Allowing time for feedback
+- Controller uses otel to start a related Span, which connected to the `span context` in object
+- Controller uses otel to propagate `span context`  to the other end(APIServer)
+- APIServer uses otel  to start a related Span, which connected to the `span context` from the  incoming request
+- APIServer uses otel to propagate `span context`  to the other end(webhook)
+- Webhook persists `span context` to object
 
-**Note:** Generally we also wait at least two releases between beta and
-GA/stable, because there's no opportunity for user feedback, or even bug reports,
-in back-to-back releases.
+#### without Mutating webhook
 
-#### Removing a Deprecated Flag
+**kubectl request:**
 
-- Announce deprecation and support policy of the existing flag
-- Two versions passed since introducing the functionality that deprecates the flag (to address version skew)
-- Address feedback on usage/changed behavior, provided on GitHub issues
-- Deprecate the flag
+- APIServer uses otel to start a new Span
+- APIServer uses otel to propagate `span context` to the other end
+- ~~Webhook persists `span context` to object~~
 
-**For non-optional features moving to GA, the graduation criteria must include 
-[conformance tests].**
+**controllers request:**
 
-[conformance tests]: https://git.k8s.io/community/contributors/devel/sig-architecture/conformance-tests.md
--->
+- Controller start uses otel to start a new Span
+- Controller uses otel to propagate `span context`  to the other end(APIServer)
+- APIServer uses otel  to start related Span, which connected to the `span context` from the  incoming request
+- APIServer uses otel to propagate `span context` to the other end
+- ~~Webhook persists `span context`  to object~~
+
+In short, the webhook decides whether to add `span context` to the object.
+
+### Test Plan
+
+All added code will be covered by unit tests.
+
+### Graduation Criteria
+
+#### Alpha
+
+- Feature covers 3 important workload objects: Deployment, Statefulset, Daemonset
+- Related unit tests described in this KEP are completed
+
+#### Beta
+
+- Feature covers other objects which not limited to ownerRef relationship
+- All necessary tests are completed
+
+#### GA
+
+- Feedback about this feature is collected and addressed
+- Enabled in Beta for at least two releases without complaints
 
 ### Upgrade / Downgrade Strategy
 
@@ -382,9 +306,9 @@ you need any help or guidance.
 _This section must be completed when targeting alpha to a release._
 
 * **How can this feature be enabled / disabled in a live cluster?**
-  - [ ] Feature gate (also fill in values in `kep.yaml`)
-    - Feature gate name:
-    - Components depending on the feature gate:
+  - [x] Feature gate (also fill in values in `kep.yaml`)
+    - Feature gate name: TracePopagating
+    - Components depending on the feature gate: kube-controller-manager
   - [ ] Other
     - Describe the mechanism:
     - Will enabling / disabling the feature require downtime of the control
@@ -393,30 +317,32 @@ _This section must be completed when targeting alpha to a release._
       of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled).
 
 * **Does enabling the feature change any default behavior?**
-  Any change of default behavior may be surprising to users or break existing
-  automations, so be extremely careful here.
+
+  In apiserver, new request handlers added by this feature will generate
+  or update the trace context , then the trace context will be added to the
+  object's annotation by the webhook provided by this feature.
+
+  In controller-manager, when sending request to apiserver, it will get the
+  trace context from the referenced object's annotation and inject the trace context into the
+  outgoing request header with the W3C format.
 
 * **Can the feature be disabled once it has been enabled (i.e. can we roll back
   the enablement)?**
-  Also set `disable-supported` to `true` or `false` in `kep.yaml`.
-  Describe the consequences on existing workloads (e.g., if this is a runtime
-  feature, can it break the existing applications?).
+Yes
 
 * **What happens if we reenable the feature if it was previously rolled back?**
+  Objects created during the rollback will have no trace context until they
+  are recreated.
 
 * **Are there any tests for feature enablement/disablement?**
-  The e2e framework does not currently support enabling or disabling feature
-  gates. However, unit tests in each component dealing with managing data, created
-  with and without the feature, are necessary. At the very least, think about
-  conversion tests if API types are being modified.
+  Unit test can ensure that the feature enablement/disablement is valid
 
 ### Rollout, Upgrade and Rollback Planning
 
 _This section must be completed when targeting beta graduation to a release._
 
 * **How can a rollout fail? Can it impact already running workloads?**
-  Try to be as paranoid as possible - e.g., what if some components will restart
-   mid-rollout?
+   It will not have impact  on running workloads.
 
 * **What specific metrics should inform a rollback?**
 
diff --git a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
index 81b23e5d84f..75b9495c211 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
+++ b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
@@ -1,51 +1,45 @@
-title: KEP Template
-kep-number: NNNN
+title: trace information popagation
+kep-number: 1668
 authors:
-  - "@jane.doe"
-owning-sig: sig-xyz
+ - "@hase1128"
+ - "@KobayashiD27"
+ - "@fenggw-fnst"
+ - "@zhijianli88"
+ - "@Hellcatlk"
+owning-sig: sig-instrumentation
 participating-sigs:
-  - sig-aaa
-  - sig-bbb
-status: provisional|implementable|implemented|deferred|rejected|withdrawn|replaced
-creation-date: yyyy-mm-dd
+status: provisional
+creation-date: 2020-09-01
 reviewers:
-  - TBD
-  - "@alice.doe"
+ - "@dashpole"
+ - "@serathius"
 approvers:
-  - TBD
-  - "@oscar.doe"
+ - "@dashpole"
 prr-approvers:
-  - TBD
-  - "@bob.doe"
 see-also:
-  - "/keps/sig-aaa/1234-we-heard-you-like-keps"
-  - "/keps/sig-bbb/2345-everyone-gets-a-kep"
 replaces:
-  - "/keps/sig-ccc/3456-replaced-kep"
 
 # The target maturity stage in the current dev cycle for this KEP.
-stage: alpha|beta|stable
+stage: alpha
 
 # The most recent milestone for which work toward delivery of this KEP has been
 # done. This can be the current (upcoming) milestone, if it is being actively
 # worked on.
-latest-milestone: "v1.19"
+latest-milestone: "v1.21"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
-  alpha: "v1.19"
-  beta: "v1.20"
-  stable: "v1.22"
+  alpha: "v1.21"
+  beta: "v1.22"
+  stable: "v1.25"
 
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled
 feature-gates:
-  - name: MyFeature
-    components:
-      - kube-apiserver
-      - kube-controller-manager
+   - name: TracePopagating
+     components:
+       - kube-controller-manager
 disable-supported: true
 
 # The following PRR answers are required at beta release
 metrics:
-  - my_feature_metric

From 2e7e52ac5fb2e87fec995e8454f11d17d285e0c3 Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Thu, 21 Jan 2021 14:52:42 +0800
Subject: [PATCH 03/12] complete KEP for alpha

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../1668-trace-popagating/README.md           | 53 ++++++-------------
 .../1668-trace-popagating/kep.yaml            |  1 +
 2 files changed, 17 insertions(+), 37 deletions(-)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
index de30e285801..f96b76d0039 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -1,4 +1,4 @@
-# KEP-1668: Trace information popagation
+# KEP-1668: Trace popagating
 
 <!-- toc -->
 - [Release Signoff Checklist](#release-signoff-checklist)
@@ -417,45 +417,26 @@ _For GA, this section is required: approvers should be able to confirm the
 previous answers based on experience in the field._
 
 * **Will enabling / using this feature result in any new API calls?**
-  Describe them, providing:
-  - API call type (e.g. PATCH pods)
-  - estimated throughput
-  - originating component(s) (e.g. Kubelet, Feature-X-controller)
-  focusing mostly on:
-  - components listing and/or watching resources they didn't before
-  - API calls that may be triggered by changes of some Kubernetes resources
-    (e.g. update of object X triggers new updates of object Y)
-  - periodic API calls to reconcile state (e.g. periodic fetching state,
-    heartbeats, leader election, etc.)
+  N/A
 
 * **Will enabling / using this feature result in introducing new API types?**
-  Describe them, providing:
-  - API type
-  - Supported number of objects per cluster
-  - Supported number of objects per namespace (for namespace-scoped objects)
+  N/A
 
 * **Will enabling / using this feature result in any new calls to the cloud 
 provider?**
+  N/A
 
 * **Will enabling / using this feature result in increasing size or count of 
 the existing API objects?**
-  Describe them, providing:
-  - API type(s):
-  - Estimated increase in size: (e.g., new annotation of size 32B)
-  - Estimated amount of new objects: (e.g., new Object X for every existing Pod)
+  N/A
 
 * **Will enabling / using this feature result in increasing time taken by any 
 operations covered by [existing SLIs/SLOs]?**
-  Think about adding additional work or introducing new steps in between
-  (e.g. need to do X to start a container), etc. Please describe the details.
+  N/A
 
 * **Will enabling / using this feature result in non-negligible increase of 
 resource usage (CPU, RAM, disk, IO, ...) in any components?**
-  Things to keep in mind include: additional in-memory state, additional
-  non-trivial computations, excessive access to disks (including increased log
-  volume), significant amount of data sent and/or received over network, etc.
-  This through this both in small and large cases, again with respect to the
-  [supported limits].
+  TBD
 
 ### Troubleshooting
 
@@ -466,26 +447,24 @@ details). For now, we leave it here.
 _This section must be completed when targeting beta graduation to a release._
 
 * **How does this feature react if the API server and/or etcd is unavailable?**
+  The feature will be unavailable.
 
 * **What are other known failure modes?**
-  For each of them, fill in the following information by copying the below template:
-  - [Failure mode brief description]
-    - Detection: How can it be detected via metrics? Stated another way:
-      how can an operator troubleshoot without logging into a master or worker node?
-    - Mitigations: What can be done to stop the bleeding, especially for already
-      running user workloads?
-    - Diagnostics: What are the useful log messages and their required logging
-      levels that could help debug the issue?
-      Not required until feature graduated to beta.
-    - Testing: Are there any tests for failure mode? If not, describe why.
+  TBD
 
 * **What steps should be taken if SLOs are not being met to determine the problem?**
+  N/A
 
 [supported limits]: https://git.k8s.io/community//sig-scalability/configs-and-limits/thresholds.md
 [existing SLIs/SLOs]: https://git.k8s.io/community/sig-scalability/slos/slos.md#kubernetes-slisslos
 
 ## Implementation History
-
+* 2020-09-01: KEP proposed
+* 2020-09-28: PRR questionnaire updated
+* [Mutating admission webhook which injects trace context for demo](https://github.com/Hellcatlk/mutating-trace-admission-controller/tree/trace-ot)
+* [Instrumentation of Kubernetes components for demo](https://github.com/Hellcatlk/kubernetes/pull/1)
+* [Instrumentation of Kubernetes components for demo based on KEP647](https://github.com/Hellcatlk/kubernetes/pull/3)
+* refactor [Log tracking](https://github.com/kubernetes/enhancements/pull/1961) KEP to Trace popagating
 <!--
 Major milestones in the lifecycle of a KEP should be tracked in this section.
 Major milestones might include:
diff --git a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
index 75b9495c211..0e799dcc662 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
+++ b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
@@ -10,6 +10,7 @@ owning-sig: sig-instrumentation
 participating-sigs:
 status: provisional
 creation-date: 2020-09-01
+last-updated: 2021-01-21
 reviewers:
  - "@dashpole"
  - "@serathius"

From 2799320e5cc0186e1e0ac359da90f9fb872f49e4 Mon Sep 17 00:00:00 2001
From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
Date: Thu, 21 Jan 2021 17:12:37 +0800
Subject: [PATCH 04/12] Update Goals

Signed-off-by: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
---
 keps/sig-instrumentation/1668-trace-popagating/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
index f96b76d0039..ec3240a4dec 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -98,7 +98,7 @@ Current logging for a series of related messages lacks common identifiers that c
 ### Goals
 
 - Trace context received by the API Server as part of [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) can be propagated to kubernetes components
-- A set of objects with relationship(OwnerRef/Non-ownerRef) can be linked by this trace information
+- A series of related objects originating from an user request can be associated by this trace information
 
 ### Non-Goals
 

From 07c7a0715ab7b23c2f389ec981ec0a3fe47db203 Mon Sep 17 00:00:00 2001
From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
Date: Fri, 22 Jan 2021 10:54:48 +0800
Subject: [PATCH 05/12] Update description

Signed-off-by: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
---
 keps/sig-instrumentation/1668-trace-popagating/README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
index ec3240a4dec..73572575349 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -81,7 +81,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 
 ## Summary
 
-This KEP proposes to propagate trace context across components and across a series of related objects originating from an user request. It lays the foundation for enhancing relevant but scattered logs with the trace information as common identifiers.
+This KEP proposes to propagate trace context across components and across a series of related objects originating from an user request. It lays the foundation for enhancing relevant but scattered logs with the trace ID as common an identifier.
 
 ## Motivation
 
@@ -98,7 +98,7 @@ Current logging for a series of related messages lacks common identifiers that c
 ### Goals
 
 - Trace context received by the API Server as part of [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) can be propagated to kubernetes components
-- A series of related objects originating from an user request can be associated by this trace information
+- A series of related objects originating from an user request can be associated by trace ID
 
 ### Non-Goals
 

From 262c2203128f6bf915044a6192cb028f85f1f008 Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Fri, 22 Jan 2021 11:14:34 +0800
Subject: [PATCH 06/12] inspired by KEP#650

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 keps/sig-instrumentation/1668-trace-popagating/README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-popagating/README.md
index 73572575349..0618371b43b 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-popagating/README.md
@@ -139,6 +139,8 @@ Consider including folks who also work outside the SIG or subproject.
 
 ## Design Details
 
+This design is inspired by the earlier KEP [Leveraging Distributed Tracing to Understand Kubernetes Object Lifecycles](https://github.com/kubernetes/enhancements/pull/650)
+
 ### In-tree changes
 
 #### Trace Utility Package

From 125d1d49e676e3a9f878930023816aae8b4adce6 Mon Sep 17 00:00:00 2001
From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
Date: Thu, 28 Jan 2021 15:59:38 +0800
Subject: [PATCH 07/12] Add SIG api-machinery to participating-sigs (#17)

Signed-off-by: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
---
 keps/sig-instrumentation/1668-trace-popagating/kep.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
index 0e799dcc662..acfa7096253 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
+++ b/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
@@ -8,6 +8,7 @@ authors:
  - "@Hellcatlk"
 owning-sig: sig-instrumentation
 participating-sigs:
+  - sig-api-machinery
 status: provisional
 creation-date: 2020-09-01
 last-updated: 2021-01-21

From 11c7c567432d8b2be1d3a44b3a74c88cf55c8aec Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Fri, 29 Jan 2021 09:22:02 +0800
Subject: [PATCH 08/12] Rename to Trace Context Propagation

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../README.md                                               | 6 +++---
 .../kep.yaml                                                | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename keps/sig-instrumentation/{1668-trace-popagating => 1668-trace-context-propagation}/README.md (99%)
 rename keps/sig-instrumentation/{1668-trace-popagating => 1668-trace-context-propagation}/kep.yaml (94%)

diff --git a/keps/sig-instrumentation/1668-trace-popagating/README.md b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
similarity index 99%
rename from keps/sig-instrumentation/1668-trace-popagating/README.md
rename to keps/sig-instrumentation/1668-trace-context-propagation/README.md
index 0618371b43b..044d9163deb 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/README.md
+++ b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
@@ -1,4 +1,4 @@
-# KEP-1668: Trace popagating
+# KEP-1668: Trace Context Propagation
 
 <!-- toc -->
 - [Release Signoff Checklist](#release-signoff-checklist)
@@ -309,7 +309,7 @@ _This section must be completed when targeting alpha to a release._
 
 * **How can this feature be enabled / disabled in a live cluster?**
   - [x] Feature gate (also fill in values in `kep.yaml`)
-    - Feature gate name: TracePopagating
+    - Feature gate name: PropagateContextTrace
     - Components depending on the feature gate: kube-controller-manager
   - [ ] Other
     - Describe the mechanism:
@@ -466,7 +466,7 @@ _This section must be completed when targeting beta graduation to a release._
 * [Mutating admission webhook which injects trace context for demo](https://github.com/Hellcatlk/mutating-trace-admission-controller/tree/trace-ot)
 * [Instrumentation of Kubernetes components for demo](https://github.com/Hellcatlk/kubernetes/pull/1)
 * [Instrumentation of Kubernetes components for demo based on KEP647](https://github.com/Hellcatlk/kubernetes/pull/3)
-* refactor [Log tracking](https://github.com/kubernetes/enhancements/pull/1961) KEP to Trace popagating
+* refactor [Log tracking](https://github.com/kubernetes/enhancements/pull/1961) KEP to Trace Context Propagation
 <!--
 Major milestones in the lifecycle of a KEP should be tracked in this section.
 Major milestones might include:
diff --git a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml b/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
similarity index 94%
rename from keps/sig-instrumentation/1668-trace-popagating/kep.yaml
rename to keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
index acfa7096253..bf328fe70a5 100644
--- a/keps/sig-instrumentation/1668-trace-popagating/kep.yaml
+++ b/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
@@ -1,4 +1,4 @@
-title: trace information popagation
+title: Trace Context Propagation
 kep-number: 1668
 authors:
  - "@hase1128"
@@ -38,7 +38,7 @@ milestone:
 # The following PRR answers are required at alpha release
 # List the feature gate name and the components for which it must be enabled
 feature-gates:
-   - name: TracePopagating
+   - name: PropagateContextTrace
      components:
        - kube-controller-manager
 disable-supported: true

From f34d1a5ab7f87bdb2f2fb75d35ae156c36e9e5fb Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Mon, 1 Feb 2021 16:50:10 +0800
Subject: [PATCH 09/12] Address comments

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../1668-trace-context-propagation/README.md  | 42 ++++++++++++-------
 1 file changed, 26 insertions(+), 16 deletions(-)

diff --git a/keps/sig-instrumentation/1668-trace-context-propagation/README.md b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
index 044d9163deb..67457b3e51c 100644
--- a/keps/sig-instrumentation/1668-trace-context-propagation/README.md
+++ b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
@@ -81,7 +81,7 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 
 ## Summary
 
-This KEP proposes to propagate trace context across components and across a series of related objects originating from an user request. It lays the foundation for enhancing relevant but scattered logs with the trace ID as common an identifier.
+This KEP proposes to propagate trace context across components and across a series of related objects originating from an user request. It lays the foundation for enhancing relevant but scattered logs with the trace ID as a common identifier.
 
 ## Motivation
 
@@ -113,15 +113,27 @@ Current logging for a series of related messages lacks common identifiers that c
 
 ### Trace context propagation
 
-To link work done across components as belonging to the same action(user request), we must pass trace context across process boundaries. In traditional distributed systems, this context can be passed down through RPC metadata or HTTP headers. Kubernetes, however, due to its watch-based nature, requires us to attach trace context directly to the target object.
+In the traditional RPC client-server tracing model, a trace context is attached to a single incoming request, and is propagated with all requests the server makes to other servers required to fulfill the initial single request.
+In order to link work done across components as belonging to the same action(user request). For example, if a user creates a ReplicaSet, the kube-controller-manager will create many Pod objects as a result, and will propagate the context used to create the ReplicaSet to Pod objects as well.
+The following should be true:
 
-In this proposal, we choose to propagate this trace context as object annotations called `trace.kubernetes.io/context`
+1. The apiserver propagate the http context from incoming requests to outgoing requests.
+2. Kubernetes client libraries([client-go](https://github.com/kubernetes/client-go)) allow propagating trace context with API requests.
+3. Attach trace context to objects.
+4. Propagate this context to objects modified as a result of the initial object modification.
+5. Propagate this context to Kubernetes client libraries (to propagate trace context to API Server).
+
+This ensures that all actions taken by kubernetes controllers as a result of the initial user action are linked by the same context.
+Fortunately, both above _1_ and _2_ are already in the scope of [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) KEP. In this proposal, we choose to propagate this [trace context](https://www.w3.org/TR/trace-context) as object annotations called `trace.kubernetes.io/context`.
 
 ###  Mutating admission webhook
 
-For trace context to be correlated as part of the same action, we must extract the trace context from the incomming request and embed it in target objects. To accomplish this, we have introduced an [out-of-tree mutating admission webhook](https://github.com/Hellcatlk/mutating-trace-admission-controller/tree/trace-ot).
+We proposal to propagate trace context through objects with the help of storing trace context to objects via mutating admission webhook. The mutating admission webhook is required for any object-based context propagation, even for a single object. Without it, the context annotation is never written.
+Additionally,  Webhook is ease of use and convenient, using client-go with a context.Context is easier than adding an annotation. The webhook takes care of writing the annotation.
+
+Only write requests to objects will update the annotation. [The Admission Controllers are not able to hook read requests](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-are-they). Therefore Get or list requests will not reach the webhook nor overwrite the annotation.
 
-The proposed in-tree changes will utilize the span context annotation injected into objects with this webhook.
+Once the trace context has been stored to object annotation(backing storage), it would be seen(propagated to) in other components. The proposed in-tree changes will utilize the trace context annotation injected into objects with this webhook.
 
 ### Risks and Mitigations
 
@@ -148,10 +160,11 @@ This design is inspired by the earlier KEP [Leveraging Distributed Tracing to Un
 This package will be able to retrieved span from the span context embedded in the `trace.kubernetes.io/context` object annotation. This package will facilitate propagating traces through kubernetes objects. The exported functions include:
 
 ```go
-// WithObject returns a context attached with a Span retrieved from object annotation, it doesn't start a new span
+// WithObject returns a context attached with a Span instance, this Span instance is not a full span, it just includes the Trace Context retrieved from object annotation.
+// It is a no-op if the annotation doesn't contain a trace context.
 func WithObject(ctx context.Context, obj meta.Object) (context.Context, error)
 ```
-
+Object to object propagation is accomplished through the changes in controllers. Using the `WithObject` function, we are extracting context from one object, and using it in the write for another object.
 When controllers create/update/delete an object A based on another B, we propagate context from B to A. Below is an example to show how deployment propagate trace context  to replicaset.
 
 ```diff
@@ -167,7 +180,7 @@ When controllers create/update/delete an object A based on another B, we propaga
 ```
 
 #### Add Go context to parameter list
-In OpenTelemetry's Go implementation,  span context is passed down through Go context. This will necessitate the threading of context across more of the Kubernetes codebase, which is a [desired outcome regardless](https://github.com/kubernetes/kubernetes/issues/815). In alpha stage,  we need to change some APIs by adding `ctx context.Context` to parameter list whose parameters doesn't contain context.Context yet. Below APIs will be impacted so far.
+In OpenTelemetry's Go implementation,  span context is passed down through Go context. This will necessitate the threading of context across more of the Kubernetes codebase, which is a [desired outcome regardless](https://github.com/kubernetes/kubernetes/issues/815). In alpha stage,  we need to change some APIs by adding `ctx context.Context` to parameter list whose parameters hasn't contained context.Context yet. Below APIs will be impacted so far.
 
 | APIs                          | file name                                                    |
 | ----------------------------- | ------------------------------------------------------------ |
@@ -178,14 +191,10 @@ In OpenTelemetry's Go implementation,  span context is passed down through Go co
 ### Out-of-tree changes
 
 #### Mutating webhook
-We use mutating admission controller(aka webhook)  to change/update the object annotation. It takes advantages of:
-
-- Ease of use. Using client-go with a context.Context is easier than adding an annotation. The webhook takes care of writing the annotation.
-- Object to object context propagation. Without the mutating admission controller, we can only associate actions from a single object. With the mutating admission controller, the logging metadata would be added for objects modified by controllers of the initial object (e.g. metadata added to a deployment annotation would appear in pod logs).
 
 This mutating admission webhook extracts  a `span context` from incoming request, and then stores it into object annotation`trace.kubernetes.io/context` with base64 encoded version of [this wire format](https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#trace-context). The webhook can be configured to inject context into only target object types.
 
-below is a key/value pair example in object annotation :
+below is a key/value pair example in object annotation:
 
 | key               | value(encoded)                       | origin value(decoded)                                   | description                                                  |
 | ---------------------------- | ------------------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
@@ -230,13 +239,14 @@ In short, the webhook decides whether to add `span context` to the object.
 
 ### Test Plan
 
-All added code will be covered by unit tests.
+- All added code will be covered by unit tests.
+- e2e tests and integration tests for the mutating admission controller.
 
 ### Graduation Criteria
 
 #### Alpha
 
-- Feature covers 3 important workload objects: Deployment, Statefulset, Daemonset
+- Feature covers 3 important workload objects: Pod, Replicaset, Deployment, Statefulset, Daemonset
 - Related unit tests described in this KEP are completed
 
 #### Beta
@@ -430,7 +440,7 @@ provider?**
 
 * **Will enabling / using this feature result in increasing size or count of 
 the existing API objects?**
-  N/A
+Yes. It adds an annotation to "traced" objects. The value is a trace context, which is ~32 bytes. Traced objects will initially include pods, replicasets, and deployments, statefulsets, daemonsets, but may expand to include others over time. Notably, this annotation should not be added to Events.
 
 * **Will enabling / using this feature result in increasing time taken by any 
 operations covered by [existing SLIs/SLOs]?**

From 7bb937c0dbdf5f7ca48dc2f024e2b524d532285e Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Wed, 3 Feb 2021 14:25:15 +0800
Subject: [PATCH 10/12] add prod-readiness

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 keps/prod-readiness/sig-instrumentation/1668.yaml | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 keps/prod-readiness/sig-instrumentation/1668.yaml

diff --git a/keps/prod-readiness/sig-instrumentation/1668.yaml b/keps/prod-readiness/sig-instrumentation/1668.yaml
new file mode 100644
index 00000000000..c53b353dee4
--- /dev/null
+++ b/keps/prod-readiness/sig-instrumentation/1668.yaml
@@ -0,0 +1,3 @@
+kep-number: 1668
+alpha:
+  approver: "@wojtek-t"

From 898fd43618e1444e83efd7cf56439a760e4f7b01 Mon Sep 17 00:00:00 2001
From: Li Zhijian <lizhijian@cn.fujitsu.com>
Date: Thu, 18 Feb 2021 12:43:58 +0800
Subject: [PATCH 11/12] update webhook (#19)

* add webhook configuration

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>

* cover e2e tests in alpha

Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
---
 .../1668-trace-context-propagation/README.md  | 59 ++++++++++++++++++-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/keps/sig-instrumentation/1668-trace-context-propagation/README.md b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
index 67457b3e51c..4d3db8f30da 100644
--- a/keps/sig-instrumentation/1668-trace-context-propagation/README.md
+++ b/keps/sig-instrumentation/1668-trace-context-propagation/README.md
@@ -192,6 +192,63 @@ In OpenTelemetry's Go implementation,  span context is passed down through Go co
 
 #### Mutating webhook
 
+This webhook will be configured to allow the requests writing the object resource only. For example, the end user create a deployment including 2 replisects, some requests reaching APIServer in order may include:
+Deployment example:
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: sleep
+  namespace: sleeping
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: sleep
+  template:
+    metadata:
+      labels:
+        app: sleep
+    spec:
+      containers:
+      - name: sleep
+        image: busybox
+        command: ["/bin/sleep","infinity"]
+        imagePullPolicy: IfNotPresent
+```
+Webhook configuration example(read [webhook configuration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#webhook-configuration) for more details):
+```yaml
+apiVersion: admissionregistration.k8s.io/v1beta1
+kind: MutatingWebhookConfiguration
+metadata:
+  name: trace-context-injector-webhook-cfg
+webhooks:
+  - name: trace-context-injector.k8s.io
+    clientConfig:
+      service:
+        name: trace-context-injector-webhook-svc
+        namespace: default
+        path: "/mutate"
+      caBundle: ${CA_BUNDLE}
+    rules:
+      - operations: ["CREATE","UPDATE"]
+        apiGroups: ["*"]
+        apiVersions: ["*"]
+        resources: ["deployments","deamonsets","replicasets","statefulsets","pods"]
+```
+Requests reaching APIServer:
+
+1. Create deployment: sleep
+2. Create replicaset: sleep-replica
+3. Create 1st pod: sleep-pod-1st
+4. Update 1st pod's subresource: sleep-pod-1st/status
+5. Create 2nd pod: sleep-pod-2nd
+6. Update 2nd pod's subresource: sleep-pod-2nd/status
+7. Update replicaset's subresource: sleep-replica/status
+8. Update deployment's subresource: sleep/status
+
+With above webhook configuration, requests 1, 2, 3, 5 above will reach the webhook and annotations of these object will be updated accordingly. The rest requests will be filtered out in APIServer.
+
 This mutating admission webhook extracts  a `span context` from incoming request, and then stores it into object annotation`trace.kubernetes.io/context` with base64 encoded version of [this wire format](https://github.com/census-instrumentation/opencensus-specs/blob/master/encodings/BinaryEncoding.md#trace-context). The webhook can be configured to inject context into only target object types.
 
 below is a key/value pair example in object annotation:
@@ -247,7 +304,7 @@ In short, the webhook decides whether to add `span context` to the object.
 #### Alpha
 
 - Feature covers 3 important workload objects: Pod, Replicaset, Deployment, Statefulset, Daemonset
-- Related unit tests described in this KEP are completed
+- e2e tests and related unit tests described in this KEP are completed
 
 #### Beta
 

From e6a36acad3878c5178a156012c7de6cbda04de08 Mon Sep 17 00:00:00 2001
From: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
Date: Thu, 18 Feb 2021 12:44:17 +0800
Subject: [PATCH 12/12] Reassign PRR approver (#20)

Signed-off-by: Guangwen Feng <fenggw-fnst@cn.fujitsu.com>
---
 keps/prod-readiness/sig-instrumentation/1668.yaml               | 2 +-
 .../sig-instrumentation/1668-trace-context-propagation/kep.yaml | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/keps/prod-readiness/sig-instrumentation/1668.yaml b/keps/prod-readiness/sig-instrumentation/1668.yaml
index c53b353dee4..91425035ea2 100644
--- a/keps/prod-readiness/sig-instrumentation/1668.yaml
+++ b/keps/prod-readiness/sig-instrumentation/1668.yaml
@@ -1,3 +1,3 @@
 kep-number: 1668
 alpha:
-  approver: "@wojtek-t"
+  approver: "@ehashman"
diff --git a/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml b/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
index bf328fe70a5..44f7de2ee93 100644
--- a/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
+++ b/keps/sig-instrumentation/1668-trace-context-propagation/kep.yaml
@@ -18,6 +18,7 @@ reviewers:
 approvers:
  - "@dashpole"
 prr-approvers:
+ - "@ehashman"
 see-also:
 replaces: