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
This commit is contained in:
Andreas Jaeger
2014-01-13 20:03:05 +01:00
parent b9f0faaa3a
commit c961797ac0
13 changed files with 26 additions and 20 deletions

View File

@@ -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

View File

@@ -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
(ML2)</firstterm> plug-in that can concurrently use
multiple layer 2 networking technologies that are
the <firstterm baseform="Modular Layer 2 (ML2) neutron plug-in">
Modular Layer 2 (ML2) plug-in</firstterm> that can concurrently
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

View File

@@ -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>

View File

@@ -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"

View File

@@ -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

View File

@@ -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
<systemitem class="service"
are the <firstterm baseform="compute node">compute nodes</firstterm>
that run <systemitem class="service"
>nova-compute</systemitem>.</para>
</listitem>
<listitem>

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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

View File

@@ -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
groups</firstterm> by OpenStack, you can use
enforce firewall rules, called <firstterm
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

View File

@@ -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

View File

@@ -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