Epic Goal*

Currently, when a single resource cannot be decrypted, listing objects of that given resource type fails and there is no way how such an object can be removed by using the API.

Make it possible to identify an object that cannot be decrypted when listing resources of this object type by returning this information in a structured way upon such an API request.

Make it possible to remove an undecryptable object via an API call by using some kind of an safety overriding mechanism.

 
Why is this important? (mandatory)

Every now and then it might happen that a key is lost for encryption at REST. When that happens and there exists at least one instance of a given resource type that's affected, any component dealing with that resource type suddenly gets degraded.

The only way to resolve the above situation is to get rid of the above object by either directly removing it from etcd, or by restoring to a working backup.

Oftentimes it might be the case that the failing object is not necessary and we can remove it without any fear of bad repercussions. If we make it possible to do this via the Kubernetes API, we are greatly improving dealing with such a problem.

 
Scenarios (mandatory) 

1. described in Why is this important?

 
Dependencies (internal and external) (mandatory)

none

Contributing Teams(and contacts) (mandatory) 

Our expectation is that teams would modify the list below to fit the epic. Some epics may not need all the default groups but what is included here should accurately reflect who will be involved in delivering the epic.

• Development - 
• Documentation -
• QE - 
• PX - 
• Others -

Acceptance Criteria (optional)

Provide some (testable) examples of how we will know if we have achieved the epic goal.  

Drawbacks or Risk (optional)

Reasons we should consider NOT doing this such as: limited audience for the feature, feature will be superseded by other work that is planned, resulting feature will introduce substantial administrative complexity or user confusion, etc.

Done - Checklist (mandatory)

The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

• CI Testing -  Basic e2e automationTests are merged and completing successfully
• Documentation - Content development is complete.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Engineering Stories Merged
• All associated work items with the Epic are closed
• Epic status should be "Release Pending"