openstack/openstack-manuals
Code Issues Proposed changes

Merge "Avoid really overlooooooooong lines in RST"

Browse Source
This commit is contained in:
Jenkins
2015-06-15 12:27:48 +00:00
committed by Gerrit Code Review
parent 2bfd6b69f2 21d93118f0
commit ce6c6d8738
15 changed files with 231 additions and 151 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/admin-guide-cloud-rst/source/identity_management.rst
View File

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

3
doc/admin-guide-cloud-rst/source/index.rst
View File

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

97
doc/common-rst/cli_manage_images.rst
View File

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

6
doc/common-rst/dashboard_customizing.rst
View File

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

57
doc/networking-guide/source/intro_basic_networking.rst
View 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

11
doc/networking-guide/source/intro_os_networking_service.rst
View File

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

14
doc/user-guide-admin/source/cli_set_compute_quotas.rst
View File

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

3
doc/user-guide-admin/source/dashboard_manage_volumes.rst
View File

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

3
doc/user-guide/source/cli_create_and_manage_stacks.rst
View File

@@ -122,7 +122,8 @@ 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 \
/path/to/heat/templates/WordPress_Single_Instance_v2.template \
--parameters "InstanceType=m1.large;DBUsername=wp;DBPassword=verybadpassword;KeyName=heat_key;LinuxDistribution=F17" --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 |

8
doc/user-guide/source/cli_manage_ip_addresses.rst
View File

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

5
doc/user-guide/source/cli_nova_configure_access_security_for_instances.rst
View File

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

40
doc/user-guide/source/cli_nova_launch_instance_from_volume.rst
View File

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

116
doc/user-guide/source/cli_swift_large_object_creation.rst
View File

@@ -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
doc/user-guide/source/sdk_schedule_objects_for_deletion.rst
View File

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

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