Update Readme/Changelog for release
* Change the clearly outdated things in the README file * Update Changelog with the release date/version
This commit is contained in:
Christopher H. Laco
parent
5b039c183f
commit
11ca020410
@ -1,5 +1,5 @@
|
||||
# Changelog
|
||||
|
||||
## 9.0.0rc3 - 2014-08-xx
|
||||
## 9.0.0 - 2014-09-25
|
||||
|
||||
- Added Changelog
|
||||
- Initial Release
|
||||
|
||||
88
README.rst
88
README.rst
@ -1,19 +1,29 @@
|
||||
Ansible Openstack LXC Playbook
|
||||
##############################
|
||||
:date: 2013-09-05 09:51
|
||||
Rackspace Private Cloud Version 9.0
|
||||
###################################
|
||||
:date: 2014-09-25 09:00
|
||||
:tags: rackspace, lxc, openstack, cloud, ansible
|
||||
:category: \*nix
|
||||
|
||||
Deploy Openstack in Containers
|
||||
==============================
|
||||
License
|
||||
-------
|
||||
Copyright 2014, Rackspace US, Inc.
|
||||
|
||||
First Pass at Ansible playbook for LXC (openstack) Containers.
|
||||
Make sure that you have the custom Ansible module installed on
|
||||
your local system prior to running the playbook.
|
||||
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:
|
||||
|
||||
Expect bugs and general unexplainable issues and the ever so popular
|
||||
API change due to general messing about with bits.
|
||||
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
|
||||
----------------------
|
||||
|
||||
Comprehensive installation guides, including FAQs and release notes, can be found at http://docs.rackspace.com
|
||||
|
||||
Playbook Support
|
||||
----------------
|
||||
@ -43,29 +53,24 @@ OpenStack:
|
||||
* neutron-linuxbridge-agent
|
||||
|
||||
|
||||
Infra:
|
||||
* haproxy
|
||||
* galara
|
||||
Infrastructure:
|
||||
* galera
|
||||
* rabbitmq
|
||||
* Deploy-Containers
|
||||
* Destroy-Containers
|
||||
* Clone-Container
|
||||
* Archive-Container
|
||||
* Archive-all-containers
|
||||
* Deploy-archived-container
|
||||
|
||||
* logstash
|
||||
* elastic-search
|
||||
* kibana
|
||||
|
||||
Assumptions
|
||||
-----------
|
||||
|
||||
This repo assumes that you have setup the host server that will be running the Openstack Infrastructure with three
|
||||
bridged network devices named: ``br-mgmt``, ``br-vmnet``, ``br-ext``. Through 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 "Un-privileged" host, you can place the contents of the /etc/ directory in your
|
||||
home folder; this would be in a directory similar to `/home/kevin/rpc_deploy/`. Once you have the file in place, you
|
||||
will have to input the details of your environment in the `rpc_user_config.yml` file; please see the file for how
|
||||
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`.
|
||||
|
||||
|
||||
@ -109,17 +114,17 @@ Example usage from the `rpc_deployment` directory in the `ansible-rpc-lxc` repos
|
||||
About Inventory
|
||||
---------------
|
||||
|
||||
In ansible all things that ansible cares about are located in inventory. In the Rackspace Private Cloud all
|
||||
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,
|
||||
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 programatic operations this does not guard against user error
|
||||
and or catastrophic failure.
|
||||
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
|
||||
@ -131,29 +136,12 @@ container affinity is changed and or a node is added or removed from an environm
|
||||
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.
|
||||
The reasons that bursting up and down in openstack is less than idea when talking about the infrastructure nodes is outside the
|
||||
scope of this document though its safe to say that the sheer volume of moving parts within openstack make this a precarious process.
|
||||
|
||||
|
||||
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 `LXC` module which adds ``lxc:`` support to Ansible.
|
||||
|
||||
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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user