Add two clarifications to conformance requirements

Based on conformance meeting today

- we want to allow a test to exercise the event API to verify it can
  be exercised; this isn't depending on a specific component to
  generate a specific event

- we don't want to allow tests which are attempting to exercise the
  componentstatus API as there is a KEP out to deprecate it, and all
  involved don't want to add more code around componentstatus

1 files changed, 3 insertions, 0 deletions

diff --git a/contributors/devel/sig-architecture/conformance-tests.md b/contributors/devel/sig-architecture/conformance-tests.md
index 919e7cd9..9dfaddb1 100644
--- a/contributors/devel/sig-architecture/conformance-tests.md
+++ b/contributors/devel/sig-architecture/conformance-tests.md
@@ -66,6 +66,7 @@ Examples of features which are not currently eligible for conformance tests:
 - optional features, eg: policy enforcement
 - cloud-provider-specific features, eg: GCE monitoring, S3 Bucketing, etc.
 - anything that requires a non-default admission plugin
+- features that are pending deprecation, eg: componentstatus
 
 Conformance tests are intended to be stable and backwards compatible according to 
 the standard API deprecation policies. Therefore any test that relies on specific 
@@ -75,6 +76,8 @@ Examples of tests which are not eligible to conformance:
   about the contents of events, nor their delivery
     - If a test depends on events it is recommended to change the test to 
       use an informer pattern and watch specific resource changes instead.
+    - An exception to this is tests that generates synthetic events themselves 
+      to verify that the API is capable of being exercised
 - anything that checks optional Condition fields, such as Reason or Message, as
   these may change over time (however it is reasonable to verify these fields
   exist or are non-empty)