Adds back a collection of documentation in README.

Previous review of README.md resulted in removal of some documentation,
  after subsequent review this will add it back.  Few release notes
  added to account for things added since the first patch set of the new
  README was submitted.

Change-Id: I453a6dc46561c02c73bb97d40691a1c45ea36614
This commit is contained in:
Cody Herriges
2013-06-18 20:59:59 -07:00
parent 777b2381e2
commit bc897c08b7

View File

@@ -25,14 +25,16 @@ The Openstack Puppet Modules are a flexible Puppet implementation capable of con
* [horizon](http://horizon.openstack.org/) (web front end) * [horizon](http://horizon.openstack.org/) (web front end)
* [cinder](http://cinder.openstack.org/) (block storage exporting) * [cinder](http://cinder.openstack.org/) (block storage exporting)
These modules are based on the [openstack documentation](http://docs.openstack.org/) [Puppet Modules](http://docs.puppetlabs.com/learning/modules1.html#modules) are a collection of related contents that can be used to model the configuration of a discrete service.
These Puppet modules are based on the [openstack documentation](http://docs.openstack.org/).
Module Description Module Description
------------------ ------------------
There are a lot of moving pieces in Openstack, consequently there are several Puppet modules needed to cover all these pieces. Each module is then made up of several class definitions, resource declarations, defined resources, and custom types/providers. A common pattern to reduce this complexity in Puppet is to create a composite module that bundles all these component type modules into a common set of configurations. The openstack module is doing this compositing and exposing a set of variables needed to be successful in getting a functional stack up and running. Multiple companies and individuals contributed to this module with the goal of producing a quick way to build single and multi-node installations that was based off documented Openstack best practices. There are a lot of moving pieces in Openstack, consequently there are several Puppet modules needed to cover all these pieces. Each module is then made up of several class definitions, resource declarations, defined resources, and custom types/providers. A common pattern to reduce this complexity in Puppet is to create a composite module that bundles all these component type modules into a common set of configurations. The openstack module is doing this compositing and exposing a set of variables needed to be successful in getting a functional stack up and running. Multiple companies and individuals contributed to this module with the goal of producing a quick way to build single and multi-node installations that was based off documented Openstack best practices.
**Dependencies** **Pre-module Dependencies**
* [Puppet](http://docs.puppetlabs.com/puppet/) 2.7.12 or greater * [Puppet](http://docs.puppetlabs.com/puppet/) 2.7.12 or greater
* [Facter](http://www.puppetlabs.com/puppet/related-projects/facter/) 1.6.1 or greater (versions that support the osfamily fact) * [Facter](http://www.puppetlabs.com/puppet/related-projects/facter/) 1.6.1 or greater (versions that support the osfamily fact)
@@ -49,6 +51,19 @@ Setup
* The entirety of Openstack! * The entirety of Openstack!
### Installing Puppet
Puppet Labs provides two tools for getting started with managing configuration modeling with Puppet, Puppet Enterprise or its underlying opensource projects, i.e. Puppet and MCollective.
* [Puppet Enterprise](http://docs.puppetlabs.com/#puppet-enterprisepelatest) is a complete configuration management platform, with an optimized set of components proven to work well together. Is free up to 10 nodes so if you're just using Puppet for Openstack management this might just work perfectly. It will come configured with a handful of extra components that make for a richer experience, like a web interface for managing the orchestration of Puppet and certificate management.
* [Puppet](http://docs.puppetlabs.com/#puppetpuppet) manages your servers: you describe machine configurations in an easy-to-read declarative language, and Puppet will bring your systems into the desired state and keep them there. This is the opensource version of Puppet and should be available in your operating system's package repositories but it is generally suggested you use the [yum](http://yum.puppetlabs.com) or [apt](http://apt.puppetlabs.com) repositories from Puppet Labs if possible.
Consult the documentation linked above to help you make your decision but don't fret about the choice to much, opensource Puppet agents are compatible with Puppet Enterprise Puppet masters.
### Optional Puppet features
The swift portions of this module needs Puppet's [exported resources](http://docs.puppetlabs.com/puppet/3/reference/lang_exported.html). Exported resources leverages the PuppetDB to export and share data across other Puppet managed nodes.
### Installing openstack ### Installing openstack
example% puppet module install puppetlabs/openstack example% puppet module install puppetlabs/openstack
@@ -90,6 +105,16 @@ Every node that is configured to be a cinder volume service must have a volume g
* Compute nodes should be deployed onto physical hardware. * Compute nodes should be deployed onto physical hardware.
* If compute nodes are deployed on virtual machines for testing, the libvirt_type parameter for the openstack::compute class should probably be configured as 'qemu'. This is because most virtualization technologies do now pass through the virtualization CPU extensions to their virtual machines. * If compute nodes are deployed on virtual machines for testing, the libvirt_type parameter for the openstack::compute class should probably be configured as 'qemu'. This is because most virtualization technologies do now pass through the virtualization CPU extensions to their virtual machines.
```puppet
class { 'openstack:compute': libvirt_type => 'qemu' }
```
**or**
```puppet
class { 'openstack::all: libvirt_type => 'qemu' }
```
### Beginning with openstack ### Beginning with openstack
Utlization of this module can come in many forms. It was designed to be capable of deploying all services to a single node or distributed across several. This is not an exhaustive list, we recommend you consult and understand all the manifests included in this module and the [core openstack](http://docs.openstack.org) documentation. Utlization of this module can come in many forms. It was designed to be capable of deploying all services to a single node or distributed across several. This is not an exhaustive list, we recommend you consult and understand all the manifests included in this module and the [core openstack](http://docs.openstack.org) documentation.
@@ -276,7 +301,7 @@ It is recommended that you first configure the controller before configuring you
openstack_compute1> puppet agent -t --certname openstack_compute1 openstack_compute1> puppet agent -t --certname openstack_compute1
openstack_compute2> puppet agent -t --certname openstack_compute2 openstack_compute2> puppet agent -t --certname openstack_compute2
## Verifying an OpenStack deployment ### Verifying an OpenStack deployment
Once you have installed openstack using Puppet (and assuming you experience no errors), the next step is to verify the installation: Once you have installed openstack using Puppet (and assuming you experience no errors), the next step is to verify the installation:
@@ -336,7 +361,7 @@ which stores environment variables that can be used for authentication of openst
it is reachable by its floating ip address (which will require it is reachable by its floating ip address (which will require
some security groups) some security groups)
## Building your own custom deployment scenario for Openstack ### Building your own custom deployment scenario for Openstack
The classes included in the Openstack module are implemented using a number of other modules. These modules can be used directly to create a customized openstack deployment. The classes included in the Openstack module are implemented using a number of other modules. These modules can be used directly to create a customized openstack deployment.
@@ -457,3 +482,6 @@ Release Notes
* Refactor of glance and cinder related classes. * Refactor of glance and cinder related classes.
* Nova-conductor added. * Nova-conductor added.
* Various cleanups and bug fixes. * Various cleanups and bug fixes.
* Adds the option to automatically set up RedHat or Ubuntu supplemental repositories.
* Class['openstack::all'] refactor that adds support of future compute nodes to be added.
* The cinder-volume logical volume group is no longer a requirement.