From 8365bf6804c2699c8ec2fb8bdcc8383f5bfceef3 Mon Sep 17 00:00:00 2001 From: Chandan kumar Date: Mon, 25 Nov 2013 15:47:20 +0530 Subject: [PATCH] Applied Doc conventions in Admin-guide-cloud-2 Change-Id: Ia3c42cc8f851c0f50d8ff62710bc9c244be44e09 Partial-Bug: #1121866 --- .../section_multi_backend.xml | 10 +++++----- .../section_networking_adv_features.xml | 20 +++++++++---------- .../section_object-storage-monitoring.xml | 4 ++-- .../section_ts_cinder_config.xml | 14 ++++++------- 4 files changed, 24 insertions(+), 24 deletions(-) diff --git a/doc/admin-guide-cloud/section_multi_backend.xml b/doc/admin-guide-cloud/section_multi_backend.xml index 699cd5a4a9..be91ffac38 100644 --- a/doc/admin-guide-cloud/section_multi_backend.xml +++ b/doc/admin-guide-cloud/section_multi_backend.xml @@ -35,7 +35,7 @@ The options for a configuration group must be defined in the group (or default options are used). All the standard - Cinder configuration options + Block Storage configuration options (volume_group, volume_driver, and so on) might be used in a configuration group. Configuration values in the @@ -69,7 +69,7 @@ volume_backend_name=LVM_iSCSI_b lvmdriver-3 back-end. - Configure Cinder scheduler multi back-end + Configure Block Storage scheduler multi back-end You must enable the option to use multi back-end. Filter scheduler acts in two steps: @@ -100,7 +100,7 @@ volume_backend_name=LVM_iSCSI_b cinder.conf configuration file: scheduler_driver=cinder.scheduler.filter_scheduler.FilterScheduler - While the Cinder Scheduler defaults to + While the Block Storage Scheduler defaults to in Grizzly, this setting is not required. @@ -109,7 +109,7 @@ volume_backend_name=LVM_iSCSI_b Volume type Before using it, a volume type has to be declared to - Cinder. This can be done by the following command: + Block Storage. This can be done by the following command: $ cinder --os-username admin --os-tenant-name admin type-create lvm Then, an extra-specification have to be created to link the volume type to a back-end name. Run this @@ -133,7 +133,7 @@ volume_backend_name=LVM_iSCSI_b If a volume type points to a volume_backend_name that does - not exist in the Cinder configuration, the + not exist in the Block Storage configuration, the filter_scheduler returns an error that it cannot find a valid host with the suitable back-end. diff --git a/doc/admin-guide-cloud/section_networking_adv_features.xml b/doc/admin-guide-cloud/section_networking_adv_features.xml index bfd795fb98..82eaf6ac4f 100644 --- a/doc/admin-guide-cloud/section_networking_adv_features.xml +++ b/doc/admin-guide-cloud/section_networking_adv_features.xml @@ -1732,8 +1732,8 @@ router resources. The back-end is polled periodically, and the status for every resource is retrieved; then the - status in the Neutron database is updated only for - the resources for which a status change occurred. + status in the Networking database is updated only + for the resources for which a status change occurred. As operational status is now retrieved asynchronously, performance for GET operations is @@ -1848,11 +1848,11 @@ - When running multiple Neutron server instances, - the status synchronization task should not run on - every node; doing so sends unnecessary traffic to - the NVP back-end and performs unnecessary DB - operations. Set the + When running multiple OpenStack Networking server + instances, the status synchronization task should + not run on every node; doing so sends unnecessary + traffic to the NVP back-end and performs unnecessary + DB operations. Set the configuration option to a non-zero value exclusively on a node designated for back-end @@ -1960,9 +1960,9 @@ xml:id="section_bigswitch_routerrule_walkthrough"> Big Switch router rules operations Router rules are configured with a router - update operation in Neutron. The update - overrides any previous rules so all rules must - be provided at the same time. + update operation in OpenStack Networking. The + update overrides any previous rules so all + rules must be provided at the same time. Update a router with rules to permit traffic by default but block traffic from external networks to the 10.10.10.0/24 subnet: diff --git a/doc/admin-guide-cloud/section_object-storage-monitoring.xml b/doc/admin-guide-cloud/section_object-storage-monitoring.xml index 8f814d8976..8d703bf6e7 100644 --- a/doc/admin-guide-cloud/section_object-storage-monitoring.xml +++ b/doc/admin-guide-cloud/section_object-storage-monitoring.xml @@ -174,8 +174,8 @@ currently reports 124 metrics across 15 Object Storage daemons and the tempauth middleware. Details of the metrics tracked are in the Swift Administration Guide. + xlink:href="http://docs.openstack.org/developer/swift/admin_guide.html" + >Administrator's Guide. The sending of metrics is integrated with the logging framework. To enable, configure log_statsd_host in the relevant config diff --git a/doc/admin-guide-cloud/section_ts_cinder_config.xml b/doc/admin-guide-cloud/section_ts_cinder_config.xml index 852e6c385a..ee1f7e8606 100644 --- a/doc/admin-guide-cloud/section_ts_cinder_config.xml +++ b/doc/admin-guide-cloud/section_ts_cinder_config.xml @@ -8,7 +8,7 @@ configuration This section helps you solve some basic and common errors that you might encounter during setup and configuration of the - Cinder Block Storage Service. The focus here is on failed + Block Storage Service. The focus here is on failed creation of volumes. The most important thing to know is where to look in case of a failure. Two log files are especially helpful for solving volume @@ -20,7 +20,7 @@ issues. If you send a request to create a volume and it fails, review the cinder-api log to determine whether the request - made it to the Cinder service. If the request is logged + made it to the Block Storage service. If the request is logged and you see no errors or trace-backs, check the cinder-volume log for errors or trace-backs. @@ -106,15 +106,15 @@ Issues with state_path and volumes_dir settings. - Cinder uses tgtd as the default - iscsi helper and implements persistent targets. This - means that in the case of a tgt restart or even a node - reboot your existing volumes on that node will be + The OpenStack Block Storage uses tgtd + as the default iscsi helper and implements persistent targets. + This means that in the case of a tgt restart or even a + node reboot your existing volumes on that node will be restored automatically with their original IQN. In order to make this possible the iSCSI target information needs to be stored in a file on creation that can be queried in case of restart of the tgt - daemon. By default, Cinder uses a + daemon. By default, Block Storage uses a state_path variable, which if installing with Yum or APT should be set to /var/lib/cinder/. The next