Avoid really overlooooooooong lines in RST
We aim to have no lines longer than 79 characters, enable the line checking niceness check but set it to 100 as current maximum. Convert files that fail this line length. Convert one table to a definition list, convert two tables to use list-table directive. Change-Id: I8d0a95cc1c8e72965b3e0e69445e7b2bc6d77f0f
This commit is contained in:
parent
ca92d0caf4
commit
21d93118f0
@ -122,7 +122,8 @@ in a tenant.
|
|||||||
|
|
||||||
To restrict users from performing operations in, for example, the
|
To restrict users from performing operations in, for example, the
|
||||||
Compute service, you need to create a role in the Identity service and
|
Compute service, you need to create a role in the Identity service and
|
||||||
then modify the :file:`/etc/nova/policy.json` file so that this role is required for Compute operations.
|
then modify the :file:`/etc/nova/policy.json` file so that this role
|
||||||
|
is required for Compute operations.
|
||||||
|
|
||||||
For example, the following line in the :file:`/etc/nova/policy.json` file
|
For example, the following line in the :file:`/etc/nova/policy.json` file
|
||||||
specifies that there are no restrictions on which users can create volumes:
|
specifies that there are no restrictions on which users can create volumes:
|
||||||
@ -384,7 +385,8 @@ To start the services for Identity, run the following command:
|
|||||||
|
|
||||||
This command starts two wsgi.Server instances configured by the
|
This command starts two wsgi.Server instances configured by the
|
||||||
:file:`keystone.conf` file as described previously. One of these wsgi
|
:file:`keystone.conf` file as described previously. One of these wsgi
|
||||||
servers is :code:`admin` (the administration API) and the other is :code:`main` (the primary/public API interface). Both run in a single
|
servers is :code:`admin` (the administration API) and the other is
|
||||||
|
:code:`main` (the primary/public API interface). Both run in a single
|
||||||
process.
|
process.
|
||||||
|
|
||||||
Example usage
|
Example usage
|
||||||
|
@ -5,7 +5,8 @@ OpenStack Cloud Administrator Guide
|
|||||||
Abstract
|
Abstract
|
||||||
~~~~~~~~
|
~~~~~~~~
|
||||||
|
|
||||||
OpenStack offers open source software for cloud administrators to manage and troubleshoot an OpenStack cloud.
|
OpenStack offers open source software for cloud administrators to
|
||||||
|
manage and troubleshoot an OpenStack cloud.
|
||||||
|
|
||||||
This guide documents OpenStack Kilo, OpenStack Juno, and OpenStack
|
This guide documents OpenStack Kilo, OpenStack Juno, and OpenStack
|
||||||
Icehouse releases.
|
Icehouse releases.
|
||||||
|
@ -125,45 +125,71 @@ To update an image by name or ID, use ``glance image-update``:
|
|||||||
|
|
||||||
$ glance image-update imageName
|
$ glance image-update imageName
|
||||||
|
|
||||||
The following table lists the optional arguments that you can use with
|
The following list explains the optional arguments that you can use with
|
||||||
the ``create`` and ``update`` commands to modify image properties. For
|
the ``create`` and ``update`` commands to modify image properties. For
|
||||||
more information, refer to Image service chapter in the `OpenStack
|
more information, refer to Image service chapter in the `OpenStack
|
||||||
Command-Line Interface
|
Command-Line Interface
|
||||||
Reference <http://docs.openstack.org/cli-reference/content/index.html>`__.
|
Reference <http://docs.openstack.org/cli-reference/content/index.html>`__.
|
||||||
|
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
``--name NAME``
|
||||||
| ``--name NAME`` | The name of the image. |
|
The name of the image.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--disk-format DISK_FORMAT`` | The disk format of the image. Acceptable formats are ami, ari, aki, vhd, vmdk, raw, qcow2, vdi, and iso. |
|
``--disk-format DISK_FORMAT``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
The disk format of the image. Acceptable formats are ami, ari, aki,
|
||||||
| ``--container-format CONTAINER_FORMAT`` | The container format of the image. Acceptable formats are ami, ari, aki, bare, and ovf. |
|
vhd, vmdk, raw, qcow2, vdi, and iso.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--owner TENANT_ID`` | The tenant who should own the image. |
|
``--container-format CONTAINER_FORMAT``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
The container format of the image. Acceptable formats are ami, ari,
|
||||||
| ``--size SIZE`` | The size of image data, in bytes. |
|
aki, bare, and ovf.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--min-disk DISK_GB`` | The minimum size of the disk needed to boot the image, in gigabytes. |
|
``--owner TENANT_ID --size SIZE``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
The tenant who should own the image. The size of image data, in
|
||||||
| ``--min-ram DISK_RAM`` | The minimum amount of RAM needed to boot the image, in megabytes. |
|
bytes.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--location IMAGE_URL`` | The URL where the data for this image resides. For example, if the image data is stored in swift, you could specify ``swift://account:key@example.com/container/obj``. |
|
``--min-disk DISK_GB``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
The minimum size of the disk needed to boot the image, in
|
||||||
| ``--file FILE`` | Local file that contains the disk image to be uploaded during the update. Alternatively, you can pass images to the client through stdin. |
|
gigabytes.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--checksum CHECKSUM`` | Hash of image data to use for verification. |
|
``--min-ram DISK_RAM``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
The minimum amount of RAM needed to boot the image, in megabytes.
|
||||||
| ``--copy-from IMAGE_URL`` | Similar to ``--location`` in usage, but indicates that the image server should immediately copy the data and store it in its configured image store. |
|
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
``--location IMAGE_URL``
|
||||||
| ``--is-public [True|False]`` | Makes an image accessible for all the tenants (admin-only by default). |
|
The URL where the data for this image resides. For example, if the
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
image data is stored in swift, you could specify
|
||||||
| ``--is-protected [True|False]`` | Prevents an image from being deleted. |
|
``swift://account:key@example.com/container/obj``.
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
|
||||||
| ``--property KEY=VALUE`` | Arbitrary property to associate with image. This option can be used multiple times. |
|
``--file FILE``
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
Local file that contains the disk image to be uploaded during the
|
||||||
| ``--purge-props`` | Deletes all image properties that are not explicitly set in the update request. Otherwise, those properties not referenced are preserved. |
|
update. Alternatively, you can pass images to the client through
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
stdin.
|
||||||
| ``--human-readable`` | Prints the image size in a human-friendly format. |
|
|
||||||
+-------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
|
``--checksum CHECKSUM``
|
||||||
|
Hash of image data to use for verification.
|
||||||
|
|
||||||
|
``--copy-from IMAGE_URL``
|
||||||
|
Similar to ``--location`` in usage, but indicates that the image
|
||||||
|
server should immediately copy the data and store it in its
|
||||||
|
configured image store.
|
||||||
|
|
||||||
|
``--is-public [True|False]``
|
||||||
|
Makes an image accessible for all the tenants (admin-only by
|
||||||
|
default).
|
||||||
|
|
||||||
|
``--is-protected [True|False]``
|
||||||
|
Prevents an image from being deleted.
|
||||||
|
|
||||||
|
``--property KEY=VALUE``
|
||||||
|
Arbitrary property to associate with image. This option can be used
|
||||||
|
multiple times.
|
||||||
|
|
||||||
|
``--purge-props``
|
||||||
|
Deletes all image properties that are not explicitly set in the
|
||||||
|
update request. Otherwise, those properties not referenced are
|
||||||
|
preserved.
|
||||||
|
|
||||||
|
``--human-readable``
|
||||||
|
Prints the image size in a human-friendly format.
|
||||||
|
|
||||||
|
|
||||||
The following example shows the command that you would use to upload a
|
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:
|
CentOS 6.3 image in qcow2 format and configure it for public access:
|
||||||
@ -193,7 +219,8 @@ performance, libvirt defaults to using virtio for both disk and VIF
|
|||||||
possible to run operating systems that lack virtio drivers, for example,
|
possible to run operating systems that lack virtio drivers, for example,
|
||||||
BSD, Solaris, and older versions of Linux and Windows.
|
BSD, Solaris, and older versions of Linux and Windows.
|
||||||
|
|
||||||
If you specify a disk or CD-ROM bus model that is not supported, see the Disk_and_CD-ROM_bus_model_values_table_.
|
If you specify a disk or CD-ROM bus model that is not supported, see
|
||||||
|
the Disk_and_CD-ROM_bus_model_values_table_.
|
||||||
If you specify a VIF model that is not supported, the instance fails to
|
If you specify a VIF model that is not supported, the instance fails to
|
||||||
launch. See the VIF_model_values_table_.
|
launch. See the VIF_model_values_table_.
|
||||||
|
|
||||||
|
@ -34,9 +34,11 @@ Logo and site colors
|
|||||||
- Login screen: 365 x 50
|
- Login screen: 365 x 50
|
||||||
- Logged in banner: 216 x 35
|
- Logged in banner: 216 x 35
|
||||||
|
|
||||||
#. Upload your new images to :file:`/usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/img/`.
|
#. Upload your new images to
|
||||||
|
:file:`/usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/img/`.
|
||||||
|
|
||||||
#. Create a CSS style sheet in :file:`/usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/css/`.
|
#. Create a CSS style sheet in
|
||||||
|
:file:`/usr/share/openstack-dashboard/openstack_dashboard/static/dashboard/css/`.
|
||||||
|
|
||||||
#. Change the colors and image file names as appropriate, though the
|
#. Change the colors and image file names as appropriate, though the
|
||||||
relative directory paths should be the same. The following example file
|
relative directory paths should be the same. The following example file
|
||||||
|
@ -145,15 +145,17 @@ There are two syntaxes for expressing a netmask:
|
|||||||
* dotted quad
|
* dotted quad
|
||||||
* classless inter-domain routing (CIDR)
|
* classless inter-domain routing (CIDR)
|
||||||
|
|
||||||
Consider an IP address of 192.168.1.5, where the first 24 bits of the address
|
Consider an IP address of 192.168.1.5, where the first 24 bits of the
|
||||||
are the network number. In dotted quad notation, the netmask would be written as
|
address are the network number. In dotted quad notation, the netmask
|
||||||
``255.255.255.0``. CIDR notation includes both the IP address and netmask,
|
would be written as ``255.255.255.0``. CIDR notation includes both the
|
||||||
and this example would be written as ``192.168.1.5/24``.
|
IP address and netmask, and this example would be written as
|
||||||
|
``192.168.1.5/24``.
|
||||||
|
|
||||||
Sometimes we want to refer to a subnet, but not any particular IP address on
|
Sometimes we want to refer to a subnet, but not any particular IP
|
||||||
the subnet. A common convention is to set the host identifier to all zeros to make
|
address on the subnet. A common convention is to set the host
|
||||||
reference to a subnet. For example, if a host's IP address is ``10.10.53.24/16``, then
|
identifier to all zeros to make reference to a subnet. For example, if
|
||||||
we would say the subnet is ``10.10.0.0/16``.
|
a host's IP address is ``10.10.53.24/16``, then we would say the
|
||||||
|
subnet is ``10.10.0.0/16``.
|
||||||
|
|
||||||
To understand how ARP translates IP addresses to MAC addresses, consider the
|
To understand how ARP translates IP addresses to MAC addresses, consider the
|
||||||
following example. Assume host *A* has an IP address of ``192.168.1.5/24`` and a
|
following example. Assume host *A* has an IP address of ``192.168.1.5/24`` and a
|
||||||
@ -161,15 +163,18 @@ MAC address of ``fc:99:47:49:d4:a0``, and wants to send a packet to host *B*
|
|||||||
with an IP address of ``192.168.1.7``. Note that the network number is the same
|
with an IP address of ``192.168.1.7``. Note that the network number is the same
|
||||||
for both hosts, so host *A* is able to send frames directly to host *B*.
|
for both hosts, so host *A* is able to send frames directly to host *B*.
|
||||||
|
|
||||||
The first time host *A* attempts to communicate with host *B*, the destination MAC
|
The first time host *A* attempts to communicate with host *B*, the
|
||||||
address is not known. Host *A* makes an ARP request to the local network.
|
destination MAC address is not known. Host *A* makes an ARP request to
|
||||||
The request is a broadcast with a message like this:
|
the local network. The request is a broadcast with a message like
|
||||||
|
this:
|
||||||
|
|
||||||
*To: everybody (ff:ff:ff:ff:ff:ff). I am looking for the computer who has IP address 192.168.1.7. Signed: MAC address fc:99:47:49:d4:a0*.
|
*To: everybody (ff:ff:ff:ff:ff:ff). I am looking for the computer who
|
||||||
|
has IP address 192.168.1.7. Signed: MAC address fc:99:47:49:d4:a0*.
|
||||||
|
|
||||||
Host *B* responds with a response like this:
|
Host *B* responds with a response like this:
|
||||||
|
|
||||||
*To: fc:99:47:49:d4:a0. I have IP address 192.168.1.7. Signed: MAC address 54:78:1a:86:00:a5.*
|
*To: fc:99:47:49:d4:a0. I have IP address 192.168.1.7. Signed: MAC
|
||||||
|
address 54:78:1a:86:00:a5.*
|
||||||
|
|
||||||
Host *A* then sends Ethernet frames to host *B*.
|
Host *A* then sends Ethernet frames to host *B*.
|
||||||
|
|
||||||
@ -198,9 +203,10 @@ you can view the contents of the ARP cache by using the *arp* command::
|
|||||||
DHCP
|
DHCP
|
||||||
~~~~
|
~~~~
|
||||||
|
|
||||||
Hosts connected to a network use the Dynamic Host Configuration Protocol (:term:`DHCP`)
|
Hosts connected to a network use the Dynamic Host Configuration
|
||||||
to dynamically obtain IP addresses. A DHCP server hands out the IP addresses to
|
Protocol (:term:`DHCP`) to dynamically obtain IP addresses. A DHCP
|
||||||
network hosts, which are the DHCP clients.
|
server hands out the IP addresses to network hosts, which are the DHCP
|
||||||
|
clients.
|
||||||
|
|
||||||
DHCP clients locate the DHCP server by sending a UDP_ packet from port 68 to
|
DHCP clients locate the DHCP server by sending a UDP_ packet from port 68 to
|
||||||
address ``255.255.255.255`` on port 67. Address ``255.255.255.255`` is the local
|
address ``255.255.255.255`` on port 67. Address ``255.255.255.255`` is the local
|
||||||
@ -211,15 +217,20 @@ as the client, or the server will not receive the broadcast. The DHCP server
|
|||||||
responds by sending a UDP packet from port 67 to port 68 on the client. The
|
responds by sending a UDP packet from port 67 to port 68 on the client. The
|
||||||
exchange looks like this:
|
exchange looks like this:
|
||||||
|
|
||||||
1. The client sends a discover ("I’m a client at MAC address ``08:00:27:b9:88:74``, I need an IP address")
|
1. The client sends a discover ("I’m a client at MAC address
|
||||||
2. The server sends an offer ("OK ``08:00:27:b9:88:74``, I’m offering IP address ``10.10.0.112``")
|
``08:00:27:b9:88:74``, I need an IP address")
|
||||||
3. The client sends a request ("Server ``10.10.0.131``, I would like to have IP ``10.10.0.112``")
|
2. The server sends an offer ("OK ``08:00:27:b9:88:74``, I’m offering
|
||||||
4. The server sends an acknowledgement ("OK ``08:00:27:b9:88:74``, IP ``10.10.0.112`` is yours")
|
IP address ``10.10.0.112``")
|
||||||
|
3. The client sends a request ("Server ``10.10.0.131``, I would like
|
||||||
|
to have IP ``10.10.0.112``")
|
||||||
|
4. The server sends an acknowledgement ("OK ``08:00:27:b9:88:74``, IP
|
||||||
|
``10.10.0.112`` is yours")
|
||||||
|
|
||||||
|
|
||||||
OpenStack uses a third-party program called dnsmasq_ to implement the DHCP server.
|
OpenStack uses a third-party program called dnsmasq_ to implement the
|
||||||
Dnsmasq writes to the syslog (normally found at /var/log/syslog), where you can observe the DHCP
|
DHCP server.
|
||||||
request and replies::
|
Dnsmasq writes to the syslog (normally found at /var/log/syslog),
|
||||||
|
where you can observe the DHCP request and replies::
|
||||||
|
|
||||||
Apr 23 15:53:46 c100-1 dhcpd: DHCPDISCOVER from 08:00:27:b9:88:74 via eth2
|
Apr 23 15:53:46 c100-1 dhcpd: DHCPDISCOVER from 08:00:27:b9:88:74 via eth2
|
||||||
Apr 23 15:53:46 c100-1 dhcpd: DHCPOFFER on 10.10.0.112 to 08:00:27:b9:88:74 via eth2
|
Apr 23 15:53:46 c100-1 dhcpd: DHCPOFFER on 10.10.0.112 to 08:00:27:b9:88:74 via eth2
|
||||||
|
@ -68,14 +68,19 @@ Routing services
|
|||||||
VPNaaS
|
VPNaaS
|
||||||
------
|
------
|
||||||
|
|
||||||
The Virtual Private Network as a Service (VPNaaS) is a neutron extension that introduces the VPN feature set.
|
The Virtual Private Network as a Service (VPNaaS) is a neutron
|
||||||
|
extension that introduces the VPN feature set.
|
||||||
|
|
||||||
LbaaS
|
LbaaS
|
||||||
-----
|
-----
|
||||||
|
|
||||||
The Load-Balancer-as-a-Service (LBaaS) API provisions and configures load balancers. The reference implementation is based on the HAProxy software load balancer.
|
The Load-Balancer-as-a-Service (LBaaS) API provisions and configures
|
||||||
|
load balancers. The reference implementation is based on the HAProxy
|
||||||
|
software load balancer.
|
||||||
|
|
||||||
FwaaS
|
FwaaS
|
||||||
-----
|
-----
|
||||||
|
|
||||||
The Firewall-as-a-Service (FWaaS) API is an experimental API that enables early adopters and vendors to test their networking implementations.
|
The Firewall-as-a-Service (FWaaS) API is an experimental API that
|
||||||
|
enables early adopters and vendors to test their networking
|
||||||
|
implementations.
|
||||||
|
@ -9,12 +9,14 @@ tenant user, as well as update the quota defaults for a new tenant.
|
|||||||
|
|
||||||
**Compute quota descriptions**
|
**Compute quota descriptions**
|
||||||
|
|
||||||
=============================== ===================================================================
|
=============================== ========================================================
|
||||||
Quota name Description
|
Quota name Description
|
||||||
=============================== ===================================================================
|
=============================== ========================================================
|
||||||
cores Number of instance cores (VCPUs) allowed per tenant.
|
cores Number of instance cores (VCPUs)
|
||||||
fixed-ips Number of fixed IP addresses allowed per tenant. This number must
|
allowed per tenant.
|
||||||
be equal to or greater than the number of allowed instances.
|
fixed-ips Number of fixed IP addresses allowed per tenant.
|
||||||
|
This number must be equal to or
|
||||||
|
greater than the number of allowed instances.
|
||||||
floating-ips Number of floating IP addresses allowed per tenant.
|
floating-ips Number of floating IP addresses allowed per tenant.
|
||||||
injected-file-content-bytes Number of content bytes allowed per injected file.
|
injected-file-content-bytes Number of content bytes allowed per injected file.
|
||||||
injected-file-path-bytes Length of injected file path.
|
injected-file-path-bytes Length of injected file path.
|
||||||
@ -25,7 +27,7 @@ tenant user, as well as update the quota defaults for a new tenant.
|
|||||||
ram Megabytes of instance ram allowed per tenant.
|
ram Megabytes of instance ram allowed per tenant.
|
||||||
security-groups Number of security groups per tenant.
|
security-groups Number of security groups per tenant.
|
||||||
security-group-rules Number of rules per security group.
|
security-group-rules Number of rules per security group.
|
||||||
=============================== ===================================================================
|
=============================== ========================================================
|
||||||
|
|
||||||
View and update Compute quotas for a tenant (project)
|
View and update Compute quotas for a tenant (project)
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -39,7 +39,8 @@ Create an encrypted volume type
|
|||||||
#. Click :guilabel:`Create Encryption` in the Actions column of the newly
|
#. Click :guilabel:`Create Encryption` in the Actions column of the newly
|
||||||
created volume type.
|
created volume type.
|
||||||
|
|
||||||
#. Configure the encrypted volume by setting the parameters below from available options (see table):
|
#. Configure the encrypted volume by setting the parameters below from
|
||||||
|
available options (see table):
|
||||||
|
|
||||||
Provider
|
Provider
|
||||||
Specifies the class responsible for configuring the encryption.
|
Specifies the class responsible for configuring the encryption.
|
||||||
|
@ -122,8 +122,9 @@ Update a stack
|
|||||||
To update an existing stack from a modified template file, run a command
|
To update an existing stack from a modified template file, run a command
|
||||||
like the following command::
|
like the following command::
|
||||||
|
|
||||||
$ heat stack-update mystack --template-file /path/to/heat/templates/WordPress_Single_Instance_v2.template
|
$ heat stack-update mystack --template-file \
|
||||||
--parameters "InstanceType=m1.large;DBUsername=wp;DBPassword=verybadpassword;KeyName=heat_key;LinuxDistribution=F17"
|
/path/to/heat/templates/WordPress_Single_Instance_v2.template \
|
||||||
|
--parameters "InstanceType=m1.large;DBUsername=wp;DBPassword=verybadpassword;KeyName=heat_key;LinuxDistribution=F17"
|
||||||
+--------------------------------------+---------------+-----------------+----------------------+
|
+--------------------------------------+---------------+-----------------+----------------------+
|
||||||
| id | stack_name | stack_status | creation_time |
|
| id | stack_name | stack_status | creation_time |
|
||||||
+--------------------------------------+---------------+-----------------+----------------------+
|
+--------------------------------------+---------------+-----------------+----------------------+
|
||||||
|
@ -54,9 +54,11 @@ run::
|
|||||||
| 172.24.4.226 | None | None | public |
|
| 172.24.4.226 | None | None | public |
|
||||||
+--------------+--------------------------------------+----------+--------+
|
+--------------+--------------------------------------+----------+--------+
|
||||||
|
|
||||||
For each floating IP address that is allocated to the current project, the
|
For each floating IP address that is allocated to the current project,
|
||||||
command outputs the floating IP address, the ID for the instance to which
|
the command outputs the floating IP address, the ID for the instance
|
||||||
the floating IP address is assigned, the associated fixed IP address, and the pool from which the floating IP address was allocated.
|
to which the floating IP address is assigned, the associated fixed IP
|
||||||
|
address, and the pool from which the floating IP address was
|
||||||
|
allocated.
|
||||||
|
|
||||||
Associate floating IP addresses
|
Associate floating IP addresses
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
@ -118,8 +118,9 @@ Create and manage security groups
|
|||||||
Create and manage security group rules
|
Create and manage security group rules
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Modify security group rules with the :command:`nova secgroup-*-rule` commands.
|
Modify security group rules with the :command:`nova secgroup-*-rule`
|
||||||
Before you begin, source the OpenStack RC file. For details, see :doc:`../common/cli_set_environment_variables_using_openstack_rc`.
|
commands. Before you begin, source the OpenStack RC file. For details,
|
||||||
|
see :doc:`../common/cli_set_environment_variables_using_openstack_rc`.
|
||||||
|
|
||||||
#. To list the rules for a security group, run the following command::
|
#. To list the rules for a security group, run the following command::
|
||||||
|
|
||||||
|
@ -7,19 +7,33 @@ You can boot instances from a volume instead of an image.
|
|||||||
To complete these tasks, use these parameters on the nova :command:`boot`
|
To complete these tasks, use these parameters on the nova :command:`boot`
|
||||||
command:
|
command:
|
||||||
|
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
.. list-table::
|
||||||
| Task | nova boot parameter | Information |
|
:header-rows: 1
|
||||||
+========================================================================+=======================+===================================================================+
|
:widths: 30 10 30
|
||||||
| Boot an instance from an image and attach a non-bootable volume. | ``--block-device`` | :ref:`Boot_instance_from_image_and_attach_non-bootable_volume` |
|
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
* - Task
|
||||||
| Create a volume from an image and boot an instance from that volume. | ``--block-device`` | :ref:`Create_volume_from_image_and_boot_instance` |
|
- nova boot parameter
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
- Information
|
||||||
| Boot from an existing source image, volume, or snapshot. | ``--block-device`` | :ref:`Create_volume_from_image_and_boot_instance` |
|
* - Boot an instance from an image and attach a non-bootable
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
volume.
|
||||||
| Attach a swap disk to an instance. | ``--swap`` | :ref:`Attach_swap_or_ephemeral_disk_to_an_instance` |
|
- ``--block-device``
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
- :ref:`Boot_instance_from_image_and_attach_non-bootable_volume`
|
||||||
| Attach an ephemeral disk to an instance. | ``--ephemeral`` | :ref:`Attach_swap_or_ephemeral_disk_to_an_instance` |
|
* - Attach a swap disk to an instance.
|
||||||
+------------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------+
|
- ``--swap``
|
||||||
|
- :ref:`Attach_swap_or_ephemeral_disk_to_an_instance`
|
||||||
|
* - Create a volume from an image and boot an instance from that
|
||||||
|
volume.
|
||||||
|
- ``--block-device``
|
||||||
|
- :ref:`Create_volume_from_image_and_boot_instance`
|
||||||
|
* - Boot from an existing source image, volume, or snapshot.
|
||||||
|
- ``--block-device``
|
||||||
|
- :ref:`Create_volume_from_image_and_boot_instance`
|
||||||
|
* - Attach a swap disk to an instance.
|
||||||
|
- ``--swap``
|
||||||
|
- :ref:`Attach_swap_or_ephemeral_disk_to_an_instance`
|
||||||
|
* - Attach an ephemeral disk to an instance.
|
||||||
|
- ``--ephemeral``
|
||||||
|
- :ref:`Attach_swap_or_ephemeral_disk_to_an_instance`
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
|
@ -250,57 +250,65 @@ Comparison of static and dynamic large objects
|
|||||||
While static and dynamic objects have similar behavior, this table
|
While static and dynamic objects have similar behavior, this table
|
||||||
describes their differences:
|
describes their differences:
|
||||||
|
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
.. list-table::
|
||||||
| | Static large object | Dynamic large object |
|
:header-rows: 1
|
||||||
+=========================+=========================================+===========================================+
|
:widths: 30 10 30
|
||||||
| **End-to-end | Assured. The list of segments | Not guaranteed. The eventual consistency |
|
:stub-columns: 1
|
||||||
| integrity** | includes the MD5 checksum (``ETag``) of | model means that although you |
|
|
||||||
| | each segment. You cannot upload the | have uploaded a segment object, it |
|
* - Description
|
||||||
| | the manifest object if the ``ETag`` in | might not appear in the container |
|
- Static large object
|
||||||
| | the list differs from the uploaded | listing until later. If you download |
|
- Dynamic large object
|
||||||
| | segment object. If a segment is | the manifest before it appears in |
|
* - End-to-end integrity
|
||||||
| | somehow lost, an attempt to download | the container, it does not form part |
|
- Assured. The list of segments includes the MD5 checksum
|
||||||
| | the manifest object results in an | of the content returned in response |
|
(``ETag``) of each segment. You cannot upload the the manifest
|
||||||
| | error. | to a ``GET`` request. |
|
object if the ``ETag`` in the list differs from the uploaded
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
segment object. If a segment is somehow lost, an attempt to
|
||||||
| **Upload order** | You must upload the segment objects | You can upload manifest and segment |
|
download the manifest object results in an error.
|
||||||
| | before upload the manifest object. | objects in any order. You are recommended |
|
- Not guaranteed. The eventual consistency model means that
|
||||||
| | | to upload the manifest object after the |
|
although you have uploaded a segment object, it might not
|
||||||
| | | segments in case a premature download of |
|
appear in the container listing until later. If you download
|
||||||
| | | the manifest occurs. However, this is not |
|
the manifest before it appears in the container, it does not
|
||||||
| | | enforced. |
|
form part of the content returned in response to a ``GET``
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
request.
|
||||||
| **Removal or addition | You cannot add or remove segment | You can upload new segment objects or |
|
* - Upload order
|
||||||
| of segment objects** | objects from the manifest. However, you | remove existing segments. The names |
|
- You must upload the segment objects before upload the manifest
|
||||||
| | can create a completely new manifest | must simply match the ``PREFIX`` |
|
object.
|
||||||
| | object of the same name with a | supplied in ``X-Object-Manifest``. |
|
- You can upload manifest and segment objects in any order. You
|
||||||
| | different manifest list. | |
|
are recommended to upload the manifest object after the
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
segments in case a premature download of the manifest occurs.
|
||||||
| **Segment object | Segment objects must be at least 1 MB | Segment objects can be any size. |
|
However, this is not enforced.
|
||||||
| size and number** | in size (by default). The final segment | |
|
* - Removal or addition of segment objects
|
||||||
| | object can be any size. At most, 1000 | |
|
- You cannot add or remove segment objects from the manifest.
|
||||||
| | segments are supported (by default). | |
|
However, you can create a completely new manifest object of the
|
||||||
| | | |
|
same name with a different manifest list.
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
- You can upload new segment objects or remove existing segments.
|
||||||
| **Segment object | The manifest list includes the | All segment objects must be in the |
|
The names must simply match the ``PREFIX`` supplied in
|
||||||
| container name** | container name of each object. Segment | same container. |
|
``X-Object-Manifest``.
|
||||||
| | objects can be in different containers. | |
|
* - Segment object size and number
|
||||||
| | | |
|
- Segment objects must be at least 1 MB in size (by default). The
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
final segment object can be any size. At most, 1000 segments
|
||||||
| **Manifest object | The object has ``X-Static-Large-Object``| The ``X-Object-Manifest`` value is the |
|
are supported (by default).
|
||||||
| metadata** | set to ``true``. You do not set this | ``CONTAINER/PREFIX``, which indicates |
|
- Segment objects can be any size.
|
||||||
| | metadata directly. Instead the system | where the segment objects are located. |
|
* - Segment object container name
|
||||||
| | sets it when you ``PUT`` a static | You supply this request header in the |
|
- The manifest list includes the container name of each object.
|
||||||
| | manifest object. | ``PUT`` operation. |
|
Segment objects can be in different containers.
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
- All segment objects must be in the same container.
|
||||||
| **Copying the manifest | Include the ``?multipart-manifest=get`` | The ``COPY`` operation does not create |
|
* - Manfiest object metadata
|
||||||
| object** | query string in the ``COPY`` request. | a manifest object. To duplicate a |
|
- The object has ``X-Static-Large-Object`` set to ``true``. You
|
||||||
| | The new object contains the same | manifest object, use the ``GET`` |
|
do not set this metadata directly. Instead the system sets it
|
||||||
| | manifest as the original. The segment | operation to read the value of |
|
when you ``PUT`` a static manifest object.
|
||||||
| | objects are not copied. Instead,both | ``X-Object-Manifest`` and use this value |
|
- The ``X-Object-Manifest`` value is the ``CONTAINER/PREFIX``,
|
||||||
| | the original and new manifest objects | in the ``X-Object-Manifest`` request |
|
which indicates where the segment objects are located. You
|
||||||
| | share the same set of segment objects. | header in a ``PUT`` operation. This |
|
supply this request header in the ``PUT`` operation.
|
||||||
| | | creates a new manifest object that shares |
|
* - Copying the manifest object
|
||||||
| | | the same set of segment objects as the |
|
- Include the ``?multipart-manifest=get`` query string in the
|
||||||
| | | original manifest object. |
|
``COPY`` request. The new object contains the same manifest as
|
||||||
+-------------------------+-----------------------------------------+-------------------------------------------+
|
the original. The segment objects are not copied. Instead, both
|
||||||
|
the original and new manifest objects share the same set of
|
||||||
|
segment objects.
|
||||||
|
- The ``COPY`` operation does not create a manifest object. To
|
||||||
|
duplicate a manifest object, use the ``GET`` operation to read
|
||||||
|
the value of ``X-Object-Manifest`` and use this value in the
|
||||||
|
``X-Object-Manifest`` request header in a ``PUT`` operation.
|
||||||
|
This creates a new manifest object that shares the same set of
|
||||||
|
segment objects as the original manifest object.
|
||||||
|
@ -3,7 +3,8 @@ Schedule objects for deletion
|
|||||||
=============================
|
=============================
|
||||||
|
|
||||||
To determine whether your Object Storage system supports this feature,
|
To determine whether your Object Storage system supports this feature,
|
||||||
see :doc:`managing-openstack-object-storage-with-swift-cli`. Alternatively, check with your service provider.
|
see :doc:`managing-openstack-object-storage-with-swift-cli`.
|
||||||
|
Alternatively, check with your service provider.
|
||||||
|
|
||||||
Scheduling an object for deletion is helpful for managing objects that
|
Scheduling an object for deletion is helpful for managing objects that
|
||||||
you do not want to permanently store, such as log files, recurring full
|
you do not want to permanently store, such as log files, recurring full
|
||||||
|
8
tox.ini
8
tox.ini
@ -90,13 +90,15 @@ commands = {toxinidir}/tools/generatepot-rst.sh {posargs}
|
|||||||
[doc8]
|
[doc8]
|
||||||
# Settings for doc8:
|
# Settings for doc8:
|
||||||
# Ignore target directories
|
# Ignore target directories
|
||||||
ignore-path = doc/*/target,doc/*/build
|
ignore-path = doc/*/target,doc/*/build,doc/common-rst/glossary.rst
|
||||||
# File extensions to use
|
# File extensions to use
|
||||||
extensions = .rst,.txt
|
extensions = .rst,.txt
|
||||||
|
# Maximal line length should be 79 but we have some overlong lines.
|
||||||
|
# Let's not get far more in.
|
||||||
|
max-line-length = 100
|
||||||
# Disable some doc8 checks:
|
# Disable some doc8 checks:
|
||||||
# D000: Check RST validity (cannot handle lineos directive)
|
# D000: Check RST validity (cannot handle lineos directive)
|
||||||
# D001: Ignore lines longer than 79 chars
|
ignore = D000
|
||||||
ignore = D000, D001
|
|
||||||
|
|
||||||
[flake8]
|
[flake8]
|
||||||
show-source = True
|
show-source = True
|
||||||
|
Loading…
Reference in New Issue
Block a user