anchor.diff:  }
   ----
   
  -
   == Scheduler Extensibility
  -As is the case with almost everything else in Kubernetes/OpenShift, the scheduler is built using a plugin model and the current implementation itself is a plugin.  There are two ways to extend the scheduler functionality.
  +As is the case with almost everything else in Kubernetes/OpenShift, the
  +scheduler is built using a plug-in model and the current implementation itself
  +is a plug-in. There are two ways to extend the scheduler functionality:
  +
  +* Enhancements
  +* Replacement
   
   === Enhancements
  -The scheduler functionality can be enhanced by adding new predicates and priority functions.  They can either be contributed upstream or maintained separately.  These predicates and priority functions would need to be registered with the scheduler factory and then specified in the scheduler policy file.
  +The scheduler functionality can be enhanced by adding new predicates and
  +priority functions. They can either be contributed upstream or maintained
  +separately. These predicates and priority functions would need to be registered
  +with the scheduler factory and then specified in the scheduler policy file.
   
   === Replacement
  -Since the scheduler is a plugin, it can be replaced in favor of an alternate implementation.  The scheduler code has a clean separation that watches new pods as they get created and identifies the most suitable node to host them.  It then creates bindings (pod to node bindings) for the pods using the master API.
  +Since the scheduler is a plug-in, it can be replaced in favor of an alternate
  +implementation. The scheduler code has a clean separation that watches new pods
  +as they get created and identifies the most suitable node to host them. It then
  +creates bindings (pod to node bindings) for the pods using the master API.
  
positive.code: }
  ----
  
  IMPORTANT: In all of the sample configurations below, the list of predicates and priority functions is truncated to include only the ones that pertain to the use case specified.  In practice, a complete/meaningful scheduler policy should include most, if not all, of the default predicates and priority functions listed above.
  
  Three topological levels defined as region (affinity) --> zone (affinity) --> rack (anti-affinity)
  ----
  
negative.code: }
  ----
  
  Three topological levels defined as city (affinity) -> building
  (anti-affinity) -> room (anti-affinity):
  ----
  {
  	"kind" : "Policy",
  