Sync glossary and firstterm

Ensure that for each firstterm, we have a proper entry in the glossary:
* Use <firstterm baseform="xxx"> if the first term is spelled differently
  than the glossary entry.
* Remove some firstterm markups where no entry is in the glossary
  and adding one not useful.

Change-Id: Id7093a53f9d466db774b548749116288425af581

doc/admin-guide-cloud/ch_compute.xml

@@ -549,7 +549,7 @@ End User Guide, and isn't required here. Comments welcome. LKB
                 xlink:href="http://docs.openstack.org/api/openstack-compute/2/content/"
                     ><citetitle>OpenStack Compute API v2 and Extensions
                     Reference</citetitle></link> documentation refers to
-            instances as <firstterm>servers</firstterm>.</para>
+            instances as <firstterm baseform="servers">servers</firstterm>.</para>
         <para>The <link linkend="instance-mgmt-novaclient">nova cli</link> can
             be made to show the API calls it is making by passing it the
                 <parameter>&ndash;&ndash;debug</parameter> parameter:</para>-->
@@ -1359,7 +1359,8 @@ echo 'Extra user data here'</computeroutput></screen>
                 <para>Every virtual instance is automatically assigned
                     a private IP address. You can optionally assign
                     public IP addresses to instances. The term
-                        <firstterm>floating IP</firstterm> refers to
+                    <firstterm baseform="floating IP address">floating
+                    IP</firstterm> refers to
                     an IP address, typically public, that you can
                     dynamically add to a running virtual instance.
                     OpenStack Compute uses Network Address Translation

doc/admin-guide-cloud/ch_networking.xml

@@ -226,9 +226,9 @@
                 options to decide on the right networking technology
                 for the deployment.</para>
             <para>In the Havana release, OpenStack Networking provides
-                the <firstterm>Modular Layer 2
+                the <firstterm baseform="Modular Layer 2 (ML2) neutron plug-in">
-                    (ML2)</firstterm> plug-in that can concurrently use
+                Modular Layer 2 (ML2) plug-in</firstterm> that can concurrently
-                multiple layer 2 networking technologies that are
+                use multiple layer 2 networking technologies that are
                 found in real-world data centers. It currently works
                 with the existing Open vSwitch, Linux Bridge, and
                 Hyper-v L2 agents. The ML2 framework simplifies the

doc/common/ch_using_openstack_overview.xml

@@ -16,7 +16,7 @@
         administrators.</para>
     <para audience="adminuser">As an OpenStack cloud administrative
         user, you can manage tenants, known as
-            <firstterm>projects</firstterm>, users, services, images,
+        <firstterm baseform="project">projects</firstterm>, users, services, images,
         flavors, and quotas.</para>
     <para>The examples in this guide show you how to complete these
         tasks with either:</para>

doc/common/section_cli_nova_userdata.xml

@@ -5,7 +5,8 @@
   xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
   xml:id="inserting_userdata">
   <title>Provide user data to instances</title>
-  <para><firstterm>User data</firstterm> is a special key in the
+  <para><firstterm baseform="user data">User data</firstterm> is a
+    special key in the
     metadata service that holds a file that cloud-aware applications
     in the guest instance can access. For example the <link
       xlink:href="https://help.ubuntu.com/community/CloudInit"

doc/common/section_trusted-compute-pools.xml

@@ -5,7 +5,7 @@
     xml:id="trusted-compute-pools">
     <title>Trusted compute pools</title>
     <para>Trusted compute pools enable administrators to designate a
-        group of compute hosts as <firstterm>trusted</firstterm>. These hosts use hardware-based
+        group of compute hosts as trusted. These hosts use hardware-based
         security features, such as the Intel Trusted Execution
         Technology (TXT), to provide an additional level of security.
         Combined with an external stand-alone web-based remote
@@ -144,7 +144,7 @@ auth_blob=i-am-openstack</programlisting>
     <section xml:id="trusted_flavors">
         <title>Specify trusted flavors</title>
         <para>You must configure one or more flavors as
-                <firstterm>trusted</firstterm>. Users can request
+                trusted. Users can request
             trusted nodes by specifying a trusted flavor when they
             boot an instance.</para>
         <para>Use the <command>nova flavor-key set</command> command

doc/config-reference/compute/section_compute-configure-migrations.xml

@@ -110,7 +110,8 @@
             <literal>HostC</literal>.</para>
       </listitem>
       <listitem>
