From 96cd4737e9347f005d66bb2e077bdb8bc63078a4 Mon Sep 17 00:00:00 2001 From: Tomas Sedovic Date: Thu, 18 Feb 2016 18:30:47 +0100 Subject: [PATCH] Fix formatting and typos Change-Id: Ie3f7497de77d8e9deceb1c06a381654e539d655f --- doc/source/advanced_deployment/deploy_manila.rst | 8 ++++---- doc/source/advanced_deployment/extra_config.rst | 12 ++++++------ .../advanced_deployment/network_isolation.rst | 16 ++++++++-------- doc/source/advanced_deployment/node_config.rst | 10 +++++----- .../advanced_deployment/profile_matching.rst | 6 +++--- .../basic_deployment/basic_deployment_cli.rst | 2 +- doc/source/contributions/contributions.rst | 4 ++-- doc/source/environments/virtual.rst | 6 +++--- doc/source/introduction/architecture.rst | 11 ++++++----- doc/source/post_deployment/quiesce_compute.rst | 2 +- .../post_deployment/replace_controller.rst | 2 +- 11 files changed, 40 insertions(+), 39 deletions(-) diff --git a/doc/source/advanced_deployment/deploy_manila.rst b/doc/source/advanced_deployment/deploy_manila.rst index 572716dd..adcfee9c 100644 --- a/doc/source/advanced_deployment/deploy_manila.rst +++ b/doc/source/advanced_deployment/deploy_manila.rst @@ -67,10 +67,10 @@ Creating the Share #. Create a share network to host the shares: - - Create the overcloud networks. The - :doc:`../basic_deployment/basic_deployment` doc has a more detailed - explanation about creating the network and subnet. Note that you may also - need to perform the following steps to get Manila working:: + - Create the overcloud networks. The :doc:`../basic_deployment/basic_deployment` + doc has a more detailed explanation about creating the network + and subnet. Note that you may also need to perform the following + steps to get Manila working:: neutron router-create router1 neutron router-interface-add router1 [subnet id] diff --git a/doc/source/advanced_deployment/extra_config.rst b/doc/source/advanced_deployment/extra_config.rst index 81de8c37..7efd4ca3 100644 --- a/doc/source/advanced_deployment/extra_config.rst +++ b/doc/source/advanced_deployment/extra_config.rst @@ -100,7 +100,7 @@ You may then deploy your overcloud referencing the additional environment file:: For a more complete example, which creates an additional user and configures SSH keys by accessing the nova metadata server, see -/usr/share/openstack-tripleo-heat-templates/firstboot/userdata_example.yaml +`/usr/share/openstack-tripleo-heat-templates/firstboot/userdata_example.yaml` on the undercloud node or the tripleo-heat-templates_ repo. .. _tripleo-heat-templates: https://git.openstack.org/openstack/tripleo-heat-templates @@ -122,7 +122,7 @@ integration points for additional third-party services, drivers or plugins. configuration, see :ref:`node_config` as this may provide a simpler solution. .. note:: - Note, the per-node interface only enable *individual* nodes to be configured, + The per-node interface only enable *individual* nodes to be configured, if cluster-wide configuration is required, the Post-Deploy interfaces should be used instead. @@ -157,9 +157,9 @@ via standard heat SoftwareConfig_ resources:: NodeDeployment: type: OS::Heat::SoftwareDeployment - properties: - config: {get_resource: NodeConfig} - server: {get_param: server} + properties: + config: {get_resource: NodeConfig} + server: {get_param: server} outputs: deploy_stdout: description: Deployment reference, used to trigger post-deploy on changes @@ -178,7 +178,7 @@ hence when any post-deploy actions (such as re-applying puppet manifests on upda may need to be performed. For a more complete example showing how to apply a personalized map of per-node configuration -to each node, see /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml +to each node, see `/usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml` or the tripleo-heat-templates_ repo. .. _SoftwareConfig: http://docs.openstack.org/developer/heat/template_guide/software_deployment.html diff --git a/doc/source/advanced_deployment/network_isolation.rst b/doc/source/advanced_deployment/network_isolation.rst index 1ba2c0c6..001edff3 100644 --- a/doc/source/advanced_deployment/network_isolation.rst +++ b/doc/source/advanced_deployment/network_isolation.rst @@ -552,12 +552,12 @@ via the gateway at 172.17.0.1 on the Internal API network: Example:: - - type: vlan - device: bond1 - vlan_id: {get_param: InternalApiNetworkVlanID} - addresses: - - - ip_netmask: {get_param: InternalApiIpSubnet} + type: vlan + device: bond1 + vlan_id: {get_param: InternalApiNetworkVlanID} + addresses: + - + ip_netmask: {get_param: InternalApiIpSubnet} routes: - ip_netmask: 10.1.2.0/24 @@ -723,7 +723,7 @@ service will be bound to the host IP within the named network on each host. .. note:: The services will be assigned to the networks according to the - ``ServiceNetMap`` in ``overcloud-without-mergepy.yaml``. Unless these + ``ServiceNetMap`` in ``overcloud.yaml``. Unless these defaults need to be overridden, the ServiceNetMap does not need to be defined in the environment file. @@ -826,6 +826,7 @@ the TripleO Heat Templates, you will find that they have been updated with these parameters. If you have NIC configuration templates from an older version of TripleO Heat Templates, then you will need to add these parameters and modify the provisioning network to take advantage of static IP addresses. + Deploying the Overcloud With Network Isolation ---------------------------------------------- @@ -951,4 +952,3 @@ to a provider network if Neutron is to provide DHCP services to tenant VMs:: --allocation-pool start=10.9.101.50,end=10.9.101.100 \ --gateway 10.9.101.254 \ provider_network 10.9.101.0/24 - diff --git a/doc/source/advanced_deployment/node_config.rst b/doc/source/advanced_deployment/node_config.rst index 61390ae6..fd5bb915 100644 --- a/doc/source/advanced_deployment/node_config.rst +++ b/doc/source/advanced_deployment/node_config.rst @@ -4,7 +4,7 @@ Modifying default node configuration ==================================== Many service configurarion options are already exposed via parameters in the -top-level `overcloud-without-mergepy.yaml` template, and these options should +top-level `overcloud.yaml` template, and these options should be used wherever available to influence overcloud configuration. However in the event the service configuration required is not exposed @@ -27,7 +27,7 @@ value for compute nodes:: nova::compute::reserved_host_memory: some_value EOF - openstack overcloud deploy -e compute_params.yaml + openstack overcloud deploy -e compute_params.yaml The parameters available are: @@ -46,9 +46,9 @@ The parameters available are: .. note:: - If you set a configuration of a puppet class which is not being included - yet, make sure you include it in the ExtraConfig definition, for example - if you want to change CPU allocation ratio:: + If you set a configuration of a puppet class which is not being included + yet, make sure you include it in the ExtraConfig definition, for example + if you want to change CPU allocation ratio:: parameters: NovaComputeExtraConfig: diff --git a/doc/source/advanced_deployment/profile_matching.rst b/doc/source/advanced_deployment/profile_matching.rst index c7dad1c7..e91e8e38 100644 --- a/doc/source/advanced_deployment/profile_matching.rst +++ b/doc/source/advanced_deployment/profile_matching.rst @@ -137,11 +137,11 @@ using command:: openstack overcloud profiles list -If you've made a mistake in introspection rules, you can delete all them:: +If you've made a mistake in introspection rules, you can delete them all:: openstack baremetal introspection rule purge -Then reupload the updates rules file and restart introspection. +Then reupload the updated rules file and restart introspection. Use the flavors to deploy ------------------------- @@ -163,7 +163,7 @@ only control and compute profiles:: * If there are not enough such nodes, it then looks at available nodes with ``PROFILE_profile`` capabilities. If enough of such nodes is found, then - their ``profile`` capabilities are update to make the choice permanent. + their ``profile`` capabilities are updated to make the choice permanent. This command should exit without errors (and optionally without warnings). diff --git a/doc/source/basic_deployment/basic_deployment_cli.rst b/doc/source/basic_deployment/basic_deployment_cli.rst index 9e53df11..af148b8d 100644 --- a/doc/source/basic_deployment/basic_deployment_cli.rst +++ b/doc/source/basic_deployment/basic_deployment_cli.rst @@ -313,7 +313,7 @@ configured for the virtual environment. To customize this, see the output of:: of Ceph for Glance, Cinder, Nova or all of them. To do so, use the following arguments when deploying:: - --ceph-storage-scale --templates -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml + --ceph-storage-scale -e /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml By default when Ceph is enabled the Cinder LVM back-end is disabled. This behavior may be changed passing:: diff --git a/doc/source/contributions/contributions.rst b/doc/source/contributions/contributions.rst index 877a074c..952042ce 100644 --- a/doc/source/contributions/contributions.rst +++ b/doc/source/contributions/contributions.rst @@ -23,7 +23,7 @@ Contributing to this Documentation |project| User Documentation lives on Github under |project| organization. -Learn `how to contribute into |project| Docs +Learn `how to contribute into TripleO Docs `_. @@ -41,7 +41,7 @@ upstream projects, please follow OpenStack's process of filing bugs. in our list of :doc:`../introduction/components`. -**|project| If the bug impacts the |project| project as a whole, you can file a +**|project|** If the bug impacts the |project| project as a whole, you can file a bug in |bug_tracker|: #. Go to |bug_tracker_url| diff --git a/doc/source/environments/virtual.rst b/doc/source/environments/virtual.rst index 97df0603..1bd3ae34 100644 --- a/doc/source/environments/virtual.rst +++ b/doc/source/environments/virtual.rst @@ -102,7 +102,7 @@ Preparing the Virtual Environment (Automated) #. Make sure you are logged in as the non-root user you intend to use. - * Example commands to log in as the non-root user:: + * Example command to log in as the non-root user:: su - stack @@ -123,7 +123,7 @@ Preparing the Virtual Environment (Automated) #. The virt setup automatically sets up a vm for the Undercloud installed with the same base OS as the host. See the Note below to choose a different - OS.: + OS: .. note:: To setup the undercloud vm with a base OS different from the host, @@ -155,7 +155,7 @@ Preparing the Virtual Environment (Automated) export NODE_CPU=4 export NODE_MEM=16384 - Note the settings above only influence the VMs created for overcloud + Note the settings above only influence the VMs created for overcloud deployment. If you want to change the values for the undercloud node:: export UNDERCLOUD_NODE_CPU=4 diff --git a/doc/source/introduction/architecture.rst b/doc/source/introduction/architecture.rst index a6580202..bcdce7ac 100644 --- a/doc/source/introduction/architecture.rst +++ b/doc/source/introduction/architecture.rst @@ -318,15 +318,16 @@ and it will create a stack. Stack is Heat's own term for the applications that it creates. The overcloud, in Heat terms, is a particularly complex instance of a stack. -In order to the stack to be deployed, Heat makes successive calls to Nova, +In order for the stack to be deployed, Heat makes successive calls to Nova, OpenStack's compute service controller. Nova depends upon Ironic, which, as described above has acquired an inventory of introspected hardware by this stage in the process. -At this point, Nova flavors may act as a constraint, influencing the range of -machines which may be picked for deployment by the Nova scheduler. For each -request to deploy a new node with a specific role, Nova filters the of available -nodes, ensuring that the selected nodes meets the hardware requirements. +At this point, Nova flavors may act as a constraint, influencing the +range of machines which may be picked for deployment by the Nova +scheduler. For each request to deploy a new node with a specific role, +Nova filters the list of available nodes, ensuring that the selected +nodes meet the hardware requirements. Once the target node has been selected, Ironic does the actual provisioning of the node, Ironic retrieves the OS image associated with the role from Glance, diff --git a/doc/source/post_deployment/quiesce_compute.rst b/doc/source/post_deployment/quiesce_compute.rst index 1f17c8f3..a9b915a1 100644 --- a/doc/source/post_deployment/quiesce_compute.rst +++ b/doc/source/post_deployment/quiesce_compute.rst @@ -46,7 +46,7 @@ Initiating Migration First, obtain a list of the current Nova services:: - source ~stack/overcloudrc # admin credentials for the overcloud + source ~/overcloudrc # admin credentials for the overcloud nova service-list Disable the `nova-compute` service on the node you wish to quiesce, to prevent diff --git a/doc/source/post_deployment/replace_controller.rst b/doc/source/post_deployment/replace_controller.rst index f87b759c..aa7ef311 100644 --- a/doc/source/post_deployment/replace_controller.rst +++ b/doc/source/post_deployment/replace_controller.rst @@ -90,7 +90,7 @@ Replacing Bootstrap Node If node with index 0 is being replaced it's necessary to edit heat templates and change bootstrap node index before starting replacement. Open -`overcloud-without-mergepy.yaml` file in root directory of heat templates and +`overcloud.yaml` file in root directory of heat templates and change lines:: bootstrap_nodeid: {get_attr: [Controller, resource.0.hostname]}