updated readme
This commit removes all of the rax notes and reflows the readme. Also at the bottom of the readme i've added a note for all of the experimental modules we are running. Change-Id: I5e99ec74e298acff64361ddcd97eaaaf22466f48
This commit is contained in:
Kevin Carter
parent
3a13141bc5
commit
3e2e907aba
72
README.rst
72
README.rst
|
|
@ -1,25 +1,9 @@
|
|||
Rackspace Private Cloud Version 9.0
|
||||
###################################
|
||||
Openstack Deployment with Ansible
|
||||
#################################
|
||||
:date: 2014-09-25 09:00
|
||||
:tags: rackspace, lxc, openstack, cloud, ansible
|
||||
:tags: lxc, openstack, cloud, ansible
|
||||
:category: \*nix
|
||||
|
||||
License
|
||||
-------
|
||||
Copyright 2014, Rackspace US, Inc.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at:
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
|
||||
Official Documentation
|
||||
----------------------
|
||||
|
||||
|
|
@ -63,31 +47,22 @@ Infrastructure:
|
|||
Assumptions
|
||||
-----------
|
||||
|
||||
This repo assumes that you have setup the host servers that will be running the OpenStack infrastructure with three
|
||||
bridged network devices named: ``br-mgmt``, ``br-vxlan``, ``br-vlan``. These bridges will be used throughout
|
||||
the OpenStack infrastructure.
|
||||
This repo assumes that you have setup the host servers that will be running the OpenStack infrastructure with three bridged network devices named: ``br-mgmt``, ``br-vxlan``, ``br-vlan``. These bridges will be used throughout the OpenStack infrastructure.
|
||||
|
||||
The repo also relies on configuration files found in the `/etc` directory of this repo.
|
||||
If you are running Ansible from an "unprivileged" host, you can place the contents of the /etc/ directory in your
|
||||
home folder; this would be in a directory similar to `/home/<myusername>/rpc_deploy/`. Once you have the file in place, you
|
||||
will have to enter the details of your environment in the `rpc_user_config.yml` file; please see the file for how
|
||||
this should look. After you have a bridged network and the files/directory in place, continue on to _`Base Usage`.
|
||||
If you are running Ansible from an "unprivileged" host, you can place the contents of the /etc/ directory in your home folder; this would be in a directory similar to `/home/<myusername>/rpc_deploy/`. Once you have the file in place, you will have to enter the details of your environment in the `rpc_user_config.yml` file; please see the file for how this should look. After you have a bridged network and the files/directory in place, continue on to _`Base Usage`.
|
||||
|
||||
|
||||
Base Usage
|
||||
----------
|
||||
|
||||
All commands must be executed from the `rpc_deployment` directory. From this directory you will have access to all
|
||||
of the playbooks, roles, and variables. It is recommended that you create an override file to contain any and all
|
||||
variables that you wish to override for the deployment. While the override file is is not required it will make life
|
||||
a bit easier.
|
||||
All commands must be executed from the ``rpc_deployment`` directory. From this directory you will have access to all of the playbooks, roles, and variables. It is recommended that you create an override file to contain any and all variables that you wish to override for the deployment. While the override file is is not required it will make life a bit easier. The default override file for the RPC environment is the ``user_variables.yml`` file.
|
||||
|
||||
All of the variables that you may wish to update are in the `vars/` directory, however you should also be aware that
|
||||
services will pull in base group variables as found in `inventory/group_vars`.
|
||||
All of the variables that you may wish to update are in the ``vars/`` directory, however you should also be aware that services will pull in base group variables as found in ``inventory/group_vars``.
|
||||
|
||||
All playbooks exist in the ``playbooks/`` directory and are grouped in different sub-directories.
|
||||
|
||||
All of the keys, tokens, and passwords are in the `user_variables.yml` file. This file contains no
|
||||
All of the keys, tokens, and passwords are in the ``user_variables.yml`` file. This file contains no
|
||||
preset passwords. To setup your keys, passwords, and tokens you will need to either edit this file
|
||||
manually or use the script ``pw-token-gen.py``. Example:
|
||||
|
||||
|
|
@ -97,7 +72,7 @@ manually or use the script ``pw-token-gen.py``. Example:
|
|||
scripts/pw-token-gen.py --file /etc/rpc_deploy/user_variables.yml
|
||||
|
||||
|
||||
Example usage from the `rpc_deployment` directory in the `ansible-rpc-lxc` repository
|
||||
Example usage from the `rpc_deployment` directory in the ``ansible-rpc-lxc`` repository
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
|
@ -115,33 +90,24 @@ About Inventory
|
|||
---------------
|
||||
|
||||
All things that Ansible cares about are located in inventory. In the Rackspace Private Cloud all
|
||||
inventory is dynamically generated using the previously mentioned configuration files. While this is a dynamically
|
||||
generated inventory, it is not 100% generated on every run. The inventory is saved in a file named
|
||||
`rpc_inventory.json` and is located in the directory where you've located your user configuration files. On every
|
||||
run a backup of the inventory json file is created in both the current working directory as well as the location where
|
||||
the user configuration files exist. The inventory json file is a living document and is intended to grow as the environment
|
||||
scales in infrastructure. This means that the inventory file will be appended to as you add more nodes and or change the
|
||||
container affinity from within the `rpc_user_config.yml` file. It is recommended that the base inventory file be backed
|
||||
up to a safe location upon the completion of a deployment operation. While the dynamic inventory processor has guards in it
|
||||
to ensure that the built inventory is not adversely effected by programmatic operations this does not guard against user error
|
||||
and/or catastrophic failure.
|
||||
inventory is dynamically generated using the previously mentioned configuration files. While this is a dynamically generated inventory, it is not 100% generated on every run. The inventory is saved in a file named `rpc_inventory.json` and is located in the directory where you've located your user configuration files. On every run a backup of the inventory json file is created in both the current working directory as well as the location where the user configuration files exist. The inventory json file is a living document and is intended to grow as the environment scales in infrastructure. This means that the inventory file will be appended to as you add more nodes and or change the container affinity from within the `rpc_user_config.yml` file. It is recommended that the base inventory file be backed up to a safe location upon the completion of a deployment operation. While the dynamic inventory processor has guards in it to ensure that the built inventory is not adversely effected by programmatic operations this does not guard against user error and/or catastrophic failure.
|
||||
|
||||
|
||||
Scaling
|
||||
-------
|
||||
|
||||
If you are scaling the environment using the dynamically generated inventory you should know that the inventory was designed to
|
||||
generate new entries in inventory and not remove entries from inventory. These playbooks will build an environment to spec so if
|
||||
container affinity is changed and or a node is added or removed from an environment the user configuration file will need to be
|
||||
modified as well as the inventory json. For this reason it is recommended that should a physical node need replacing it should be
|
||||
renamed the same as the previous one. This will make things easier when rebuilding the environment. Additionally if a container
|
||||
is needing to be replaced it is better to simply remove the misbehaving container and rebuild it using the existing inventory.
|
||||
If you are scaling the environment using the dynamically generated inventory you should know that the inventory was designed to generate new entries in inventory and not remove entries from inventory. These playbooks will build an environment to spec so if container affinity is changed and or a node is added or removed from an environment the user configuration file will need to be modified as well as the inventory json. For this reason it is recommended that should a physical node need replacing it should be renamed the same as the previous one. This will make things easier when rebuilding the environment. Additionally if a container is needing to be replaced it is better to simply remove the misbehaving container and rebuild it using the existing inventory.
|
||||
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
* Library has an experimental `Keystone` module which adds ``keystone:`` support to Ansible.
|
||||
* Library has an experimental `Swift` module which adds ``swift:`` support to Ansible.
|
||||
* Library has an experimental `LXC` module which adds ``lxc:`` support to Ansible.
|
||||
* Library has an experimental `keystone` module which adds ``keystone:`` support to Ansible.
|
||||
* Library has an experimental `swift` module which adds ``swift:`` support to Ansible.
|
||||
* Library has an experimental `neutron` module which adds ``keystone:`` support to Ansible.
|
||||
* Library has an experimental `glance` module which adds ``keystone:`` support to Ansible.
|
||||
* Library has an experimental `lxc` module which adds ``lxc:`` support to Ansible.
|
||||
* Library has an experimental `memcached` module which adds ``lxc:`` support to Ansible.
|
||||
* Library has an experimental `name2int` module which adds ``lxc:`` support to Ansible.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue