sig-api-machinery: Add scale targets to CRDs to GA KEP

keps/sig-api-machinery/20180415-crds-to-ga.md

@@ -102,10 +102,14 @@ See [Post-GA tasks](#post-ga-tasks) for decided out-of-scope features.
 ### Defaulting and pruning for custom resources is implemented
 
 Both defaulting and pruning and also read-only validation are blocked by the
-OpenAPI subset definition (next point). An update of the [old Pruning for
-CustomResources KEP](https:/kubernetes/enhancements/pull/709) and the implementation
-([pruning PR](https:/kubernetes/kubernetes/pull/64558), [defaulting
-PR](https:/kubernetes/kubernetes/pull/63604)), are follow-ups as soon as unblocked.
+OpenAPI subset definition (next point). 
+
+See the update to [Pruning for CustomResources KEP](https:/kubernetes/enhancements/pull/709) 
+and the [Defaulting for Custom Resources KEP](https:/kubernetes/enhancements/pull/1006).
+
+Implementation is via ([pruning PR](https:/kubernetes/kubernetes/pull/64558) and 
+[defaulting PR](https:/kubernetes/kubernetes/pull/63604)), which are follow-ups
+as soon as they are unblocked.
 
 ### CRD v1 schemas are restricted to a subset of the OpenAPI specification
 
@@ -149,6 +153,7 @@ TODO: complete this list
  * TODO
 * [Vanilla OpenAPI Subset Design](https://docs.google.com/document/d/1pcGlbmw-2Y0JJs9hsYnSBXamgG9TfWtHY6eh80zSTd8)
  * TODO
+* Ensure CRD themselves are v1<->v1beta1 round trippable
 * CRD versioning/conversion (https:/kubernetes/kubernetes/issues/64136):
  * Ensure what is persisted in etcd matches the storage version
  * Set up a CRD, persist some data, changed the version, and ensure the previously persisted data is readable
@@ -157,15 +162,37 @@ TODO: complete this list
 
 ### e2e tests for GA
 
-* Custom Resources should be readable and writable at all available versions (test for round trip-ability)
 * A Custom Resource watch should terminate if its CustomResourceDefinition is deleted or updated
 
 ### Scale Targets for GA
 
-* TODO quantify: Read/write latency of CRDs within X% of native Kubernetes types
-* TODO quantify: Latency degrades less than X% for up to 100k Custom Resources per CRD kind
-* TODO quantify: Webhook conversion QPS of a noop converter is within X% of QPS with no webhook
-* Coordinate with sig-scalability
+Given that (a) the performance and scalability of conversion webhooks are the
+responsibly of their author, and (b) custom resources can be arbitrarily large,
+Kubernetes cannot offer an SLOs for custom resources like we do for
+Kubernetes native types (see [API call latency
+SLIs/SLOs](https:/kubernetes/community/blob/master/sig-scalability/slos/api_call_latency.md#api-call-latency-slisslos-details).
+
+Instead, we will set a scale target for custom resources using the same approach as the other [kubernetes
+thresholds](https:/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md#kubernetes-thresholds):
+
+- namespace scope: 2000
+- cluster scope: 10000
+
+such that apply when these conditions are met:
+
+- custom resource size is <= 10kb
+- 99th percentile conversion webhook latency:
+ - includes serialization/deserialization cost 
+ - excludes per resource conversion operation cost (i.e. conversion is a noop)
+
+custom resources latency meet the same SLOs as for native types as described in [API call latency
+SLIs/SLOs](https:/kubernetes/community/blob/master/sig-scalability/slos/api_call_latency.md#api-call-latency-slisslos-details).
+
+We will update the threshold and SLO documentation to make this clear and
+encourage CRD authors are encouraged provide thresholds/SLOs for their custom
+resource kinds to their users by incorporating the per resource conversion cost
+of their conversion webhook and/or size of their custom resources into the
+base thresholds/SLOs we've defined here for custom resource scale targets.
 
 ## Graduation Criteria