* Ansible Powerplay

  Powerplay allows you to run multiple Ansible playbooks in
  parallel. Depending on how you organize your playbooks,
  this can be a solid win. I basically before this had been
  doing a playbook with multiple includes for other playbooks
  representing different servers in our stack. Playbook launching
  of playbooks is slow and very serial.

  Basically, the playbooks are all contained, 
  so no interdependencies. And in my case, running in the
  cloud, so no reason why they can't be running in parallel

  Powerplay allows you to specify vars common
  to all playbooks, and also vars specific
  to some playbooks so by which you can
  make your setup very DRY.

  All the Ansible playbooks are executed in seperate processes,
  and thus avoiding a number of the "side effects" you would
  normally encounter with running multiple playbooks with
  Ansible includes.

  For example, here is Powerplay integrated with tmux:
  #+CAPTION: Powerplay writing to tmux panes, one pane per playbook.
  #+NAME: Powerplay Example
  [[./examples/powerplay_screenshot.jpeg]]

** Features and Cavets
*** Integration with TMUX
    When running multiple Ansible Playbooks concurrently,
    one would like to be able to see the output of each
    in a reasonable manner. To faciliate this in this
    initial realse, we shall make heavy use of TMUX panes
    to dump the output.

    So basically, you need as many panes as you have
    concurrent Ansible Playbooks in this initial release. In 
    subsequent releases, Curses will be directly
    leveraged to create "tabs" for the multiple output
    streams. We may even do this, still, through TMUX.

    Your input on this is strongly encouarged. We will not
    be supporting Screen at all. Sorry.

** DSL Terminology & Documentation
*** DSL
    The DSL is straightforward as possible,
    simple and elegant to allow you to write 
    your Powerplays in a DRY manner.
**** configuration
     You can intersperse configuration blocks
     anywhere, and the expected nested scoping
     will take effect.
**** playbooks
     playbooks are a collection of groups, and
     each group are normally executed serially. This will
     allow you to organize your plays in an intelligent
     manner to deploy and manage resources and assets
     that may have to be done in a serial manner.
**** group
     A group is a collection of books that all execute
     in parallel. Books are required to be independent of
     each other.
**** book
     A book has a direct correspondence to an Ansible
     playbook, and will execute that Yaml file
     given the configuration variables as parameters.

     Here is where var inheritance becomes useful.

** Installation
   Easy installation. From command-line:
   #+BEGIN_SRC bash
   gem install ansible-powerplay
   #+END_SRC

   Or from a gemfile:
   #+BEGIN_SRC ruby
   gem 'ansible-powerplay'
   #+END_SRC

** Use
   Basically, cd to the root of your Ansible directory,
   and a .play file (see the example at: [[https://github.com/flajann2/ansible-powerplay/blob/master/examples/test.play][test.play]].

   You can place a config clause either globally,
   inside of playbooks, inside of groups, and the
   variable set up this way are inherited to the inner
   clauses, thus allowing you to keep your specifications
   DRYer.

   For example:
   #+BEGIN_SRC ruby
   # This is a global system configuration
   configuration :system do
     playbook_directory "playbooks"
   end
   #+END_SRC

   Note that 'playbook_directory' is special, as it allows
   you to define the directory all of your Ansible playbooks
   can be found. You can also specify this anywhere
   you can use the configuration clause, so you
   may set up different playbook directories for different
   playbook collections.

   #+BEGIN_SRC ruby
   # sṕecific configuration for :development
   configuration do 
    stack :development
    krell_type "t2.small"
    servers 1
    rolling 3
    krell_disk_size 20
   end
   #+END_SRC
   
   The above shows Ansible variables for my specialiezd setup
   that is geared with work with AWS. You are free to specify
   any variables here, which will be injected into 
   ansible-playbook through the '--extra-vars' parameter.

   Here is a group clause with a single book in it:

   #+BEGIN_SRC ruby
   # Groups are executed serially.
   group :first, "our very first group" do
     # Books within a group are executed in parallel,
     # and therefore must be independent of each other.
     book :nat, "nat.yml"
   end
   #+END_SRC

   Which issues the following command to Ansible (based on the
   earlier configuration):

   #+BEGIN_SRC bash
   ansible-playbook playbooks/nat.yml \
     --extra-vars "playbook_directory=playbooks stack=development krell_type=t2.small servers=1 rolling=3 krell_disk_size=20"
   #+END_SRC

   And if our group had more book entries, as in the second 
   example:

   #+BEGIN_SRC ruby
   group :second, "our second group" do
     book :rabbit, "rabbitmq_cluster.yml" do
       krell_type "t2.medium"
     end

     book :es_cluster, "elasticsearch_cluster.yml" do
       esver "1.7.4"
       cluster_name :es
       servers 3
       heapsize "2g"
       krell_type "t2.medium"
       krell_disk_size 200
     end
   end
   #+END_SRC

   Both the :rabbit and :es_cluster books would be executed
   in parallel.

*** Example .play Script
    To play around with the example .play script,
    Clone the [[https://github.com/flajann2/ansible-powerplay][Ansible Powerplay]] project locally:

    #+BEGIN_SRC bash
    git clone git@github.com:flajann2/ansible-powerplay.git
    #+END_SRC

    and go to the examples directory to find test.play.

*** Submitting your example .play scripts
    Please feel free to do pull requests of your
    scripts or submit them to me as Gist snippets
    and I will include them if they are good.

** Contributing to ansible-powerplay
   Your parcipitation is welcome, and I will respond to your
   pull requests in a timely fashion as long as I am not
   pulling an "Atlas" at my current job! lol
 
   + Check out the latest master to make sure the feature hasn't been implemented or the bug hasn't been fixed yet.
   + Check out the issue tracker to make sure someone already hasn't requested it and/or contributed it.
   + Fork the project.
   + Start a feature/bugfix branch.
   + Commit and push until you are happy with your contribution.
   + Make sure to add tests for it. This is important so I don't break it in a future version unintentionally.
   + Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

** Copyright
   Copyright (c) 2016 Fred Mitchell. See LICENSE.txt for
   further details.