Standardize usage of client arguments (common)
Like documented at https://wiki.openstack.org/wiki/Documentation/Conventions#Client_arguments:_.22--option_ARGUMENT.22 we prefer to use '--option ARGUMENT'. Change-Id: I4ea2c16a384726429d583d5eb6f03aeec3ca514c
This commit is contained in:
parent
304e8f39c2
commit
6feaaf116f
@ -34,8 +34,8 @@
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>Migrate a volume with the <command>cinder migrate</command> command, as shown in the following example:</para>
|
||||
<screen><prompt>$</prompt> <userinput>cinder migrate <replaceable>volumeID</replaceable> <replaceable>destinationHost</replaceable> --force-host-copy=<replaceable>True|False</replaceable></userinput></screen>
|
||||
<para>In this example, <literal>--force-host-copy=True</literal> forces the generic host-based migration mechanism and
|
||||
<screen><prompt>$</prompt> <userinput>cinder migrate <replaceable>volumeID</replaceable> <replaceable>destinationHost</replaceable> --force-host-copy <replaceable>True|False</replaceable></userinput></screen>
|
||||
<para>In this example, <literal>--force-host-copy True</literal> forces the generic host-based migration mechanism and
|
||||
bypasses any driver optimizations.</para>
|
||||
<note>
|
||||
<para>If the volume is in use or has snapshots, the specified host destination cannot accept the volume. If the user
|
||||
|
@ -101,10 +101,10 @@
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>After you restart the Image Service, you can use the following syntax to view the image's location information:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance --os-image-api-version=2 image-show <replaceable>imageID</replaceable></userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>glance --os-image-api-version 2 image-show <replaceable>imageID</replaceable></userinput></screen>
|
||||
<para>For example, using the image ID shown above, you would issue the command
|
||||
as follows:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance --os-image-api-version=2 image-show 2d9bb53f-70ea-4066-a68b-67960eaae673</userinput></screen></note>
|
||||
<screen><prompt>$</prompt> <userinput>glance --os-image-api-version 2 image-show 2d9bb53f-70ea-4066-a68b-67960eaae673</userinput></screen></note>
|
||||
</section>
|
||||
<section xml:id="glance_add_image">
|
||||
<title>Create or update an image (glance)</title>
|
||||
@ -264,8 +264,8 @@
|
||||
</informaltable>
|
||||
<para>The following example shows the command that you would use to upload a CentOS
|
||||
6.3 image in qcow2 format and configure it for public access:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance image-create --name centos63-image --disk-format=qcow2 \
|
||||
--container-format=bare --is-public=True --file=./centos63.qcow2</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>glance image-create --name centos63-image --disk-format qcow2 \
|
||||
--container-format bare --is-public True --file ./centos63.qcow2</userinput></screen>
|
||||
<para>The following example shows how to update an existing image with a properties
|
||||
that describe the disk bus, the CD-ROM bus, and the VIF model:</para>
|
||||
<screen><prompt>$</prompt> <userinput>glance image-update \
|
||||
|
@ -12,7 +12,7 @@
|
||||
pair, where you can make up the string for both the key and the
|
||||
value. For example, you could add a description and also the creator
|
||||
of the server.
|
||||
<screen><prompt>$</prompt> <userinput>nova boot --image=natty-image --flavor=2 smallimage2 --meta description='Small test image' --meta creator=joecool</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>nova boot --image natty-image --flavor 2 smallimage2 --meta description 'Small test image' --meta creator=joecool</userinput></screen>
|
||||
</para>
|
||||
<para>When viewing the server information, you can see the metadata
|
||||
included on the <literal>metadata</literal> line:
|
||||
|
@ -12,7 +12,7 @@
|
||||
human user. Has associated information such as user
|
||||
name, password, and email. This example creates a user
|
||||
named <literal>alice</literal>:</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-create --name=alice --pass=mypassword123 --email=alice@example.com</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-create --name alice --pass mypassword123 --email alice@example.com</userinput></screen>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><emphasis role="bold">Tenant</emphasis>. A project,
|
||||
@ -23,7 +23,7 @@
|
||||
instances in the tenant that you specified in your
|
||||
query. This example creates a tenant named
|
||||
<literal>acme</literal>:</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone tenant-create --name=acme</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone tenant-create --name acme</userinput></screen>
|
||||
<note>
|
||||
<para>Because the term <emphasis>project</emphasis>
|
||||
was used instead of <emphasis>tenant</emphasis> in
|
||||
@ -40,7 +40,7 @@
|
||||
operations that a user can perform in a given tenant.</para>
|
||||
<para>This example creates a role named
|
||||
<literal>compute-user</literal>:</para>
|
||||
<screen><prompt>$</prompt> <userinput>keystone role-create --name=compute-user</userinput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone role-create --name compute-user</userinput></screen>
|
||||
<note>
|
||||
<para>Individual services, such as Compute and the
|
||||
Image Service, assign meaning to roles. In the
|
||||
@ -71,7 +71,7 @@
|
||||
+--------+------+---------+
|
||||
| 6b8fd2 | acme | True |
|
||||
+--------+------+---------+</computeroutput></screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-role-add --user=892585 --role=9a764e --tenant-id=6b8fd2</userinput> </screen>
|
||||
<screen><prompt>$</prompt> <userinput>keystone user-role-add --user 892585 --role 9a764e --tenant-id 6b8fd2</userinput> </screen>
|
||||
<para>A user can have different roles in different tenants. For
|
||||
example, Alice might also have the <literal>admin</literal>
|
||||
role in the <literal>Cyberdyne</literal> tenant. A user can
|
||||
|
Loading…
Reference in New Issue
Block a user