Openstack -> OpenStack
Fix wrong capitalizations of OpenStack. Change-Id: Iab823200c0f4c4310f3693ea8bd4a6d9b5aa0cdc
This commit is contained in:
parent
6105d0bd28
commit
a317a8fff5
@ -1650,7 +1650,7 @@
|
||||
bridged transport connectors. These network types
|
||||
enable the attachment of large number of ports. To
|
||||
handle the increased scale, the NSX plug-in can
|
||||
back a single Openstack Network with a chain of
|
||||
back a single OpenStack Network with a chain of
|
||||
NSX logical switches. You can specify the maximum
|
||||
number of ports on each logical switch in this
|
||||
chain on the
|
||||
|
@ -519,7 +519,7 @@ allow_overlapping_ips = True</programlisting>
|
||||
</step>
|
||||
<step>
|
||||
<para>To configure the NSX controller cluster
|
||||
for the Openstack Networking Service,
|
||||
for the OpenStack Networking Service,
|
||||
locate the <literal>[default]</literal>
|
||||
section in the
|
||||
<filename>/etc/neutron/plugins/vmware/nsx.ini</filename>
|
||||
@ -558,7 +558,7 @@ nsx_controllers = <comma separated list of API endpoints></programlisting>
|
||||
API endpoints are specified, it is
|
||||
up to the user to ensure that all
|
||||
these endpoints belong to the same
|
||||
controller cluster. The Openstack
|
||||
controller cluster. The OpenStack
|
||||
Networking VMware NSX plug-in does
|
||||
not perform this check, and results
|
||||
might be unpredictable.</para>
|
||||
|
@ -68,7 +68,7 @@
|
||||
<para>While the NFS protocols standardize file access for
|
||||
users, they do not standardize administrative actions such
|
||||
as taking snapshots or replicating file systems. The
|
||||
Openstack Volume Drivers bring a common interface to these
|
||||
OpenStack Volume Drivers bring a common interface to these
|
||||
operations. The Nexenta NFS driver implements these
|
||||
standard actions using the ZFS management plane that
|
||||
already is deployed on NexentaStor appliances.</para>
|
||||
|
@ -4,7 +4,7 @@
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
|
||||
xml:id="section_block-storage-overview">
|
||||
<title>Introduction to the Block Storage Service</title>
|
||||
<para>The Openstack Block Storage Service provides persistent
|
||||
<para>The OpenStack Block Storage Service provides persistent
|
||||
block storage resources that OpenStack Compute instances can
|
||||
consume. This includes secondary attached storage similar to
|
||||
the Amazon Elastic Block Storage (EBS) offering. In addition,
|
||||
|
@ -367,7 +367,7 @@ flavor = keystone</programlisting>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Neutron</emphasis></para>
|
||||
<para>Neutron is an OpenStack project to provide “network connectivity as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).</para>
|
||||
<para>Neutron is an OpenStack project to provide “network connectivity as a service" between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., nova).</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Install Neutron Server and the OpenVSwitch package collection:</para>
|
||||
@ -683,7 +683,7 @@ rabbit_port = 5672</programlisting>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para><emphasis role="bold">Horizon</emphasis></para>
|
||||
<para>Horizon is the canonical implementation of Openstack’s Dashboard, which provides a web based user interface to OpenStack services including Nova, Swift, Keystone, etc.</para>
|
||||
<para>Horizon is the canonical implementation of OpenStack’s dashboard, which provides a web based user interface to OpenStack services including Nova, Swift, Keystone, etc.</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>To install Horizon, proceed like this</para>
|
||||
|
@ -101,7 +101,7 @@
|
||||
current state, with edge-triggered actions
|
||||
associated with target states. Provides
|
||||
user-oriented Monitoring-as-a-Service and a
|
||||
general purpose utility for Openstack.
|
||||
general purpose utility for OpenStack.
|
||||
Orchestration auto scaling is a typical use-case.
|
||||
Alarms follow a tristate model of
|
||||
<literal>ok</literal>,
|
||||
|
@ -21,7 +21,7 @@ keystone = ksclient.Client(auth_url=env['OS_AUTH_URL'],
|
||||
<programlisting language="python">import keystoneclient.v2_0.client as ksclient
|
||||
keystone = ksclient.Client(...)
|
||||
print keystone.auth_token</programlisting>
|
||||
<para>If the Openstack cloud is configured to use public-key
|
||||
<para>If the OpenStack cloud is configured to use public-key
|
||||
infrastructure (PKI) tokens, the Python script output looks
|
||||
something like this:</para>
|
||||
<screen><computeroutput>MIIQUQYJKoZIhvcNAQcCoIIQQjCCED4CAQExCTAHBgUrDgMCGjCCDqcGCSqGSIb3DQEHAaCCDpgE
|
||||
|
Loading…
Reference in New Issue
Block a user