diff --git a/doc/openstack-ops/locale/ja.po b/doc/openstack-ops/locale/ja.po
index a51d875f..ddef4076 100644
--- a/doc/openstack-ops/locale/ja.po
+++ b/doc/openstack-ops/locale/ja.po
@@ -36,11 +36,11 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2016-03-03 21:41+0000\n"
+"POT-Creation-Date: 2016-03-18 11:44+0000\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"PO-Revision-Date: 2016-03-07 04:44+0000\n"
+"PO-Revision-Date: 2016-03-18 10:30+0000\n"
 "Last-Translator: KATO Tomoyuki <kato.tomoyuki@jp.fujitsu.com>\n"
 "Language: ja\n"
 "Plural-Forms: nplurals=1; plural=0;\n"
@@ -5461,10 +5461,10 @@ msgstr ""
 "てください。"
 
 msgid "Ensuring Snapshots of Linux Guests Are Consistent"
-msgstr "Linux ゲストのスナップショットの一貫性の保証"
+msgstr "Linux ゲストのスナップショットの整合性の保証"
 
 msgid "Ensuring Snapshots of Windows Guests Are Consistent"
-msgstr "Windows ゲストのスナップショットの一貫性の保証"
+msgstr "Windows ゲストのスナップショットの整合性の保証"
 
 msgid "Ephemeral"
 msgstr "エフェメラル"
@@ -6414,7 +6414,7 @@ msgid ""
 "Hardware does not have to be consistent, but it should at least have the "
 "same type of CPU to support instance migration."
 msgstr ""
-"ハードウェアに一貫性を持たせる必要はありませんが、インスタンスのマイグレー"
+"ハードウェアに整合性を持たせる必要はありませんが、インスタンスのマイグレー"
 "ションをサポートできるように、最低限、CPU の種類は同じにする必要があります。"
 
 msgid ""
@@ -8532,7 +8532,7 @@ msgid ""
 "instance is running on Ubuntu, install the util-linux package to get "
 "<literal>fsfreeze</literal>:"
 msgstr ""
-"ファイルシステムが一貫性を持つことを保証するためには、単に <code>sync</code> "
+"ファイルシステムが整合性を持つことを保証するためには、単に <code>sync</code> "
 "を実行するだけでは不十分です。<code>fsfreeze</code> ツールを使用することを推"
 "奨します。これは、ファイルシステムに対する新規アクセスを停止し、スナップ"
 "ショットに適した安定したイメージをディスクに作成します。<code>fsfreeze</"
@@ -9872,8 +9872,8 @@ msgid ""
 "utilities to coordinate with a Windows-only subsystem designed to facilitate "
 "consistent backups."
 msgstr ""
-"Windows 仮想マシンの一貫性あるスナップショットの取得は、Linux マシンのスナッ"
-"プショットの場合と同じようなものです。ただし、一貫性バックアップを働かせるた"
+"Windows 仮想マシンの整合性あるスナップショットの取得は、Linux マシンのスナッ"
+"プショットの場合と同じようなものです。ただし、整合性バックアップを働かせるた"
 "めに、Windows 専用のサブコマンドと調整するための追加機能を必要とします。"
 
 msgid "Oct 12, 2012"
@@ -10414,7 +10414,7 @@ msgid ""
 msgstr ""
 "OpenStack Block Storage では、ボリュームのスナップショットを作成することもで"
 "きます。これはブロックレベルのスナップショットであることを覚えておいてくださ"
-"い。これはクラッシュに対する一貫性があります。そのため、スナップショットが取"
+"い。これはクラッシュに対する整合性があります。そのため、スナップショットが取"
 "得されるとき、ボリュームがインスタンスに接続されていないことが最良です。ボ"
 "リュームが接続されたインスタンスにおいて使用されていなければ、次に良いです。"
 "ボリュームが高負荷にある場合、スナップショットによりファイルシステムの不整合"
@@ -11135,7 +11135,7 @@ msgid "OpenStack.org case study"
 msgstr "OpenStack.org ケーススタディー"
 
 msgid "Operate with consistency groups"
-msgstr "一貫性グループの操作"
+msgstr "整合性グループの操作"
 
 msgid "Operating with a share"
 msgstr "共有の運用"
@@ -11290,7 +11290,7 @@ msgid ""
 "process to ensure a consistent state. For example, instances not fully "
 "purged from the system after deletion might cause indeterminate behavior."
 msgstr ""
-"確実に一貫性のある状態にするために、アップグレード作業を始める前にいくつか環"
+"確実に整合性のある状態にするために、アップグレード作業を始める前にいくつか環"
 "境のクリーンアップを実行します。例えば、削除後に完全削除されていないインスタ"
 "ンスにより、不確実な挙動を引き起こす可能性があります。"
 
@@ -11624,7 +11624,7 @@ msgid ""
 msgstr ""
 "QEMU は、KVM ハイパーバイザーにおいて動作しているゲストで実行できるゲストエー"
 "ジェントを提供しています。Windows 仮想マシンの場合、このゲストエージェント"
-"は、Windows VSS サービスと連携して、スナップショットの一貫性を保証する流れを"
+"は、Windows VSS サービスと連携して、スナップショットの整合性を保証する流れを"
 "楽にします。この機能は QEMU 1.7 以降を必要とします。関連するゲストエージェン"
 "トのコマンドは次のとおりです。"
 
@@ -12454,34 +12454,6 @@ msgstr "neutron コマンドを用いたセットアップ方法"
 msgid "Setting with nova command"
 msgstr "nova コマンドを用いたセットアップ方法"
 
