diff options
| author | Kubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com> | 2017-10-30 14:39:47 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-10-30 14:39:47 -0700 |
| commit | aababdc6ae1e91bea2668c081f567f10a447fa15 (patch) | |
| tree | 1c4208f91a81eb609dfefcc06e5ba39ccd867143 | |
| parent | 48ff9a34c8ecdc0705eeab3476f9fb1f4afb8f46 (diff) | |
| parent | 1f9d9e8d66e076408a3d4dd21706a0b241b6f56b (diff) | |
Merge pull request #1301 from cheftako/naming
Automatic merge from submit-queue.
Adding naming discussion details to the design document.
Adding the synopsis of a naming thread to the webhook's design document.
| -rw-r--r-- | contributors/design-proposals/api-machinery/admission-control-webhooks.md | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/contributors/design-proposals/api-machinery/admission-control-webhooks.md b/contributors/design-proposals/api-machinery/admission-control-webhooks.md index 551754fe..fda6e0ea 100644 --- a/contributors/design-proposals/api-machinery/admission-control-webhooks.md +++ b/contributors/design-proposals/api-machinery/admission-control-webhooks.md @@ -3,7 +3,7 @@ ## PUBLIC Authors: @erictune, @caesarxuchao, @enisoc -Thanks to: {@dbsmith, @smarterclayton, @deads2k, @cheftaco, @jpbetz, @mbohlool, @mml, @janetkuo} for comments, data, prior designs, etc. +Thanks to: {@dbsmith, @smarterclayton, @deads2k, @cheftako, @jpbetz, @mbohlool, @mml, @janetkuo} for comments, data, prior designs, etc. [TOC] @@ -39,6 +39,25 @@ This plan is compatible with the [original design doc]( https://github.com/kuber **Static Admission Controller**: Compiled-in Admission Controllers, (in plugin/pkg/admission). +# Naming + +Many names were considered before settling on mutating. None of the names +considered were completely satisfactory. The following are the names which were +considered and a brief explanation of the perspectives on each. + +* Mutating: Well defined meaning related to mutable and immutable. Some + negative connotations related to genetic mutation. Might be too specifically + as CS term. +* Defaulting: Clearly indicates a create use case. However implies a lack of + functionality for the update use case. +* Modifying: Similar issues to mutating but not as well defined. +* Revising: Less clear what it does. Does it imply it works only on updates? +* Transforming: Some concern that it might have more to do with changing the + type or shape of the related object. +* Adjusting: Same general perspective as modifying. +* Updating: Nice clear meaning. However it seems to easy to confuse update with + the update operation and intuit it does not apply to the create operation. + # Development Plan |