Install lxml dependency

Running tempest smoke tests fail on all the XML tests due to lxml not
being installed in keystone containers.  The lxml package is no longer
a hard dependency since lxml is only required when using the (optional)
XmlBodyMiddleware middleware.

Ideally we'd want to remove XmlBodyMiddleware middleware since it's
being removed in Kilo, however I have not seen an option to disable all
the XML tests in tempest.
Added my inital work on ansible-swift.

I have tried to put all the files in where I think they will go:

  swift_setup.yml -> etc/rpc_deploy/
  roles swift_{common,account,container,object} -> rpc_deployment/roles
  swift_intentory -> scripts/swift_inventory.py

To generate a hosts file run:

  python swift_inventory.py -s etc/rpc_deploy/swift_setup.yml -d

  NOTE: -d is dry-run so prints to screen, it will actually place
        it whereever you specify it in the swift_setup.yml file.
Debugging the generation of storage policy definitions.

I have been debugging the hosts file being generated, doing so I found a
few bugs in the swift_inventory script.
Swift_inventory script now concats policy data

The swift_inventory script now combines the required variables to
generate the storage policy definitions into a concatenated string
and stored with the host.

  extra_data=<name>:<index>:<depricated>:<type>

E.G:

  extra_data=gold:0:True:Replication

If the host is a member of more then one storage group then these
entries are concatenated together with a ';':

  extra_data=<name1>:<index1>:..:<type>;<name2>:<index2>....

The swift.conf file template now takes this into account and
is generated correctly.
Place swift.conf

The swift_common role now places the swift.conf file in /etc/swfit.
The file is generated from a template.
First version of a ring builder

This change actually does quite a bit.

  - Removes duplication in the swift yaml file, meaning you can now add
    hosts directly to a global hosts section, which then can be refenced by
    name. You can still define hosts in the other hosts areas, but this stops
    duplication.

  - Adds a bunch of extra settings to the swift yaml file to support ring
    building, including:
      * min_part_hours
      * port (for account, container and object (storage policies))
      * drives
      * repl_ip (specify a replication IP to use, if it differes from main)
      * repl_port (a different replication port.. as above)

  - Passing the server ports and the correct drives value through to templates

  - scripts/swift_rings.py:
      This script reads in the swift.yaml file and generates all required
      rings. I have gone this approach as this why there is no annoying
      ansible getting in the way. The next step is to write a rings playbook
      that runs the swift_rings.py script locally and then copies all the rings
      to every memeber of the swfit group.

      Alternativelty we could pass the script and swift yaml to each node (via
      swfit_common role) and have a simple playbook that runs the script on
      each node to build the rings.

One benefit of swfit_rings that reads in the yaml, is that we could actaully
simplfy what actaully needs to be translated into an ansible inventory. (no
ring specific settings).
Added a build swift rings playbook

I have written a playbook that builds the rings locally and copies
them to all hosts in the swift group.

In order to write it and test, I put together an ansible server and
a bunch of nodes. The build script:

  - On local:
    * Runs the swift_common role (so swift source is downloaded and
      installed so the ringbuilder code exists).
    * Makes sure /etc/swift/rings exist (as a place to store the rings
      locally).
    * Runs the scripts/swift_rings.py script on the swift yaml to
      generate the keys.
      NOTE: These are hard coded locations atm (testing purposes).

  - Then copies the rings to /etc/swift on all the swift servers.

NOTE: The swift_ringbuilder code (from swift) which we make use of
      automatically makes dated backups of the rings on the local
      ansible server (Whatever runs the code). As of this playbook
      these are in /etc/swift/rings/backup/

In the process of building and testing the playbook I also fixed up
a bunch of errors in the swift_common role. And now seems to be working
a treat.
Adjust environment file to spin up swift-proxy containers

* Add a swift_all group_vars file
Fix up the swift-proxy runs

* Fix some typoes
* Add haproxy for swift-proxy
* Add swift_vars
* Remove redundant tasks that are handled by container_common

Conflicts:
	rpc_deployment/roles/swift_common/tasks/main.yml
Setup the swift_common task to place the swift.conf template

* Add task for swift.conf template
* Remove swift_common unrequired tasks
* Add further variables
* Fix some typos in the conf teplate.
Fix up the container/account/object tasks/plays

* Adjust the variable names
* Fix some typos
* Remove unrequired tasks
* Adjust config files
* Add playbooks for proxy/storage
* Fix cron jobs
Adjust swift.conf to work with rpc_user_config

* Set storage policies appropriately
* Set the storage policies up in rpc_user_config
* Adjust sample rpc_user_config
* Loop through the storage policies in the swift.conf
Set out the ring distribution and configuration plays

* Add tasks for building the ring and distributing the play
* Add additional playbook to handle ring building
* Add "overall" playbook for swift-all
Clean up some unrequired swift scripts

* Remove the swift_inventory script
* Remove the swift_rings.py (its moved to the swift_ring_builder role)
* Remove the swift_setup.yml (We will use rpc_user_config.yml for these)
Adjust the ring-builder to happen on the local host

* This needs to be built on the host (where the inventory file is)
* Copy up from local host to remote hosts
* Tag directory creation from container_common
* Run against only swift_hosts and swift_proxy (Avoids running against proxy containers)
Adjust swift_rings.py to work with rpc_user_config.yml

* Adjust the way hosts/storage policies are setup
* Set this as a template so default port can be a variable
* First pass at changing the swift_rings.py file
Fix keystone endpoint creation for Swift

* Setup the keystone endpoint for swift
* Move swift-proxy port to 8888 (8000 is used by heat)
* Typo prevented object server services from restarting
* Adjust order of swift plays for swift-all.yml
Fix haproxy endpoint for swift-proxy

HAProxy settings were wrong causing swift-proxy to 503
Adjust the sample /etc/rpc_deplooy/rpc_user_config.yml

* Change this to reflect the changes required for swift
Fix haproxy vars for swift-proxy again

* Checks cause haproxy service to fail shortly after starting up!