openstack/fuel-library
Code Issues Proposed changes

Removed download.mirantis.com references, other minor last-minute fixes.

Browse Source
This commit is contained in:
Nick Chase 2013-03-25 10:15:19 -04:00
parent d3c59dd9bb
commit e97cfc9d7c
3 changed files with 29 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/pages/installation-instructions/0055-installing-os-using-cobbler.rst
View File

@ -20,10 +20,10 @@ The process for each node looks like this:
#. Wait for the installation to complete.
#. Log into the new machine using root/r00tme.
#. **Change the root password.**
#. Check that networking is set up correctly and the machine can reach the Puppet Master and package repositories::
#. Check that networking is set up correctly and the machine can reach the Internet::
ping fuel-pm.your-domain-name.com
ping download.mirantis.com
ping www.mirantis.com
If you're unable to ping outside addresses, add the fuel-pm server as a default gateway::

2
docs/pages/installation-instructions/0060-deploying-openstack.rst
View File

@ -121,7 +121,7 @@ Next ``site.pp`` defines DNS servers and provides netmasks::
# Specify netmasks for internal and external networks.
$internal_netmask = '255.255.255.0'
$public_netmask = '255.255.255.0'
...
#Set this to anything other than pacemaker if you do not want Quantum HA
#Also, if you do not want Quantum HA, you MUST enable $quantum_network_node
#on the ONLY controller

57
docs/pages/production-considerations/0020-deployment-pipeline.rst
View File

@ -1,28 +1,25 @@
Redepolying an environment
--------------------------
Because Puppet is additive only, there is no ability to revert changes as you would in a typical application deployment.
If a change needs to be backed out, you must explicitly add a configuration to reverse it, check this configuration in,
and promote it to production using the pipeline. This means that if a breaking change did get deployed into production,
typically a manual fix was applied, with the proper fix subsequently checked into version control.
Because Puppet is additive only, there is no ability to revert changes as you would in a typical application deployment.
If a change needs to be backed out, you must explicitly add a configuration to reverse it, check this configuration in,
and promote it to production using the pipeline. This means that if a breaking change did get deployed into production,
typically a manual fix was applied, with the proper fix subsequently checked into version control.
Fuel combines the ability to isolate code changes while developing with minimizing the headaches associated
with maintaining multiple environments serviced by one puppet server by creating environments
Fuel combines the ability to isolate code changes while developing with minimizing the headaches associated
with maintaining multiple environments serviced by one puppet server by creating environments
Environments
^^^^^^^^^^^^
Puppet supports putting nodes into separate 'environments'. These environments can map cleanly to your development, QA and production life cycles, so it’s a way to hand out different code to different nodes.
Puppet supports putting nodes into separate 'environments'. These environments can map cleanly to your development, QA and production life cycles, so it’s a way to hand out different code to different nodes.
* On the Master/Server Node
* On the Master/Server Node
The Puppet Master tries to find modules using its ``modulepath`` setting, which is typically something like ``/etc/puppet/modules``.
You usually just set this value once in your ``/etc/puppet/puppet.conf``.
Environments expand on this idea and give you the ability to use different settings for different environments.
The Puppet Master tries to find modules using its ``modulepath`` setting, which is typically something like ``/etc/puppet/modules``. You usually just set this value once in your ``/etc/puppet/puppet.conf``. Environments expand on this idea and give you the ability to use different settings for different environments.
For example, you can specify several search paths. The following example dynamically sets the ``modulepath``
so Puppet will check a per-environment folder for a module before serving it from the main set::
For example, you can specify several search paths. The following example dynamically sets the ``modulepath`` so Puppet will check a per-environment folder for a module before serving it from the main set::
[master]
modulepath = $confdir/$environment/modules:$confdir/modules
@ -33,12 +30,11 @@ Environments
[development]
manifest = $confdir/$environment/manifests/site.pp
* On the Agent Node
* On the Agent Node
Once the agent node makes a request, the Puppet Master gets informed of its environment.
If you don’t specify an environment, the agent uses the default ``production`` environment.
Once the agent node makes a request, the Puppet Master gets informed of its environment. If you don’t specify an environment, the agent uses the default ``production`` environment.
To set an environment agent-side, just specify the environment setting in the ``[agent]`` block of ``puppet.conf``::
To set an environment agent-side, just specify the environment setting in the ``[agent]`` block of ``puppet.conf``::
[agent]
environment = development
@ -47,36 +43,35 @@ Environments
Deployment pipeline
^^^^^^^^^^^^^^^^^^^
* Deploy
* Deploy
In order to deploy multiple environments that don't interfere with each other,
you should specify the ``$deployment_id`` option in ``/etc/puppet/manifests/site.pp``. It should be an even integer value in the range of 1-254.
In order to deploy multiple environments that don't interfere with each other, you should specify the ``$deployment_id`` option in ``/etc/puppet/manifests/site.pp``. It should be an even integer value in the range of 0-254.
This value is used in dynamic environment-based tag generation. Fuel also apply that tag globally to all resources on each node. It is also used for the keepalived daemon, which evaluates a unique ``virtual_router_id``.
This value is used in dynamic environment-based tag generation. Fuel also apply that tag globally to all resources on each node. It is also used for the keepalived daemon, which evaluates a unique ``virtual_router_id``.
* Clean/Revert
* Clean/Revert
At this stage you just need to make sure the environment has the original/virgin state.
At this stage you just need to make sure the environment has the original/virgin state.
* Puppet node deactivate
* Puppet node deactivate
This will ensure that any resources exported by that node will stop appearing in the catalogs served to the agent nodes::
This will ensure that any resources exported by that node will stop appearing in the catalogs served to the agent nodes::
puppet node deactivate <node>
where <node> is the fully qualified domain name as seen in ``puppet cert list --all``.
where ``<node>`` is the fully qualified domain name as seen in ``puppet cert list --all``.
You can deactivate nodes manually one by one, or execute the following command to automatically deactivate all nodes::
You can deactivate nodes manually one by one, or execute the following command to automatically deactivate all nodes::
cert list --all | awk '! /DNS:puppet/ { gsub(/"/, "", $2); print $2}' | xargs puppet node deactivate
* Redeploy
* Redeploy
Fire up the puppet agent again to apply a desired node configuration
Fire up the puppet agent again to apply a desired node configuration
Links
^^^^^
* http://puppetlabs.com/blog/a-deployment-pipeline-for-infrastructure/
* http://docs.puppetlabs.com/guides/environment.html
* http://puppetlabs.com/blog/a-deployment-pipeline-for-infrastructure/
* http://docs.puppetlabs.com/guides/environment.html