<commit_before># Pod Preset

  * [Abstract](#abstract)
  * [Motivation](#motivation)
  * [Constraints and Assumptions](#constraints-and-assumptions)
  * [Use Cases](#use-cases)
    * [Summary](#summary)
    * [Prior Art](#prior-art)
    * [Objectives](#objectives)
  * [Proposed Changes](#proposed-changes)
    * [PodPreset API object](#podpreset-api-object)
      * [Validations](#validations)
    * [AdmissionControl Plug-in: PodPreset](#admissioncontrol-plug-in-podpreset)
      * [Behavior](#behavior)
      * [PodPreset Exclude Annotation](#podpreset-exclude-annotation)
  * [Examples](#examples)
    * [Simple Pod Spec Example](#simple-pod-spec-example)
    * [Pod Spec with `ConfigMap` Example](#pod-spec-with-`configmap`-example)
    * [ReplicaSet with Pod Spec Example](#replicaset-with-pod-spec-example)
    * [Multiple PodPreset Example](#multiple-podpreset-example)
    * [Conflict Example](#conflict-example)


## Abstract

Describes a policy resource that allows for the loose coupling of a Pod's
definition from additional runtime requirements for that Pod. For example,
mounting of Secrets, or setting additional environment variables,
may not be known at Pod deployment time, but may be required at Pod creation
time.

## Motivation

Consuming a service involves more than just connectivity. In addition to
coordinates to reach the service, credentials and non-secret configuration
parameters are typically needed to use the service.  The primitives for this
already exist, but a gap exists where loose coupling is desired: it should be
possible to inject pods with the information they need to use a service on a
service-by-service basis, without the pod authors having to incorporate the
information into every pod spec where it is needed.

## Constraints and Assumptions

1.  Future work might require new mechanisms to be made to work with existing
    controllers such as deployments and replicasets that create pods. Existing
    controllers that create pods should recreate their pods when a new Pod Injection
    Policy is added that would effect them.<commit_msg>Fix anchor in pod-preset.md<commit_after># Pod Preset

  * [Abstract](#abstract)
  * [Motivation](#motivation)
  * [Constraints and Assumptions](#constraints-and-assumptions)
  * [Use Cases](#use-cases)
    * [Summary](#summary)
    * [Prior Art](#prior-art)
    * [Objectives](#objectives)
  * [Proposed Changes](#proposed-changes)
    * [PodPreset API object](#podpreset-api-object)
      * [Validations](#validations)
    * [AdmissionControl Plug-in: PodPreset](#admissioncontrol-plug-in-podpreset)
      * [Behavior](#behavior)
      * [PodPreset Exclude Annotation](#podpreset-exclude-annotation)
  * [Examples](#examples)
    * [Simple Pod Spec Example](#simple-pod-spec-example)
    * [Pod Spec with `ConfigMap` Example](#pod-spec-with-configmap-example)
    * [ReplicaSet with Pod Spec Example](#replicaset-with-pod-spec-example)
    * [Multiple PodPreset Example](#multiple-podpreset-example)
    * [Conflict Example](#conflict-example)


## Abstract

Describes a policy resource that allows for the loose coupling of a Pod's
definition from additional runtime requirements for that Pod. For example,
mounting of Secrets, or setting additional environment variables,
may not be known at Pod deployment time, but may be required at Pod creation
time.

## Motivation

Consuming a service involves more than just connectivity. In addition to
coordinates to reach the service, credentials and non-secret configuration
parameters are typically needed to use the service.  The primitives for this
already exist, but a gap exists where loose coupling is desired: it should be
possible to inject pods with the information they need to use a service on a
service-by-service basis, without the pod authors having to incorporate the
information into every pod spec where it is needed.

## Constraints and Assumptions

1.  Future work might require new mechanisms to be made to work with existing
    controllers such as deployments and replicasets that create pods. Existing
    controllers that create pods should recreate their pods when a new Pod Injection
    Policy is added that would effect them.
{'fraction_non_alphanumeric': 0.08400954653937948, 'fraction_numerical': 0.00047732696897374703, 'mean_word_length': 4.558355437665782, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3225254', 'n_tokens_mistral': 1172, 'n_tokens_neox': 1087, 'n_words': 448}