+++ This bug was initially created as a clone of Bug #1484134 +++

Description of problem:
If the wrong secret is passed in a given buildconfig (secret is non existing in the project space), it will consume all of the resources set via quota and thus any other build, deployment, etc. will fail until the X build is deleted.

As a result this buildpod, is an invalid object, incrementing a counter that quota is tracking, which leads to quota exhaustion. 

This needs to be documented as a known issue / possible issue with object creation. 

Version-Release number of selected component (if applicable):
3.4 to 3.7(3.8)


--- Additional comment from Derek Carr on 2017-08-23 11:51:19 EDT ---

quota is incremented in admission prior to validation of the resource.  as a result, quota may be incremented even if the pod is not ultimately persisted.  this is a known limitation of the quota subsystem today in kubernetes that we will have to address in a future release.

we should probably doc this at minimum in the product documentation, and we would want an RFE in the future to address this.


--- Additional comment from Derek Carr on 2017-08-24 17:29:46 EDT ---

To provide context for this issue, the API server at a high level works as follows:

1. Receive request
2. Deserialize the object
3. Default the object
4. Convert the object to internal form
5. Admission controllers Admit the object
6. Validate the object
7. ...
8. Persist the Object

Quota validation happens as part of the admission controller chain, and before object validation.  As a result, invalid objects sent to the API server can cause temporary charges to quota until replenishment occurs.

Ideally, we could have validation happen before quota, which requires bucketing of admission controllers into defaulters and non-defaulters.  This bucketing is not yet possible.