-        <para><literal>HostA</literal> is the <firstterm>Cloud
+        <para><literal>HostA</literal> is the
+            <firstterm baseform="cloud controller">Cloud
             Controller</firstterm>, and should run these services:
             <systemitem class="service">nova-api</systemitem>,
             <systemitem class="service">nova-scheduler</systemitem>,
@@ -120,8 +121,8 @@
       </listitem>
       <listitem>
         <para><literal>HostB</literal> and <literal>HostC</literal>
-          are the <firstterm>compute nodes</firstterm> that run
+          are the <firstterm baseform="compute node">compute nodes</firstterm>
-            <systemitem class="service"
+          that run <systemitem class="service"
           >nova-compute</systemitem>.</para>
       </listitem>
       <listitem>

doc/config-reference/compute/section_hypervisor_vmware.xml

@@ -110,7 +110,7 @@
       <listitem>
         <para><emphasis role="bold">DRS</emphasis>. For any cluster
           that contains multiple ESX hosts, enable DRS and enable
-            <firstterm>fully automated</firstterm> placement.</para>
+          fully automated placement.</para>
       </listitem>
       <listitem>
         <para><emphasis role="bold">Shared storage</emphasis>. Only

doc/install-guide/section_cinder-controller.xml

@@ -5,7 +5,8 @@
   <title>Configure a Block Storage Service controller</title>
   <note>
      <para>This section describes how to configure OpenStack Block Storage
-         services on the <firstterm>Controller</firstterm> node and assumes that a
+         services on the <firstterm baseform="controller node">Controller node</firstterm>
+         and assumes that a
          second node provides storage through the <systemitem
           class="service">cinder-volume</systemitem> service. For
          instructions on how to configure the second node, see <xref

doc/install-guide/section_debconf-concepts.xml

@@ -66,7 +66,7 @@
         <literal>nova-common</literal>, and
         <literal>heat-common</literal> packages.</para>
     <para>In <systemitem class="library">debconf</systemitem>, the
-      higher the <firstterm>priority</firstterm> for a screen, the
+      higher the priority for a screen, the
       greater the chance that the user sees that screen. If a
         <systemitem class="library">debconf</systemitem> screen has
         <literal>medium</literal> priority and you configure the

doc/install-guide/section_debconf-preseeding.xml

@@ -4,7 +4,7 @@
   xmlns:xi="http://www.w3.org/2001/XInclude"
   xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
   <title>Pre-seed debconf prompts</title>
-  <para>You can <firstterm>pre-seed</firstterm> all <systemitem
+  <para>You can pre-seed all <systemitem
       class="library">debconf</systemitem> prompts. To pre-seed means
     to store responses in the <package>debconf</package> database so
     that <package>debconf</package> does not prompt the user for

doc/install-guide/section_neutron-install.xml

@@ -694,8 +694,9 @@ use_namespaces = True</programlisting>
           <!-- TODO(sross): support provider networks?  you need to modify things above for this to work -->
           <step>
             <para>Configure a firewall plug-in. If you do not wish to
-              enforce firewall rules, called <firstterm>security
+              enforce firewall rules, called <firstterm
-                groups</firstterm> by OpenStack, you can use
+              baseform="security group">security groups</firstterm>
+              by OpenStack, you can use
                 <literal>neutron.agent.firewall.NoopFirewall</literal>.
               Otherwise, you can choose one of the Networking firewall
               plug-ins. The most common choice is the Hybrid

doc/install-guide/section_neutron-provider-router-with-private_networks.xml

@@ -625,7 +625,8 @@ export OS_SERVICE_TOKEN=password</programlisting>
             that tenant. The router object in the API is created and
             owned by the cloud administrator.</para>
         <para>This model supports assigning public addresses to VMs by
-            using <firstterm>floating IPs</firstterm>; the router maps
+            using <firstterm baseform="floating IP">floating IPs</firstterm>;
+            the router maps
             public addresses from the external network to fixed IPs on
             private networks. Hosts without floating IPs can still
             create outbound connections to the external network

doc/user-guide-admin/section_dashboard_admin_manage_projects_security.xml

@@ -10,7 +10,7 @@
         to the instance. Group rules are project specific; project
         members can edit the default rules for their group and add new
         rule sets.</para>
-    <para>All projects have a <firstterm>default</firstterm> security
+    <para>All projects have a default security
         group that is applied to any instance that has no other
         defined security group. Unless you change the default, this
         security group denies all incoming traffic and allows only