anchor.diff:  ==== Rollover
   
   The deployment process for Deployments is driven by a controller
  -loop, in contrast to deployment configurations which use deployer pods for every
  +loop, in contrast to DeploymentConfigs which use deployer pods for every
   new rollout. This means that a Deployment can have as many active
   ReplicaSets as possible, and eventually the deployment controller will scale
   down all old ReplicaSets and scale up the newest one.
   
  -Deployment configurations can have at most one deployer pod running, otherwise
  +DeploymentConfigs can have at most one deployer pod running, otherwise
   multiple deployers end up conflicting while trying to scale up what they think
   should be the newest ReplicationController. Because of this, only two
   ReplicationControllers can be active at any point in time. Ultimately, this
  
positive.code: 
  Deployments can be paused at any point in time, meaning you can also
  pause ongoing rollouts. On the other hand, you cannot pause deployer pods
  currently, so if you try to pause a deployment configuration in the middle of a
  rollout, the deployer process will not be affected and will continue until it
  finishes.
  
negative.code: [id="deployments-comparing-deploymentconfigs-{context}"]
  = Comparing Deployments and DeploymentConfigs
  
  Both Kubernetes Deployments and {product-title}-provided
  DeploymentConfigs are supported in {product-title}; however, it is
  recommended to use Deployments unless you need a specific feature or behavior
  provided by DeploymentConfigs.
  
  The following sections go into more detail on the differences between the two
  object types to further help you decide which type to use.
  
  [id='deployments-design-{context}']
  == Design
  
  One important difference between Deployments and DeploymentConfigs is the
  properties of the link:https://en.wikipedia.org/wiki/CAP_theorem[CAP theorem]
  that each design has chosen for the rollout process. DeploymentConfigs prefer
  consistency, whereas Deployments take availability over consistency.
  
  For DeploymentConfigs, if a node running a deployer Pod goes down, it will
  not get replaced. The process waits until the node comes back online or is
  manually deleted. Manually deleting the node also deletes the corresponding Pod.
  This means that you can not delete the Pod to unstick the rollout, as the
  kubelet is responsible for deleting the associated Pod.
  
  However, Deployments rollouts are driven from a controller manager. The
  controller manager runs in high availability mode on masters and uses leader
  election algorithms to value availability over consistency. During a failure it
  is possible for other masters to act on the same Deployment at the same time,
  but this issue will be reconciled shortly after the failure occurs.
  
  [id="delpoymentconfigs-specific-features-{context}"]
  == DeploymentConfigs-specific features
  