anchor.diff:  *Periscope brings QoS and autoscaling to Hadoop YARN. Built on cloud resource management and YARN schedulers, allows to associate SLA policies to applications.*
   
   >>>>>>> 2a07954... PERI-2 minor fix
  +=======
  +*Periscope brings QoS and autoscaling to Hadoop YARN. Built on cloud resource management and YARN schedulers,it allows to associate SLA policies to applications.*
  +>>>>>>> 046962f... PERI-2 typos fixed
   
   ##Overview
   
  -The purpose of Periscope is to bring QoS to a multi-tenant Hadoop cluster, while allowing to apply SLAs to individual applications and customers.
  -At [SequenceIQ](http://sequenceiq.com) working with multi-tenant Hadoop clusters for quite a while we have always seen the same frustration and fight for resource between users.
  +The purpose of Periscope is to bring QoS and autoscaling to a multi-tenant Hadoop YARN cluster, while allowing to apply SLA policies to individual applications.
  +At [SequenceIQ](http://sequenceiq.com) working with multi-tenant Hadoop clusters for quite a while, we have always seen the same frustration and fight for resource between users.
   The **FairScheduler** was partially solving this problem - bringing in fairness based on the notion of [Dominant Resource Fairness](http://static.usenix.org/event/nsdi11/tech/full_papers/Ghodsi.pdf).
   With the emergence of Hadoop 2 YARN and the **CapacityScheduler** we had the option to maximize throughput and utilization for a multi-tenant cluster in an operator-friendly manner.
   The scheduler works around the concept of queues. These queues are typically setup by administrators to reflect the economics of the shared cluster.
  -While this is a pretty good abstraction and brings some level of SLA for `predictable` workloads, it often needs proper `design ahead`.
  +While this is a pretty good abstraction and brings some level of SLA for predictable workloads, it often needs proper design ahead.
   The queue hierarchy and resource allocation needs to be changed when new tenants and workloads are moved to the cluster.
   
   Periscope was designed around the idea of `autoscaling` clusters - without any need to preconfigure queues, cluster nodes or apply capacity planning ahead.
   
   ##How it works
   
  -Periscope monitors the application progress, the number of YARN containers/resources and their allocation, queue depths, and the number of available cluster nodes and their health.
  +Periscope monitors the application progress, the number of YARN containers/resources and their allocation, queue depths, the number of available cluster nodes and their health. 
   Since we have switched to YARN a while ago (been among the first adopters) we have run an open source [monitoring project](https://github.com/sequenceiq/yarn-monitoring), based on R.
   We have been collecting metrics from the YARN Timeline server, Hadoop Metrics2 and Ambari's Nagios/Ganglia - and profiling the applications and correlating with these metrics.
  -One of the key findings was that while low level metrics are good to understand the cluster health - they might not necessarily help on making decisions when applying different SLAs on a multi-tenant cluster. 
  +One of the key findings was that while low level metrics are good to understand the cluster health - they might not necessarily help on making decisions when applying different SLA policies on a multi-tenant cluster. 
   Focusing on higher level building blocks as queue depth, YARN containers, etc actually brings in the same quality of service, while not being lost in low level details.
  -
  -_Example: Applying SLA based on `resource` load might not be the best solution - each application tasks generates different loads, and a CPU heavy step might be followed by an I/O heavy one - making a decision based on a low `snapshot` might not be the right option (the FairScheduler does something similar for the dominant resource).
  -Also note that a YARN cluster can run different applications - MR2, HBase, Spark, etc - and they all generate different load across different timeframes.
  -When YARN allocates containers it associates `resources` - it's actually more predictable to let YARN to deal with the resource allocation, and have Periscope orchestrate the process._
   
   Periscope works with two types of Hadoop clusters: `static` and `dynamic`. Periscope does not require any pre-installation - the only thing it requires is to be `attached` to an Ambari server's REST API.
   
  
positive.code: 
  <<<<<<< HEAD
  <<<<<<< HEAD
  *Periscope is a heuristic Hadoop scheduler you associate with a QoS profile. Built on YARN schedulers, cloud and VM resource management API's it allows you to associate SLA's to applications and customers.*
  <<<<<<< HEAD
  >>>>>>> f4bf1b1... PERI-2 apiary template added
  
negative.code: =======
    8. Attach priorities to SLAs
  
  <<<<<<< HEAD
  >>>>>>> a0f5794... PERI-2 apiary changes
  =======
  _Note: not all of the features above are supported in the first `public beta` version. There are dependencies we contributed to Hadoop, Ambari and YARN and they will be included in the next releases (1.7 and 2.6)_
  
  >>>>>>> 046962f... PERI-2 typos fixed
  
  #Group Clusters
  <<<<<<< HEAD
  