-msgid ""
-"Several configuration-management tools are available, and this guide does "
-"not recommend a specific one. The two most popular ones in the OpenStack "
-"community are <link xlink:href=\"https://puppetlabs.com/\">Puppet</link>, "
-"with available <link xlink:href=\"https://github.com/puppetlabs/puppetlabs-"
-"openstack\">OpenStack Puppet modules</link>; and <link xlink:href=\"http://"
-"www.getchef.com/chef/\">Chef</link>, with available <link xlink:href="
-"\"https://github.com/opscode/openstack-chef-repo\">OpenStack Chef recipes</"
-"link>. Other newer configuration tools include <link xlink:href=\"https://"
-"juju.ubuntu.com/\">Juju</link>, <link xlink:href=\"http://www.ansible.com/"
-"home\">Ansible</link>, and <link xlink:href=\"http://www.saltstack.com/"
-"\">Salt</link>; and more mature configuration management tools include <link "
-"xlink:href=\"http://cfengine.com/\">CFEngine</link> and <link xlink:href="
-"\"http://bcfg2.org/\">Bcfg2</link>."
-msgstr ""
-"いくつかの構成管理ツールがあります。このガイドでは特定のものを推奨しません。"
-"OpenStack コミュニティで人気があるものは <link xlink:href=\"https://"
-"puppetlabs.com/\">Puppet</link> と <link xlink:href=\"http://www.getchef.com/"
-"chef/\">Chef</link> の 2 つで、OpenStack 用の設定集がそれぞれ <link xlink:"
-"href=\"https://github.com/puppetlabs/puppetlabs-openstack\">OpenStack Puppet "
-"modules</link> と <link xlink:href=\"https://github.com/opscode/openstack-"
-"chef-repo\">OpenStack Chef recipes</link> にあります。比較的新しい他のツール"
-"としては、<link xlink:href=\"https://juju.ubuntu.com/\">Juju</link>、<link "
-"xlink:href=\"http://www.ansible.com/home\">Ansible</link> や <link xlink:"
-"href=\"http://www.saltstack.com/\">Salt</link> があります。もう少し成熟した"
-"ツールとしては <link xlink:href=\"http://cfengine.com/\">CFEngine</link> や "
-"<link xlink:href=\"http://bcfg2.org/\">Bcfg2</link> があります。"
-
 msgid ""
 "Several minutes after <literal>nova-network</literal> is restarted, you "
 "should see new dnsmasq processes running:"
@@ -14855,7 +14827,7 @@ msgstr ""
 "性が高いため、ペタバイトレベルのストレージを管理するのに非常に適しています。"
 "OpenStack Object Storage の利点は OpenStack (OpenStack Identity と統合し、"
 "OpenStack Dashboard インターフェースと連携) と<phrase role=\"keep-together\">"
-"統合でき</phrase>、非同期のイベントを一貫性を保ちながら複製できるため、複数の"
+"統合でき</phrase>、非同期のイベントを整合性を保ちながら複製できるため、複数の"
 "データセンターのデプロイメントへのサポートも向上されています。"
 
 msgid ""
@@ -15099,9 +15071,9 @@ msgid ""
 "\"><primary>provisioning/deployment</primary><secondary>automated "
 "configuration</secondary></indexterm>"
 msgstr ""
-"自動環境設定管理の目的は、人間の介在なしにシステムの一貫性を確保、維持するこ"
+"自動環境設定管理の目的は、人間の介在なしにシステムの整合性を確保、維持するこ"
 "とにあります。毎回、同じクラウド環境を繰り返し作るために、デプロイメントにお"
-"ける一貫性を確保します。自動環境設定管理ツールを正しく利用することによって、"
+"ける整合性を確保します。自動環境設定管理ツールを正しく利用することによって、"
 "デプロイメントと環境設定の変更を伝搬する作業を簡素化するだけでなく、クラウド"
 "システムのコンポーネントが必ず特定の状態にあるようにすることができます。"
 "<indexterm class=\"singular\"><primary>自動設定</primary></"
@@ -15210,7 +15182,7 @@ msgstr ""
 "Compute 用の基盤となる最もシンプルなアーキテクチャーは、単一のクラウドコント"
 "ローラーと複数のコンピュートノードで構成されます。Object Storage 用の最もシン"
 "プルなアーキテクチャーは、ユーザーを識別して API への要求をプロキシするノー"
-"ド 1 つと、最終的な一貫性を確保するのに十分なレプリケーションを提供する、スト"
+"ド 1 つと、最終的な整合性を確保するのに十分なレプリケーションを提供する、スト"
 "レージ自体のためのノード 4つを合わせた 5 つのノードで構成されます。このアーキ"
 "テクチャーの例では、特定のノード数は決まっていませんが、このアーキテクチャー"
 "を選択するにあたって考慮 <phrase role=\"keep-together\">および検討した点</"
@@ -16856,7 +16828,7 @@ msgid ""
 "<indexterm class=\"endofrange\" startref=\"OSaspect\"/>"
 msgstr ""
 "OpenStack と通信するための効率的な SDK として、さまざまな python-*client コー"
-"ドを使用してとても成功していますが、プロジェクト間の一貫性とドキュメントの入"
+"ドを使用してとても成功していますが、プロジェクト間の整合性とドキュメントの入"
 "手可能性は満ち欠けがあります。これを取り除くために、<link xlink:href="
 "\"https://wiki.openstack.org/wiki/PythonOpenStackSDK\">エクスペリエンスを改善"
 "するための取り組み</link>が開始されました。OpenStack におけるクロスプロジェク"
@@ -19406,10 +19378,10 @@ msgid ""
 "to create a snapshot. Once the snapshot has been made, the VSS service "
 "unfreezes VSS writers and normal I/O activity resumes."
 msgstr ""
-"Windows XP 以降は、従順なアプリケーションが動作中のファイルシステムで一貫性の"
+"Windows XP 以降は、従順なアプリケーションが動作中のファイルシステムで整合性の"
 "あるバックアップを取得できるようにするフレームワークを提供する Volume Shadow "
 "Copy Service (VSS) が含まれます。このフレームワークを使用するために、VSS リク"
-"エスターが、一貫性バックアップを必要とすることを VSS サービスに対してシグナル"
+"エスターが、整合性バックアップを必要とすることを VSS サービスに対してシグナル"
 "を発行します。VSS サービスは、従順なアプリケーション (VSS ライターと言いま"
 "す) に通知して、これらのデータ処理を休止します。そして、VSS サービスがコピー"
 "プロバイダーにスナップショットを作成するよう指示します。スナップショットが作"
@@ -19681,23 +19653,6 @@ msgstr ""
 "\"singular\"><primary>Identity service</primary><secondary>サービスおよびエン"
 "ドポイントの表示</secondary></indexterm>"
 
-msgid ""
-"You can attach block storage to instances from the dashboard on the "
-"<guilabel>Volumes</guilabel> page. Click the <guibutton>Edit Attachments</"
-"guibutton> action next to the volume you want to attach.<indexterm class="
-"\"singular\"><primary>storage</primary><secondary>block storage</secondary></"
-"indexterm><indexterm class=\"singular\"><primary>block storage</primary></"
-"indexterm><indexterm class=\"singular\"><primary>user training</"
-"primary><secondary>block storage</secondary></indexterm>"
-msgstr ""
-"ダッシュボードの <guilabel>ボリューム</guilabel> ページから、インスタンスにブ"
-"ロックストレージを接続できます。接続したいボリュームの隣にある <guibutton>接"
-"続の編集</guibutton> をクリックします。<indexterm class=\"singular"
-"\"><primary>storage</primary><secondary>block storage</secondary></"
-"indexterm><indexterm class=\"singular\"><primary>block storage</primary></"
-"indexterm><indexterm class=\"singular\"><primary>user training</"
-"primary><secondary>block storage</secondary></indexterm>"
-
 msgid ""
 "You can configure some services, such as <code>nova-api</code> and "
 "<code>glance-api</code>, to use multiple processes by changing a flag in "
