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:
@@ -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>––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
|
||||
|
@@ -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
|
||||
|
@@ -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>
|
||||
|
@@ -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"
|
||||
|
@@ -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
|
||||
|
@@ -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>
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
Reference in New Issue
Block a user