update metric stability kep status

Author: Han Kang

keps/sig-instrumentation/20190404-kubernetes-control-plane-metrics-stability.md

@@ -266,15 +266,15 @@ Like their stable metric counterparts, deprecated metrics will be automatically
 On a subsequent release (when the metric's deprecatedVersion is equal to current_kubernetes_version - 1)), a deprecated metric will become a __hidden metric__. _Unlike_ their deprecated counterparts, hidden metrics will __*no longer be automatically registered*__ to the metrics endpoint (hence hidden). However, they can be explicitly enabled through a command line flag on the binary (i.e. '--show-hidden-metrics-for-version=<previous minor release>'). This is to provide cluster admins an escape hatch to properly migrate off of a deprecated metric, if they were not able to react to the earlier deprecation warnings. Hidden metrics should be deleted after one release.
 
 ### Show Hidden Metrics
-As described above, admins can enable hidden metrics through a command-line flag on a specific binary. 
-This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release. 
+As described above, admins can enable hidden metrics through a command-line flag on a specific binary.
+This intends to be used as an escape hatch for admins if they missed the migration of the metrics deprecated in the last release.
 
 The flag `show-hidden-metrics-for-version` takes a version for which you want to show metrics deprecated in that release.
 The version is expressed as __x.y__, where __x__ is the major version, __y__ is the minor version.
 The patch version is not needed even though a metrics can be deprecated in a patch release, the reason for that is
 the metrics deprecation policy runs against the minor release.
 
-The flag can only take the previous minor version as it's value. 
+The flag can only take the previous minor version as it's value.
 All metrics hidden in previous will be emitted if admins set the previous version to `show-hidden-metrics-for-version`.
 The too old version is not allowed because this violates the metrics deprecated policy.
 
@@ -284,11 +284,11 @@ According to metrics deprecated policy, we can reach the following conclusion:
 - In release `1.n+1`, the metric is hidden by default and it can be emitted by command line `show-hidden-metrics-for-version=1.n`.
 - In release `1.n+2`, the metric should be removed from the codebase. No escape hatch anymore.
 
-So, if admins want to enable metric `A` in release `1.n+1`, they should set `1.n` to the command line flag. 
-That is `show-hidden-metrics=1.n`. 
+So, if admins want to enable metric `A` in release `1.n+1`, they should set `1.n` to the command line flag.
+That is `show-hidden-metrics=1.n`.
 
 ### Why Not Bool Flag
-Alternatively, another solution which was previously suggested(refer to the discussion on [PR](https://github.com/kubernetes/kubernetes/pull/84292)) 
+Alternatively, another solution which was previously suggested(refer to the discussion on [PR](https://github.com/kubernetes/kubernetes/pull/84292))
 was provide a bool flag-like `show-hidden-metrics`. That works like:
 - `show-hidden-metrics=true`: enable all hidden metrics deprecated in a previous minor version.
 - `show-hidden-metrics=false`: the default value, do nothing.
@@ -330,11 +330,11 @@ Alternatively, one lightweight solution which was previously suggested was docum
 
 ### Static Analysis for Validation
 
-Having a set of wrappers in place which allows us to define custom metadata on metrics is quite powerful, since it enables a number of _theorectically possible_ features, like static analysis for verifying metric guarantees during a precommit phase. How we would actually go about doing this is TBD. It is possible to use the metrics registry to output metric descriptions in a separate endpoint; using static analysis we could validate metrics descriptions with our stability rules.
+[_resolved_](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/20190605-metrics-validation-and-verification.md)
 
 ### Beta Stability Level
 
-Currently I am inclined to omit the beta stage from metric versioning if only to reduce initial complexity. It may however become more desirable to include this state in a later design/implementation phase.
+_discussed during [stability-to-beta](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/20191028-metrics-stability-to-beta.md), and decided it wasn't necessary_
 
 ### Prometheus Labels vs OpenCensus-type Tags