diff --git a/doc/openstack-ops/locale/openstack-ops.pot b/doc/openstack-ops/locale/openstack-ops.pot
index d38bb7d5..ed6aebcb 100644
--- a/doc/openstack-ops/locale/openstack-ops.pot
+++ b/doc/openstack-ops/locale/openstack-ops.pot
@@ -1,7 +1,7 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
-"POT-Creation-Date: 2016-03-07 06:36+0000\n"
+"POT-Creation-Date: 2016-03-19 06:33+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
@@ -253,7 +253,7 @@ msgstr ""
 msgid "OpenStack Identity - Clear any expired tokens before synchronizing the database."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_upgrades.xml:350(para)
+#: ./doc/openstack-ops/ch_ops_upgrades.xml:350(para) ./doc/openstack-ops/ch_ops_maintenance.xml:1369(title)
 msgid "OpenStack Image service"
 msgstr ""
 
@@ -1003,7 +1003,7 @@ msgstr ""
 
 #. When image changes, this message will be marked fuzzy or untranslated for you.
 #. It doesn't matter what you translate it to: it's not used at all.
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:856(None)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:860(None)
 msgid "@@image: 'http://git.openstack.org/cgit/openstack/operations-guide/plain/doc/openstack-ops/figures/osog_0902.png'; md5=THIS FILE DOESN'T EXIST"
 msgstr ""
 
@@ -1532,186 +1532,190 @@ msgid "Role"
 msgstr ""
 
 #: ./doc/openstack-ops/ch_ops_projects_users.xml:770(para)
