anchor.diff:            "from": {
               "kind": "ImageStreamTag",
               "name": "origin-ruby-sample:latest"
  -          },
  -          "lastTriggeredImage": ""
  +          }
           }
         }
       ],
  -    "replicas": 1,
  -    "selector": {
  -      "name": "frontend"
  -    },
  +    "strategy": { <5>
  +      "type": "Rolling"
  +    }
  +  }
  +}
  +----
  +
  +<1> The replication controller template named `frontend` describes a simple Ruby application.
  +<2> There will be 5 replicas of `frontend` by default.
  +<3> A link:#config-change-trigger[configuration change trigger] causes a new deployment to be created any time the replication controller template changes.
  +<4> An link:#image-change-trigger[image change trigger] trigger causes a new deployment to be
  +created each time a new version of the `origin-ruby-sample:latest` image repository is available.
  +<5> The link:#rolling-strategy[rolling strategy] is the default and may be omitted.
  +====
  +
  +== Triggers
  +
  +A deployment configuration can contain triggers, which drive the creation of
  +new deployments in response to events, both inside and outside OpenShift.
  +
  +WARNING: If no triggers are defined on a deployment configuration, deployments
  +must be triggered manually with:
  +
  +----
  +$ oc deploy deploymentConfigName --latest
  +----
  +
  +=== Configuration Change Trigger [[config-change-trigger]]
  +
  +The ConfigChange trigger results in a new deployment whenever changes are
  +detected to the replication controller template of the deployment configuration.
  +
  +IMPORTANT: If a ConfigChange trigger is defined on a deployment configuration,
  +the first deployment will be automatically created soon after the deployment
  +configuration itself is created.
  +
  +The following is an example of a ConfigChange trigger:
  +
  +====
  +
  +[source,json]
  +----
  +"triggers": [
  +  {
  +    "type": "ConfigChange"
  +  }
  +]
  +----
  +====
  +
  +=== Image Change Trigger [[image-change-trigger]]
  +
  +The ImageChange trigger results in a new deployment whenever the value of an
  +image stream tag changes.
  +
  +The following is an example of an ImageChange trigger:
  +
  +====
  +
  +[source,json]
  +----
  +"triggers": [
  +  {
  +    "type": "ImageChange",
  +    "imageChangeParams": {
  +      "automatic": true, <1>
  +      "from": {
  +        "kind": "ImageStreamTag",
  +        "name": "origin-ruby-sample:latest"
  +      },
  +      "containerNames": [
  +        "helloworld"
  +      ]
  +    }
  +  }
  +]
  +----
  +<1> If the `*automatic*` option is set to `false`, the trigger is disabled.
  +====
  +
  +With the above example, when the `latest` tag value of the `origin-ruby-sample`
  +image stream changes and the new tag value differs from the current image
  +specified in the deployment configuration's `helloworld` container, a new
  +deployment is created using the new tag value for the `helloworld` container.
  +
  +== Strategies
  +
  +A deployment configuration declares a strategy which is responsible for
  +executing the deployment process. Each application has different requirements
  +for availability (and other considerations) during deployments. OpenShift
  +provides out-of-the-box strategies to support a variety of deployment
  +scenarios.
  +
  +The link:#rolling-strategy[rolling strategy] is the default strategy used if
  +no strategy is specified on a deployment configuration.
  +
  +=== Rolling Strategy [[rolling-strategy]]
  +
  +The Rolling strategy performs a rolling update and supports
  +link:#lifecycle-hooks[lifecycle hooks] for injecting code into the deployment
  +process.
  +
  +The following is an example of the Rolling strategy:
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Rolling",
  +  "rollingParams": {
  +    "timeoutSeconds": 120, <1>
  +    "pre": {}, <2>
  +    "post": {}
  +  }
  +}
  +----
  +
  +<1> How long to wait for a scaling event before giving up. Optional; the default is 120.
  +<2> `*pre*` and `*post*` are both link:#lifecycle-hooks[lifecycle hooks].
  +
  +The Rolling strategy will:
  +
  +. Execute any "pre" lifecycle hook.
  +. Scale up the new deployment by one.
  +. Scale down the old deployment by one.
  +. Repeat this scaling until the new deployment has reached the desired replica
  +count and the old deployment has been scaled to zero.
  +. Execute any "post" lifecycle hook.
  +
  +IMPORTANT: During scale up, if the replica count of the deployment is greater
  +than one, the  first replica of the deployment will be validated for readiness
  +before fully scaling up the deployment. If the validation of the first replica
  +fails, the deployment will be considered a failure.
  +
  +IMPORTANT: When executing the "post" lifecycle hook, all failures will be
  +ignored regardless of the failure policy specified on the hook.
  +
  +=== Recreate Strategy [[recreate-strategy]]
  +
  +The Recreate strategy has basic rollout behavior and supports
  +link:#lifecycle-hooks[lifecycle hooks] for injecting code into the deployment
  +process.
  +
  +The following is an example of the Recreate strategy:
  +
  +====
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Recreate",
  +  "recreateParams": { <1>
  +    "pre": {}, <2>
  +    "post": {}
  +  }
  +}
  +----
  +
  +<1> `*recreateParams*` are optional.
  +<2> `*pre*` and `*post*` are both link:#lifecycle-hooks[lifecycle hooks].
  +====
  +
  +The Recreate strategy will:
  +
  +. Execute any "pre" lifecycle hook.
  +. Scale down the previous deployment to zero.
  +. Scale up the new deployment.
  +. Execute any "post" lifecycle hook.
  +
  +IMPORTANT: During scale up, if the replica count of the deployment is greater
  +than one, the  first replica of the deployment will be validated for readiness
  +before fully scaling up the deployment. If the validation of the first replica
  +fails, the deployment will be considered a failure.
  +
  +IMPORTANT: When executing the "post" lifecycle hook, all failures will be
  +ignored regardless of the failure policy specified on the hook.
  +
  +=== Custom strategy [[custom-strategy]]
  +
  +The Custom strategy allows you to provide your own deployment behavior.
  +
  +The following is an example of the Custom strategy:
  +
  +====
  +
  +[source,json]
  +----
  +"strategy": {
  +  "type": "Custom",
  +  "customParams": {
  +    "image": "organization/strategy",
  +    "command": ["command", "arg1"],
  +    "environment": [
  +      {
  +        "name": "ENV_1",
  +        "value": "VALUE_1"
  +      }
  +    ]
  +  }
  +}
  +----
  +====
  +
  +In the above example, the *organization/strategy* Docker image provides the
  +deployment behavior. The optional `*command*` array overrides any `CMD`
  +directive specified in the image's *_Dockerfile_*. The optional environment
  +variables provided are added to the execution environment of the strategy
  +process.
  +
  +Additionally, OpenShift provides the following environment variables to the
  +strategy process:
  +
  +[cols="4,8",options="header"]
  +|===
  +|Environment Variable |Description
  +
  +.^|`*OPENSHIFT_DEPLOYMENT_NAME*`
  +|The name of the new deployment (a replication controller).
  +
  +.^|`*OPENSHIFT_DEPLOYMENT_NAMESPACE*`
  +|The namespace of the new deployment.
  +|===
  +
  +The replica count of the new deployment will initially be zero. The
  +responsibility of the strategy is to make the new deployment active using the
  +logic that best serves the needs of the user.
  +
  +== Lifecycle Hooks [[lifecycle-hooks]]
  +
  +The link:#recreate-strategy[Recreate] and link:#rolling-strategy[Rolling]
  +strategies support lifecycle hooks, which allow behavior to be injected into
  +the deployment process at predefined points within the strategy:
  +
  +The following is an example of a "pre" lifecycle hook:
  +
  +====
  +
  +[source,json]
  +----
  +"pre": {
  +  "failurePolicy": "Abort",
  +  "execNewPod": {} <1>
  +}
  +----
  +<1> `*execNewPod*` is link:#pod-based-lifecycle-hook[a pod-based lifecycle hook].
  +====
  +
  +Every hook has a `*failurePolicy*`, which defines the action the strategy should
  +take when a hook failure is encountered:
  +
  +[cols="2,8"]
  +|===
  +
  +.^|`*Abort*`
  +|The deployment should be considered a failure if the hook fails.
  +
  +.^|`*Retry*`
  +|The hook execution should be retried until it succeeds.
  +
  +.^|`*Ignore*`
  +|Any hook failure should be ignored and the deployment should proceeed.
  +|===
  +
  +WARNING: Some hook points for a strategy might support only a subset of
  +failure policy values. For example, the link:#recreate-strategy[Recreate] and
  +link:#rolling-strategy[Rolling] strategies do not currently support the
  +`*Abort*` policy for a "post" deployment lifecycle hook. Consult the
  +documentation for a given strategy for details on any restrictions regarding
  +lifecycle hooks.
  +
  +Hooks have a type-specific field that describes how to execute the hook.
  +Currently link:#pod-based-lifecycle-hook[pod-based hooks] are the only
  +supported hook type, specified by the `*execNewPod*` field.
  +
  +=== Pod-based Lifecycle Hook [[pod-based-lifecycle-hook]]
  +
  +Pod-based lifecycle hooks execute hook code in a new pod derived from the
  +template in a deployment configuration.
  +
  +The following simplified example deployment configuration uses the
  +link:#rolling-strategy[Rolling strategy]. Triggers and some other minor details
  +are omitted for brevity:
  +
  +====
  +
  +[source,json]
  +----
  +{
  +  "kind": "DeploymentConfig",
  +  "apiVersion": "v1",
  +  "metadata": {
  +    "name": "frontend"
  +  },
  +  "spec": {
       "template": {
         "metadata": {
           "labels": {
  
positive.code: toc::[]
  
  == Overview
  A deployment in OpenShift is an update to a single replication controller's pod
  template based on triggered events. The `*deployment*` subsystem provides:
  
  - A link:#defining-a-deploymentConfig[deploymentconfig] that drives automated deployments by the system.
  - link:#triggers[Triggers] which drive new deployments in response to events.
  - User-customizable link:#strategies[strategies] for deployment rollout behavior, which are responsible for making a deployment live in the cluster.
  - link:#rollbacks[Rollbacks] to a previous deployment.
  - Replication link:#scaling[scaling].
  - An audit history of deployed pod template configurations.
  
  The deployment configuration has a version parameter value that increases in increments of one each time a new deployment is created from that configuration. In addition, the cause of the last deployment is added to the configuration.
  
  == Defining a deploymentConfig
  
  A `*deploymentConfig*` describes a single link:templates.html[template] and a
  set of link:#triggers[triggers] for when a new deployment should be created.
  A deployment is simply a specially annotated `*replicationController*`.
  
  A `*deploymentConfig*` is a REST object, which can be used in a `POST` to the
  API server to create a new instance. The following configuration results in a
  new deployment every time a Docker image tag changes:
  
  ====
  
  
negative.code:           }
          }
        }
      }
    }
  }
  ----
  <1> The `helloworld` name refers to `spec.template.spec.containers[0].name`.
  <2> This `*command*` overrides any `ENTRYPOINT` defined by the `openshift/origin-ruby-sample` image.
  <3> `*env*` is an optional set of environment variables for the hook container.
  ====
  
  In this example, the "pre" hook will be executed in a new pod using the
  *openshift/origin-ruby-sample* image from the *helloworld* container. The hook
  container command will be `/usr/bin/command arg1 arg2`, and the hook container
  will have the `CUSTOM_VAR1=custom_value1` environment variable. Because the
  hook failure policy is `Abort`, the deployment will fail if the hook fails.
  
  == Deployment Resources
  A deployment is completed by a pod that consumes *resources* (memory and cpu) on a node.
  By default, pods consume unbounded node resources.
  However, if a project specifies default container limits, then pods consume resources up to those limits.
  Another way to limit resource use is to specify resource limits as part of the deployment strategy.
  In the following example, each of `resources`, `cpu`, and `memory` is optional.
  
  ====
  
  [source,json]
  ----
  {
    "type": "Recreate",
    "resources": {
      "limits": {
        "cpu": "100m", <1>
        "memory": "256Mi" <2>
      }
    },
  }
  ----
  
  <1> `*cpu*` is in cpu units; `100m` represents 0.1 cpu units (`100 * 1e-3`)
  <2> `*memory*` is in bytes; `256Mi` represents 268435456 bytes (`256 * 2 ^ 20`)
  ====
  
  == Rollbacks
  Rollbacks revert an application back to a previous deployment and can be
  