kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
This commit is contained in:
Aaron Crickenberger 2020-01-14 15:19:22 -08:00
parent a669c0beda
commit 2eb7d04ae5
1 changed files with 3 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
contributors/devel/sig-architecture/conformance-tests.md
View File

@ -66,6 +66,7 @@ Examples of features which are not currently eligible for conformance tests:
- optional features, eg: policy enforcement - optional features, eg: policy enforcement
- cloud-provider-specific features, eg: GCE monitoring, S3 Bucketing, etc. - cloud-provider-specific features, eg: GCE monitoring, S3 Bucketing, etc.
- anything that requires a non-default admission plugin - 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 Conformance tests are intended to be stable and backwards compatible according to
the standard API deprecation policies. Therefore any test that relies on specific 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 about the contents of events, nor their delivery
- If a test depends on events it is recommended to change the test to - If a test depends on events it is recommended to change the test to
use an informer pattern and watch specific resource changes instead. 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 - 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 these may change over time (however it is reasonable to verify these fields
exist or are non-empty) exist or are non-empty)