+msgid "Enabled"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:774(para)
 msgid "Username and email address are self-explanatory, though your site may have local conventions you should observe. The primary project is simply the first project the user is associated with and must exist prior to creating the user. Role is almost always going to be \"member.\" Out of the box, OpenStack comes with two roles defined:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:781(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:785(term)
 msgid "member"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:784(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:788(para)
 msgid "A typical user"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:789(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:793(term)
 msgid "admin"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:792(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:796(para)
 msgid "An administrative super user, which has full permissions across all projects and should be used with great care"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:798(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:802(para)
 msgid "It is possible to define other roles, but doing so is uncommon."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:801(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:805(para)
 msgid "Once you've gathered this information, creating the user in the dashboard is just another web form similar to what we've seen before and can be found by clicking the Users link in the Identity navigation bar and then clicking the Create User button at the top right."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:806(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:810(para)
 msgid "Modifying users is also done from this Users page. If you have a large number of users, this page can get quite crowded. The Filter search box at the top of the page can be used to limit the users listing. A form very similar to the user creation dialog can be pulled up by selecting Edit from the actions dropdown menu at the end of the line for the user you are modifying."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:815(title)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:819(title)
 msgid "Associating Users with Projects"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:817(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:821(para)
 msgid "Many sites run with users being associated with only one project. This is a more conservative and simpler choice both for administration and for users. Administratively, if a user reports a problem with an instance or quota, it is obvious which project this relates to. Users needn't worry about what project they are acting in if they are only in one project. However, note that, by default, any user can affect the resources of any other user within their project. It is also possible to associate users with multiple projects if that makes sense for your organization.<indexterm class=\"singular\"><primary>Project Members tab</primary></indexterm><indexterm class=\"singular\"><primary>user management</primary><secondary>associating users with projects</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:833(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:837(para)
 msgid "Associating existing users with an additional project or removing them from an older project is done from the Projects page of the dashboard by selecting Modify Users from the Actions column, as shown in <xref linkend=\"horizon-edit-project\"/>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:838(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:842(para)
 msgid "From this view, you can do a number of useful things, as well as a few dangerous ones."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:841(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:845(para)
 msgid "The first column of this form, named All Users, includes a list of all the users in your cloud who are not already associated with this project. The second column shows all the users who are. These lists can be quite long, but they can be limited by typing a substring of the username you are looking for in the filter field at the top of the <phrase role=\"keep-together\">column</phrase>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:848(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:852(para)
 msgid "From here, click the <guiicon>+</guiicon> icon to add users to the project. Click the <guiicon>-</guiicon> to remove them."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:852(title)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:856(title)
 msgid "<guilabel>Edit Project Members</guilabel> tab"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:861(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:865(para)
 msgid "The dangerous possibility comes with the ability to change member roles. This is the dropdown list below the username in the <guilabel>Project Members</guilabel> list. In virtually all cases, this value should be set to Member. This example purposefully shows an administrative user where this value is admin."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:868(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:872(para)
 msgid "The admin is global, not per project, so granting a user the admin role in any project gives the user administrative rights across the whole cloud."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:873(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:877(para)
 msgid "Typical use is to only create administrative users in a single project, by convention the admin project, which is created by default during cloud setup. If your administrative users also use the cloud to launch and manage instances, it is strongly recommended that you use separate user accounts for administrative access and normal operations and that they be in distinct projects.<indexterm class=\"singular\"><primary>accounts</primary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:883(title)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:887(title)
 msgid "Customizing Authorization"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:885(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:889(para)
 msgid "The default <glossterm>authorization</glossterm> settings allow administrative users only to create resources on behalf of a different project. OpenStack handles two kinds of authorization <phrase role=\"keep-together\">policies</phrase>:<indexterm class=\"singular\"><primary>authorization</primary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:896(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:900(term)
 msgid "Operation based"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:899(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:903(para)
 msgid "Policies specify access criteria for specific operations, possibly with fine-grained control over specific attributes."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:906(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:910(term)
 msgid "Resource based"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:909(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:913(para)
 msgid "Whether access to a specific resource might be granted or not according to the permissions configured for the resource (currently available only for the network resource). The actual authorization policies enforced in an OpenStack service vary from deployment to deployment."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:918(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:922(para)
 msgid "The policy engine reads entries from the <code>policy.json</code> file. The actual location of this file might vary from distribution to distribution: for nova, it is typically in <code>/etc/nova/policy.json</code>. You can update entries while the system is running, and you do not have to restart services. Currently, the only way to update such policies is to edit the policy file."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:925(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:929(para)
 msgid "The OpenStack service's policy engine matches a policy directly. A rule indicates evaluation of the elements of such policies. For instance, in a <code>compute:create: [[\"rule:admin_or_owner\"]]</code> statement, the policy is <code>compute:create</code>, and the rule is <code>admin_or_owner</code>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:931(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:935(para)
 msgid "Policies are triggered by an OpenStack policy engine whenever one of them matches an OpenStack API operation or a specific attribute being used in a given operation. For instance, the engine tests the <code>create:compute</code> policy every time a user sends a <code>POST /v2/{tenant_id}/servers</code> request to the OpenStack Compute API server. Policies can be also related to specific <glossterm>API extension</glossterm>s. For instance, if a user needs an extension like <code>compute_extension:rescue</code>, the attributes defined by the provider extensions trigger the rule test for that operation."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:941(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:945(para)
 msgid "An authorization policy can be composed by one or more rules. If more rules are specified, evaluation policy is successful if any of the rules evaluates successfully; if an API operation matches multiple policies, then all the policies must evaluate successfully. Also, authorization rules are recursive. Once a rule is matched, the rule(s) can be resolved to another rule, until a terminal rule is reached. These are the rules <phrase role=\"keep-together\">defined</phrase>:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:951(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:955(term)
 msgid "Role-based rules"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:954(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:958(para)
 msgid "Evaluate successfully if the user submitting the request has the specified role. For instance, <code>\"role:admin\"</code> is successful if the user submitting the request is an administrator."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:962(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:966(term)
 msgid "Field-based rules"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:965(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:969(para)
 msgid "Evaluate successfully if a field of the resource specified in the current request matches a specific value. For instance, <code>\"field:networks:shared=True\"</code> is successful if the attribute shared of the network resource is set to <literal>true</literal>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:974(term)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:978(term)
 msgid "Generic rules"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:977(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:981(para)
 msgid "Compare an attribute in the resource with an attribute extracted from the user's security credentials and evaluates successfully if the comparison is successful. For instance, <code>\"tenant_id:%(tenant_id)s\"</code> is successful if the tenant identifier in the resource is equal to the tenant identifier of the user submitting the request."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:987(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:991(para)
 msgid "Here are snippets of the default nova <filename>policy.json</filename> file:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1017(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1021(para)
 msgid "Shows a rule that evaluates successfully if the current user is an administrator or the owner of the resource specified in the request (tenant identifier is equal)."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1023(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1027(para)
 msgid "Shows the default policy, which is always evaluated if an API operation does not match any of the policies in <code>policy.json</code>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1029(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1033(para)
 msgid "Shows a policy restricting the ability to manipulate flavors to administrators using the Admin API only.<indexterm class=\"singular\"><primary>admin API</primary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1037(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1041(para)
 msgid "In some cases, some operations should be restricted to administrators only. Therefore, as a further example, let us consider how this sample policy file could be modified in a scenario where we enable users to create their own flavors:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1046(title)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1050(title)
 msgid "Users Who Disrupt Other Users"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1048(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1052(para)
 msgid "Users on your cloud can disrupt other users, sometimes intentionally and maliciously and other times by accident. Understanding the situation allows you to make a better decision on how to handle the disruption.<indexterm class=\"singular\"><primary>user management</primary><secondary>handling disruptive users</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1057(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1061(para)
 msgid "For example, a group of users have instances that are utilizing a large amount of compute resources for very compute-intensive tasks. This is driving the load up on compute nodes and affecting other users. In this situation, review your user use cases. You may find that high compute scenarios are common, and should then plan for proper segregation in your cloud, such as host aggregation or regions."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1064(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1068(para)
 msgid "Another example is a user consuming a very large amount of bandwidth<indexterm class=\"singular\"><primary>bandwidth</primary><secondary>recognizing DDOS attacks</secondary></indexterm>. Again, the key is to understand what the user is doing. If she naturally needs a high amount of bandwidth, you might have to limit her transmission rate as to not affect other users or move her to an area with more bandwidth available. On the other hand, maybe her instance has been hacked and is part of a botnet launching DDOS attacks. Resolution of this issue is the same as though any other server on your network has been hacked. Contact the user and give her time to respond. If she doesn't respond, shut down the instance."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1078(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1082(para)
 msgid "A final example is if a user is hammering cloud resources repeatedly. Contact the user and learn what he is trying to do. Maybe he doesn't understand that what he's doing is inappropriate, or maybe there is an issue with the resource he is trying to access that is causing his requests to queue or lag."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1087(title) ./doc/openstack-ops/ch_ops_log_monitor.xml:1045(title) ./doc/openstack-ops/ch_ops_backup_recovery.xml:281(title) ./doc/openstack-ops/ch_ops_network_troubleshooting.xml:1289(title) ./doc/openstack-ops/ch_ops_lay_of_land.xml:789(title)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1091(title) ./doc/openstack-ops/ch_ops_log_monitor.xml:1045(title) ./doc/openstack-ops/ch_ops_backup_recovery.xml:281(title) ./doc/openstack-ops/ch_ops_network_troubleshooting.xml:1289(title) ./doc/openstack-ops/ch_ops_lay_of_land.xml:789(title)
 msgid "Summary"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_projects_users.xml:1089(para)
+#: ./doc/openstack-ops/ch_ops_projects_users.xml:1093(para)
 msgid "One key element of systems administration that is often overlooked is that end users are the reason systems administrators exist. Don't go the BOFH route and terminate every user who causes an alert to go off. Work with users to understand what they're trying to accomplish and see how your environment can better assist them in achieving their goals. Meet your users needs by organizing your users into projects, applying policies, managing quotas, and working with them.<indexterm class=\"singular\"><primary>systems administration</primary><see>user management</see></indexterm>"
 msgstr ""
 
@@ -5344,7 +5348,7 @@ msgid "Attaching Block Storage"
 msgstr ""
 
 #: ./doc/openstack-ops/ch_ops_user_facing.xml:2233(para)
-msgid "You can attach block storage to instances from the dashboard on the <guilabel>Volumes</guilabel> page. Click the <guibutton>Edit Attachments</guibutton> action next to the volume you want to attach.<indexterm class=\"singular\"><primary>storage</primary><secondary>block storage</secondary></indexterm><indexterm class=\"singular\"><primary>block storage</primary></indexterm><indexterm class=\"singular\"><primary>user training</primary><secondary>block storage</secondary></indexterm>"
+msgid "You can attach block storage to instances from the dashboard on the <guilabel>Volumes</guilabel> page. Click the <guibutton>Manage Attachments</guibutton> action next to the volume you want to attach.<indexterm class=\"singular\"><primary>storage</primary><secondary>block storage</secondary></indexterm><indexterm class=\"singular\"><primary>block storage</primary></indexterm><indexterm class=\"singular\"><primary>user training</primary><secondary>block storage</secondary></indexterm>"
 msgstr ""
 
 #: ./doc/openstack-ops/ch_ops_user_facing.xml:2248(para)
@@ -6823,7 +6827,7 @@ msgstr ""
 msgid "The Book of Xen"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_resources.xml:96(title) ./doc/openstack-ops/ch_ops_maintenance.xml:859(title)
+#: ./doc/openstack-ops/ch_ops_resources.xml:96(title) ./doc/openstack-ops/ch_ops_maintenance.xml:870(title)
 msgid "Configuration Management"
 msgstr ""
 
@@ -7115,7 +7119,7 @@ msgstr ""
 msgid "The cloud controller manages the following services for the cloud:<indexterm class=\"singular\"><primary>cloud controllers</primary><secondary>services managed by</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_arch_cloud_controller.xml:51(term) ./doc/openstack-ops/ch_ops_maintenance.xml:1003(title)
+#: ./doc/openstack-ops/ch_arch_cloud_controller.xml:51(term) ./doc/openstack-ops/ch_ops_maintenance.xml:1014(title)
 msgid "Databases"
 msgstr ""
 
@@ -9684,530 +9688,602 @@ msgid "Next, update the nova database to indicate that all instances that used t
 msgstr ""
 
 #: ./doc/openstack-ops/ch_ops_maintenance.xml:565(para)
+msgid "If you're using the Networking service ML2 plug-in, update the Networking service database to indicate that all ports that used to be hosted on c01.example.com are now hosted on c02.example.com:"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:576(para)
 msgid "After that, use the <literal>nova</literal> command to reboot all instances that were on c01.example.com while regenerating their XML files at the same time:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:571(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:582(para)
 msgid "Finally, reattach volumes using the same method described in the section <link linkend=\"volumes\">Volumes</link>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:578(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:589(title)
 msgid "/var/lib/nova/instances"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:580(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:591(para)
 msgid "It's worth mentioning this directory in the context of failed compute nodes. This directory contains the libvirt KVM file-based disk images for the instances that are hosted on that compute node. If you are not running your cloud in a shared storage environment, this directory is unique across all compute nodes.<indexterm class=\"singular\"><primary>/var/lib/nova/instances directory</primary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>/var/lib/nova/instances</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:592(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:603(para)
 msgid "<code>/var/lib/nova/instances</code> contains two types of directories."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:595(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:606(para)
 msgid "The first is the <code>_base</code> directory. This contains all the cached base images from glance for each unique image that has been launched on that compute node. Files ending in <code>_20</code> (or a different number) are the ephemeral base images."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:600(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:611(para)
 msgid "The other directories are titled <code>instance-xxxxxxxx</code>. These directories correspond to instances running on that compute node. The files inside are related to one of the files in the <code>_base</code> directory. They're essentially differential-based files containing only the changes made from the original <code>_base</code> directory."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:607(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:618(para)
 msgid "All files and directories in <code>/var/lib/nova/instances</code> are uniquely named. The files in _base are uniquely titled for the glance image that they are based on, and the directory names <code>instance-xxxxxxxx</code> are uniquely titled for that particular instance. For example, if you copy all data from <code>/var/lib/nova/instances</code> on one compute node to another, you do not overwrite any files or cause any damage to images that have the same unique name, because they are essentially the same file."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:616(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:627(para)
 msgid "Although this method is not documented or supported, you can use it when your compute node is permanently offline but you have instances locally stored on it."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:625(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:636(title)
 msgid "Storage Node Failures and Maintenance"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:627(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:638(para)
 msgid "Because of the high redundancy of Object Storage, dealing with object storage node issues is a lot easier than dealing with compute node issues."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:634(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:645(title)
 msgid "Rebooting a Storage Node"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:636(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:647(para)
 msgid "If a storage node requires a reboot, simply reboot it. Requests for data hosted on that node are redirected to other copies while the server is rebooting.<indexterm class=\"singular\"><primary>storage node</primary></indexterm><indexterm class=\"singular\"><primary>nodes</primary><secondary>storage nodes</secondary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>storage node reboot</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:654(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:665(title)
 msgid "Shutting Down a Storage Node"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:656(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:667(para)
 msgid "If you need to shut down a storage node for an extended period of time (one or more days), consider removing the node from the storage ring. For example:<indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>storage node shut down</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:671(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:682(para)
 msgid "Next, redistribute the ring files to the other nodes:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:678(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:689(para)
 msgid "These actions effectively take the storage node out of the storage cluster."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:681(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:692(para)
 msgid "When the node is able to rejoin the cluster, just add it back to the ring. The exact syntax you use to add a node to your swift cluster with <code>swift-ring-builder</code> heavily depends on the original options used when you originally created your cluster. Please refer back to those commands."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:691(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:702(title)
 msgid "Replacing a Swift Disk"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:693(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:704(para)
 msgid "If a hard drive fails in an Object Storage node, replacing it is relatively easy. This assumes that your Object Storage environment is configured correctly, where the data that is stored on the failed drive is also replicated to other drives in the Object Storage environment.<indexterm class=\"singular\"><primary>hard drives, replacing</primary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>swift disk replacement</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:705(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:716(para)
 msgid "This example assumes that <code>/dev/sdb</code> has failed."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:707(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:718(para)
 msgid "First, unmount the disk:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:711(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:722(para)
 msgid "Next, physically remove the disk from the server and replace it with a working disk."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:714(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:725(para)
 msgid "Ensure that the operating system has recognized the new disk:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:719(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:730(para)
 msgid "You should see a message about <code>/dev/sdb</code>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:721(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:732(para)
 msgid "Because it is recommended to not use partitions on a swift disk, simply format the disk as a whole:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:726(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:737(para)
 msgid "Finally, mount the disk:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:730(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:741(para)
 msgid "Swift should notice the new disk and that no data exists. It then begins replicating the data to the disk from the other existing replicas."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:739(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:750(title)
 msgid "Handling a Complete Failure"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:741(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:752(para)
 msgid "A common way of dealing with the recovery from a full system failure, such as a power outage of a data center, is to assign each service a priority, and restore in order. <xref linkend=\"restor-prior-table\"/> shows an example.<indexterm class=\"singular\"><primary>service restoration</primary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>complete failures</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:754(caption)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:765(caption)
 msgid "Example service restoration priority list"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:758(th)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:769(th)
 msgid "Priority"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:760(th)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:771(th)
 msgid "Services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:766(para) ./doc/openstack-ops/ch_arch_scaling.xml:94(para) ./doc/openstack-ops/ch_arch_scaling.xml:106(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:777(para) ./doc/openstack-ops/ch_arch_scaling.xml:94(para) ./doc/openstack-ops/ch_arch_scaling.xml:106(para)
 msgid "1"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:768(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:779(para)
 msgid "Internal network connectivity"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:772(para) ./doc/openstack-ops/ch_arch_scaling.xml:118(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:783(para) ./doc/openstack-ops/ch_arch_scaling.xml:118(para)
 msgid "2"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:774(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:785(para)
 msgid "Backing storage services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:778(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:789(para)
 msgid "3"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:780(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:791(para)
 msgid "Public network connectivity for user virtual machines"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:785(para) ./doc/openstack-ops/ch_arch_scaling.xml:130(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:796(para) ./doc/openstack-ops/ch_arch_scaling.xml:130(para)
 msgid "4"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:787(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:798(para)
 msgid "<literal>nova-compute</literal>, <literal>nova-network</literal>, cinder hosts"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:792(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:803(para)
 msgid "5"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:794(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:805(para)
 msgid "User virtual machines"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:798(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:809(para)
 msgid "10"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:800(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:811(para)
 msgid "Message queue and database services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:804(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:815(para)
 msgid "15"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:806(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:817(para)
 msgid "Keystone services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:810(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:821(para)
 msgid "20"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:812(literal)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:823(literal)
 msgid "cinder-scheduler"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:816(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:827(para)
 msgid "21"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:818(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:829(para)
 msgid "Image Catalog and Delivery services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:822(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:833(para)
 msgid "22"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:824(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:835(para)
 msgid "<literal>nova-scheduler</literal> services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:828(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:839(para)
 msgid "98"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:830(literal)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:841(literal)
 msgid "cinder-api"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:834(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:845(para)
 msgid "99"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:836(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:847(para)
 msgid "<literal>nova-api</literal> services"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:840(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:851(para)
 msgid "100"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:842(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:853(para)
 msgid "Dashboard node"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:847(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:858(para)
 msgid "Use this example priority list to ensure that user-affected services are restored as soon as possible, but not before a stable environment is in place. Of course, despite being listed as a single-line item, each step requires significant work. For example, just after starting the database, you should check its integrity, or, after starting the nova services, you should verify that the hypervisor matches the database and fix any <phrase role=\"keep-together\">mismatches</phrase>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:861(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:872(para)
 msgid "Maintaining an OpenStack cloud requires that you manage multiple physical servers, and this number might grow over time. Because managing nodes manually is error prone, we strongly recommend that you use a configuration-management tool. These tools automate the process of ensuring that all your nodes are configured properly and encourage you to maintain your configuration information (such as packages and configuration options) in a version-controlled repository.<indexterm class=\"singular\"><primary>configuration management</primary></indexterm><indexterm class=\"singular\"><primary>networks</primary><secondary>configuration management</secondary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>configuration management</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:881(para)
-msgid "Several configuration-management tools are available, and this guide does not recommend a specific one. The two most popular ones in the OpenStack community are <link xlink:href=\"https://puppetlabs.com/\">Puppet</link>, with available <link xlink:href=\"https://github.com/puppetlabs/puppetlabs-openstack\">OpenStack Puppet modules</link>; and <link xlink:href=\"http://www.getchef.com/chef/\">Chef</link>, with available <link xlink:href=\"https://github.com/opscode/openstack-chef-repo\">OpenStack Chef recipes</link>. Other newer configuration tools include <link xlink:href=\"https://juju.ubuntu.com/\">Juju</link>, <link xlink:href=\"http://www.ansible.com/home\">Ansible</link>, and <link xlink:href=\"http://www.saltstack.com/\">Salt</link>; and more mature configuration management tools include <link xlink:href=\"http://cfengine.com/\">CFEngine</link> and <link xlink:href=\"http://bcfg2.org/\">Bcfg2</link>."
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:892(para)
+msgid "Several configuration-management tools are available, and this guide does not recommend a specific one. The two most popular ones in the OpenStack community are <link xlink:href=\"https://puppetlabs.com/\">Puppet</link>, with available <link xlink:href=\"https://github.com/puppetlabs/puppetlabs-openstack\">OpenStack Puppet modules</link>; and <link xlink:href=\"http://www.getchef.com/chef/\">Chef</link>, with available <link xlink:href=\"https://github.com/opscode/openstack-chef-repo\">OpenStack Chef recipes</link>. Other newer configuration tools include <link xlink:href=\"https://juju.ubuntu.com/\">Juju</link>, <link xlink:href=\"https://www.ansible.com/\">Ansible</link>, and <link xlink:href=\"http://www.saltstack.com/\">Salt</link>; and more mature configuration management tools include <link xlink:href=\"http://cfengine.com/\">CFEngine</link> and <link xlink:href=\"http://bcfg2.org/\">Bcfg2</link>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:902(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:913(title)
 msgid "Working with Hardware"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:904(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:915(para)
 msgid "As for your initial deployment, you should ensure that all hardware is appropriately burned in before adding it to production. Run software that uses the hardware to its limits—maxing out RAM, CPU, disk, and network. Many options are available, and normally double as benchmark software, so you also get a good idea of the performance of your system.<indexterm class=\"singular\"><primary>hardware</primary><secondary>maintenance/debugging</secondary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>hardware</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:922(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:933(title)
 msgid "Adding a Compute Node"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:924(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:935(para)
 msgid "If you find that you have reached or are reaching the capacity limit of your computing resources, you should plan to add additional compute nodes. Adding more nodes is quite easy. The process for adding compute nodes is the same as when the initial compute nodes were deployed to your cloud: use an automated deployment system to bootstrap the bare-metal server with the operating system and then have a configuration-management system install and configure OpenStack Compute. Once the Compute service has been installed and configured in the same way as the other compute nodes, it automatically attaches itself to the cloud. The cloud controller notices the new node(s) and begins scheduling instances to launch there.<indexterm class=\"singular\"><primary>cloud controllers</primary><secondary>new compute nodes and</secondary></indexterm><indexterm class=\"singular\"><primary>nodes</primary><secondary>adding</secondary></indexterm><indexterm class=\"singular\"><primary>compute nodes</primary><secondary>adding</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:948(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:959(para)
 msgid "If your OpenStack Block Storage nodes are separate from your compute nodes, the same procedure still applies because the same queuing and polling system is used in both services."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:952(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:963(para)
 msgid "We recommend that you use the same hardware for new compute and block storage nodes. At the very least, ensure that the CPUs are similar in the compute nodes to not break live migration."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:960(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:971(title)
 msgid "Adding an Object Storage Node"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:962(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:973(para)
 msgid "Adding a new object storage node is different from adding compute or block storage nodes. You still want to initially configure the server by using your automated deployment and configuration-management systems. After that is done, you need to add the local disks of the object storage node into the object storage ring. The exact command to do this is the same command that was used to add the initial disks to the ring. Simply rerun this command on the object storage proxy server for all disks on the new object storage node. Once this has been done, rebalance the ring and copy the resulting ring files to the other storage nodes.<indexterm class=\"singular\"><primary>Object Storage</primary><secondary>adding nodes</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:978(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:989(para)
 msgid "If your new object storage node has a different number of disks than the original nodes have, the command to add the new node is different from the original commands. These parameters vary from environment to environment."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:988(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:999(title)
 msgid "Replacing Components"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:990(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1001(para)
 msgid "Failures of hardware are common in large-scale deployments such as an infrastructure cloud. Consider your processes and balance time saving against availability. For example, an Object Storage cluster can easily live with dead disks in it for some period of time if it has sufficient capacity. Or, if your compute installation is not full, you could consider live migrating instances off a host with a RAM failure until you have time to deal with the problem."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1005(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1016(para)
 msgid "Almost all OpenStack components have an underlying database to store persistent information. Usually this database is MySQL. Normal MySQL administration is applicable to these databases. OpenStack does not configure the databases out of the ordinary. Basic administration includes performance tweaking, high availability, backup, recovery, and repairing. For more information, see a standard MySQL administration guide.<indexterm class=\"singular\"><primary>databases</primary><secondary>maintenance/debugging</secondary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>databases</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1021(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1032(para)
 msgid "You can perform a couple of tricks with the database to either more quickly retrieve information or fix a data inconsistency error—for example, an instance was terminated, but the status was not updated in the database. These tricks are discussed throughout this book."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1029(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1040(title)
 msgid "Database Connectivity"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1031(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1042(para)
 msgid "Review the component's configuration file to see how each OpenStack component accesses its corresponding database. Look for either <code>sql_connection</code> or simply <code>connection</code>. The following command uses <code>grep</code> to display the SQL connection string for nova, glance, cinder, and keystone:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1037(emphasis)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1048(emphasis)
 msgid "grep -hE \"connection ?=\" /etc/nova/nova.conf /etc/glance/glance-*.conf /etc/cinder/cinder.conf /etc/keystone/keystone.conf"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1045(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1056(para)
 msgid "The connection strings take this format:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1053(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1064(title)
 msgid "Performance and Optimizing"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1055(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1066(para)
 msgid "As your cloud grows, MySQL is utilized more and more. If you suspect that MySQL might be becoming a bottleneck, you should start researching MySQL optimization. The MySQL manual has an entire section dedicated to this topic: <link xlink:href=\"http://dev.mysql.com/doc/refman/5.5/en/optimize-overview.html\">Optimization Overview</link>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1067(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1078(title)
 msgid "HDWMY"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1069(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1080(para)
 msgid "Here's a quick list of various to-do items for each hour, day, week, month, and year. Please note that these tasks are neither required nor definitive but helpful ideas:<indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>schedule of tasks</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1080(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1091(title)
 msgid "Hourly"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1084(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1095(para)
 msgid "Check your monitoring system for alerts and act on them."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1089(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1100(para)
 msgid "Check your ticket queue for new tickets."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1097(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1108(title)
 msgid "Daily"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1101(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1112(para)
 msgid "Check for instances in a failed or weird state and investigate why."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1106(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1117(para)
 msgid "Check for security patches and apply them as needed."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1114(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1125(title)
 msgid "Weekly"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1120(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1131(para)
 msgid "User quotas"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1124(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1135(para)
 msgid "Disk space"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1128(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1139(para)
 msgid "Image usage"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1132(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1143(para)
 msgid "Large instances"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1136(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1147(para)
 msgid "Network usage (bandwidth and IP usage)"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1118(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1129(para)
 msgid "Check cloud usage: <placeholder-1/>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1142(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1153(para)
 msgid "Verify your alert mechanisms are still working."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1150(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1161(title)
 msgid "Monthly"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1154(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1165(para)
 msgid "Check usage and trends over the past month."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1158(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1169(para)
 msgid "Check for user accounts that should be removed."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1162(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1173(para)
 msgid "Check for operator accounts that should be removed."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1170(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1181(title)
 msgid "Quarterly"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1174(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1185(para)
 msgid "Review usage and trends over the past quarter."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1178(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1189(para)
 msgid "Prepare any quarterly reports on usage and statistics."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1182(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1193(para)
 msgid "Review and plan any necessary cloud additions."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1186(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1197(para)
 msgid "Review and plan any major OpenStack upgrades."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1194(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1205(title)
 msgid "Semiannually"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1198(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1209(para)
 msgid "Upgrade OpenStack."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1202(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1213(para)
 msgid "Clean up after an OpenStack upgrade (any unused or new services to be aware of?)."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1212(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1223(title)
 msgid "Determining Which Component Is Broken"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1214(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1225(para)
 msgid "OpenStack's collection of different components interact with each other strongly. For example, uploading an image requires interaction from <code>nova-api</code>, <code>glance-api</code>, <code>glance-registry</code>, keystone, and potentially <code>swift-proxy</code>. As a result, it is sometimes difficult to determine exactly where problems lie. Assisting in this is the purpose of this section.<indexterm class=\"singular\"><primary>logging/monitoring</primary><secondary>tailing logs</secondary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>determining component affected</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1233(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1244(title)
 msgid "Tailing Logs"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1235(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1246(para)
 msgid "The first place to look is the log file related to the command you are trying to run. For example, if <code>nova list</code> is failing, try tailing a nova log file and running the command again:<indexterm class=\"singular\"><primary>tailing logs</primary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1242(para) ./doc/openstack-ops/ch_ops_maintenance.xml:1257(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1253(para) ./doc/openstack-ops/ch_ops_maintenance.xml:1268(para)
 msgid "Terminal 1:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1246(para) ./doc/openstack-ops/ch_ops_maintenance.xml:1261(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1257(para) ./doc/openstack-ops/ch_ops_maintenance.xml:1272(para)
 msgid "Terminal 2:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1250(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1261(para)
 msgid "Look for any errors or traces in the log file. For more information, see <xref linkend=\"logging_monitoring\"/>."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1253(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1264(para)
 msgid "If the error indicates that the problem is with another component, switch to tailing that component's log file. For example, if nova cannot access glance, look at the <literal>glance-api</literal> log:"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1265(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1276(para)
 msgid "Wash, rinse, and repeat until you find the core cause of the problem."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1272(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1283(title)
 msgid "Running Daemons on the CLI"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1274(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1285(para)
 msgid "Unfortunately, sometimes the error is not apparent from the log files. In this case, switch tactics and use a different command; maybe run the service directly on the command line. For example, if the <code>glance-api</code> service refuses to start and stay running, try launching the daemon from the command line:<indexterm class=\"singular\"><primary>daemons</primary><secondary>running on CLI</secondary></indexterm><indexterm class=\"singular\"><primary>Command-line interface (CLI)</primary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1289(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1300(para)
 msgid "The <literal>-H</literal> flag is required when running the daemons with sudo because some daemons will write files relative to the user's home directory, and this write may fail if <literal>-H</literal> is left off."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1288(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1299(para)
 msgid "This might print the error and cause of the problem.<placeholder-1/>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1296(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1307(title)
 msgid "Example of Complexity"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1298(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1309(para)
 msgid "One morning, a compute node failed to run any instances. The log files were a bit vague, claiming that a certain instance was unable to be started. This ended up being a red herring because the instance was simply the first instance in alphabetical order, so it was the first instance that <literal>nova-compute</literal> would touch."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1304(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1315(para)
 msgid "Further troubleshooting showed that libvirt was not running at all. This made more sense. If libvirt wasn't running, then no instance could be virtualized through KVM. Upon trying to start libvirt, it would silently die immediately. The libvirt logs did not explain why."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1310(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1321(para)
 msgid "Next, the <code>libvirtd</code> daemon was run on the command line. Finally a helpful error message: it could not connect to d-bus. As ridiculous as it sounds, libvirt, and thus <code>nova-compute</code>, relies on d-bus and somehow d-bus crashed. Simply starting d-bus set the entire chain back on track, and soon everything was back up and running."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1325(title)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1336(title)
+msgid "What to do when things are running slowly"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1338(para)
+msgid "When you are getting slow responses from various services, it can be hard to know where to start looking. The first thing to check is the extent of the slowness: is it specific to a single service, or varied among different services? If your problem is isolated to a specific service, it can temporarily be fixed by restarting the service, but that is often only a fix for the symptom and not the actual problem."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1347(para)
+msgid "This is a collection of ideas from experienced operators on common things to look at that may be the cause of slowness. It is not, however, designed to be an exhaustive list."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1355(title)
+msgid "OpenStack Identity service"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1356(para)
+msgid "If OpenStack Identity is responding slowly, it could be due to the token table getting large. This can be fixed by running the <placeholder-1/> command."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1361(para)
+msgid "Additionally, for Identity-related issues, try the tips in <xref linkend=\"runningslow_sql\"/>."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1370(para)
+msgid "OpenStack Image service can be slowed down by things related to the Identity service, but the Image service itself can be slowed down if connectivity to the back-end storage in use is slow or otherwise problematic. For example, your back-end NFS server might have gone down."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1381(title)
+msgid "OpenStack Block Storage service"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1382(para)
+msgid "OpenStack Block Storage service is similar to the Image service, so start by checking Identity-related services, and the back-end storage. Additionally, both the Block Storage and Image services rely on AMQP and SQL functionality, so consider these when debugging."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1392(title)
+msgid "OpenStack Compute service"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1393(para)
+msgid "Services related to OpenStack Compute are normally fairly fast and rely on a couple of backend services: Identity for authentication and authorization), and AMQP for interoperability. Any slowness related to services is normally related to one of these. Also, as with all other services, SQL is used extensively."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1404(title)
+msgid "OpenStack Networking service"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1405(para)
+msgid "Slowness in the OpenStack Networking service can be caused by services that it relies upon, but it can also be related to either physical or virtual networking. For example: network namespaces that do not exist or are not tied to interfaces correctly; DHCP daemons that have hung or are not running; a cable being physically disconnected; a switch not being configured correctly. When debugging Networking service problems, begin by verifying all physical networking functionality (switch configuration, physical cabling, etc.). After the physical networking is verified, check to be sure all of the Networking services are running (neutron-server, neutron-dhcp-agent, etc.), then check on AMQP and SQL back ends."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1422(title)
+msgid "AMQP broker"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1423(para)
+msgid "Regardless of which AMQP broker you use, such as RabbitMQ, there are common issues which not only slow down operations, but can also cause real problems. Sometimes messages queued for services stay on the queues and are not consumed. This can be due to dead or stagnant services and can be commonly cleared up by either restarting the AMQP-related services or the OpenStack service in question."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1435(title)
+msgid "SQL back end"
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1436(para)
+msgid "Whether you use SQLite or an RDBMS (such as MySQL), SQL interoperability is essential to a functioning OpenStack environment. A large or fragmented SQLite file can cause slowness when using files as a back end. A locked or long-running query can cause delays for most RDBMS services. In this case, do not kill the query immediately, but look into it to see if it is a problem with something that is hung, or something that is just taking a long time to run and needs to finish on its own. The administration of an RDBMS is outside the scope of this document, but it should be noted that a properly functioning RDBMS is essential to most OpenStack services."
+msgstr ""
+
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1457(title)
 msgid "Uninstalling"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1327(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1459(para)
 msgid "While we'd always recommend using your automated deployment system to reinstall systems from scratch, sometimes you do need to remove OpenStack from a system the hard way. Here's how:<indexterm class=\"singular\"><primary>uninstall operation</primary></indexterm><indexterm class=\"singular\"><primary>maintenance/debugging</primary><secondary>uninstalling</secondary></indexterm>"
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1340(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1472(para)
 msgid "Remove all packages."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1344(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1476(para)
 msgid "Remove remaining files."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1348(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1480(para)
 msgid "Remove databases."
 msgstr ""
 
-#: ./doc/openstack-ops/ch_ops_maintenance.xml:1352(para)
+#: ./doc/openstack-ops/ch_ops_maintenance.xml:1484(para)
 msgid "These steps depend on your underlying distribution, but in general you should be looking for \"purge\" commands in your package manager, like <literal>aptitude purge ~c $package</literal>. Following this, you can look for orphaned files in the directories referenced throughout this guide. To uninstall the database properly, refer to the manual appropriate for the product in use.<indexterm class=\"endofrange\" startref=\"maindebug\"/>"
 msgstr ""