From bf5bcdc68fa903b658ddb05ea88ec35b32baf419 Mon Sep 17 00:00:00 2001 From: Ananya Kumar Date: Thu, 30 Jul 2015 20:02:06 -0700 Subject: [PATCH 1/2] Update admission_control.md I tested out a Limit Ranger, and it seems like the admission happens *before* Validation. Please correct me if I'm wrong though, I didn't look at the code in detail. In any case, I think it makes sense for admission to happen before validation because code in admission can change containers. By the way I think it's pretty hard to find flows like this in the code, so it's useful if we add links to code in the design docs (for prospective developers) :) --- docs/design/admission_control.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/design/admission_control.md b/docs/design/admission_control.md index c75d55359cd..8cc6cf03c58 100644 --- a/docs/design/admission_control.md +++ b/docs/design/admission_control.md @@ -104,9 +104,9 @@ will ensure the following: 1. Incoming request 2. Authenticate user 3. Authorize user -4. If operation=create|update, then validate(object) -5. If operation=create|update|delete, then admission.Admit(requestAttributes) - a. invoke each admission.Interface object in sequence +4. If operation=create|update|delete, then admission.Admit(requestAttributes) + a. invoke each admission.Interface object in sequence +5. If operation=create|update, then validate(object) 6. Object is persisted If at any step, there is an error, the request is canceled. From 15884e14d291cd8540b4c77dd39af966b663a8c2 Mon Sep 17 00:00:00 2001 From: Ananya Kumar Date: Mon, 3 Aug 2015 23:00:48 -0700 Subject: [PATCH 2/2] Update admission_control.md --- docs/design/admission_control.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/design/admission_control.md b/docs/design/admission_control.md index 8cc6cf03c58..b84b2543e40 100644 --- a/docs/design/admission_control.md +++ b/docs/design/admission_control.md @@ -98,16 +98,17 @@ func init() { Invocation of admission control is handled by the **APIServer** and not individual **RESTStorage** implementations. -This design assumes that **Issue 297** is adopted, and as a consequence, the general framework of the APIServer request/response flow -will ensure the following: +This design assumes that **Issue 297** is adopted, and as a consequence, the general framework of the APIServer request/response flow will ensure the following: 1. Incoming request 2. Authenticate user 3. Authorize user -4. If operation=create|update|delete, then admission.Admit(requestAttributes) - a. invoke each admission.Interface object in sequence -5. If operation=create|update, then validate(object) -6. Object is persisted +4. If operation=create|update|delete|connect, then admission.Admit(requestAttributes) + - invoke each admission.Interface object in sequence +5. Case on the operation: + - If operation=create|update, then validate(object) and persist + - If operation=delete, delete the object + - If operation=connect, exec If at any step, there is an error, the request is canceled.