openstack/swift - swift - OpenDev: Free Software Needs Free Tools

Also removed a bunch of unnecessary unquotes. Just use path_info
instead (it's already unquoted).
Partial-Bug: #1670915
Change-Id: If1af43485b4708cab6c4b5d7f6f0a334d8752518

Closes-Bug: #1671896
Related-Change: Ie4fee05b5f7e0c0879a7b42973bca459f7c85408
Change-Id: I18db1937a0991497027a4d096fb95cdda81f7d68

Trivialfix
Change-Id: I4862d073adecf1cc5312a64795ad890eeddf774d

With this commit, the tempurl middleware accepts (besides
the traditional unix timestamps) also timestamps according
to the format '%Y-%m-%dT%H:%M:%SZ' (one acceptable form of ISO 8601).
The idea is to make the tempurls more user-friendly,
and has been formulated here:
Change-Id: I346a0241060a9559d178b30e60c957792bbeb9f0
Implements: blueprint human-readable-tempurl-timestamp

For now, last modified timestamp is supported only on
object listing. (i.e. GET container)
For example:
GET container with json format results in like as:
[{"hash": "d41d8cd98f00b204e9800998ecf8427e", "last_modified":
"2015年06月10日T04:58:23.460230", "bytes": 0, "name": "object",
"content_type": "application/octet-stream"}]
However, container listing (i.e. GET account) shows just a dict
consists of ("name", "bytes", "name") for each container.
For example:
GET accounts with json format result in like as:
[{"count": 0, "bytes": 0, "name": "container"}]
This patch is for supporting last_modified key in the container
listing results as well as object listing like as:
[{"count": 0, "bytes": 0, "name": "container", "last_modified":
"2015年06月10日T04:58:23.460230"}]
This patch is changing just output for listing. The original
timestamp to show the last modified is already in container table
of account.db as a "put_timestamp" column.
Note that this patch *DOESN'T* change the put_timestamp semantics.
i.e. the last_modified timestamp will be changed only at both PUT
container and POST container.
(PUT object doesn't affect the timestamp)
Note that the tuple format of returning value from
swift.account.backend.AccountBroker.list_containers is now
(name, object_count, bytes_used, put_timestamp, 0)
* put_timestamp is added *
Original discussion was in working session at Vancouver Summit.
Etherpads are around here:
https://etherpad.openstack.org/p/liberty-swift-contributors-meetup
https://etherpad.openstack.org/p/liberty-container-listing-update
DocImpact
Change-Id: Iba0503916f1481a20c59ae9136436f40183e4c5b

With a multipart-manifest PUT request, if client sends the md5 of the
segments' etags, a 422 Unprocessable Entity response is returned. This
patch fixes that and confirms the etag
Change-Id: I4598a2a3f16ca8727bb07bbb6d8efcfcae777796
Closes-Bug: #1213200
Co-Authored-By: Tim Burke <tim@swiftstack.com>

Currently, conditional headers, e.g. If-Match, If-Modified-Since, etc.,
are listed for the GET objects API call, but not in the HEAD objects
call in the api-ref documentation. This patch adds the missing headers
to the HEAD documentation.
Change-Id: Idd1c248cc27415d148a1b9a5eb2e95f25b8c4da0
Closes-Bug: #1630212 

Change-Id: Ib95a693042f0b3cf204033eb5957660cb3573dcf
Related-Change: I56cd4738808b99c0a08463f83c100be51a62db05

Previously, they would render as "X -Trans-Id-Extra"
Change-Id: Ibaf9b365467a2c91a0f03baed4d7bc36b0fa9967

Swift returns `X-Openstack-Request-Id` for container and
object requests as well as account. A couple api-ref docs are
missing this value in the response examples.
Change-Id: Ifcd67a620e04be5e92b43c7749ee4acb50bb171d

Documents the syntax and meaning of container ACLs. Account ACLs
were already pretty well documented. However the account
ACL text was moved as part of this change.
TempAuth and keystoneauth have diffent ACLs. However, I decided
to describe both in one section/table because there are many
"examples" of ACLs in other documents, and it's better that
someone coming here from those sources become aware that the
specific ACL might not apply to them. In addition, the
referrer and .rlistings is common to both.
Some changes were also made to the api-ref document. The doc
and api-ref documents are published as seperate documents, so
the cross references from the api-ref section will not work
until this patch merges and the documents are rebuilt.
Change-Id: Icd2d6c278050c263b833ae76545c041f54fae68d

Many other OpenStack services use a `[X-]OpenStack-Request-Id` header
to return a unique identifier for the request. Swift will now return
`X-Trans-Id` as well as `X-Openstack-Request-Id`.
Change-Id: I56cd4738808b99c0a08463f83c100be51a62db05
Closes-Bug: #1572786 

The os-api-ref 1.0.0 is out. We can remove the support to older version now.
Reference:
6d41feb58d
Change-Id: I0b28cd3f6b5c393d63b9ab2b4dcd3b7b3c20f9b4

Now, instead of saying
 X-Versions-Location: <container>
 X-Versions-Mode: history
clients should just say
 X-History-Location: <container>
Since we've never had a release featuring a user-settable
X-Versions-Mode header, support may be dropped and that is now ignored.
Change-Id: Icfd0f481d4e40dd5375c737190aea7ee8dbc3bf9

Clarify Content-Type header definition for listings.
Distinguish between request and response definitions for
X-Account-Meta-Temp-URL-Key* headers.
Insert X-Container-Meta-Quota-* headers missing from some
request/response definitions.
Improve X-Container-Meta-Access-Control-Expose-Headers
parameter formatting.
Distinguish between request and response definitions for
X-Container-Meta-Temp-URL-Key* headers.
Co-Authored-By: Christian Schwede <cschwede@redhat.com>
Change-Id: I8fc7610395973b520aa9ddd72c94e1eb75f602cd
Related-Change: I315b4e550b7d10880fbc00fce9311127ba609c2d

If we're going to talk about replacing an object, we should use the
same object name as the previous example.
Including a non-zero content-length on PUT but not providing a body
will timeout.
Not including the '-' in '-H' will make curl complain:
 Rebuilt URL to: H/
 * Could not resolve host: H
 * Closing connection 1
201 Created responses have content-length of zero, not 116.
Change-Id: Ifd878559ee4036e4893221c7968f53021f38e236

Move the account listing sample responses to follow the sample
requests, and to precede the request/response parameter definitions to
be consistent with other parts of the doc.
Related-Change: I315b4e550b7d10880fbc00fce9311127ba609c2d
Change-Id: Ia20acacd238db4a423b8cd89af1658222b4c5828

Move repeated test re metadata header syntax to an include
file and make it be rendered as a note.
Also make already included text about metadata header value
encoding be a note.
Change-Id: I4795836587492954ad24dd5baaa5d668746d6040

Fixes a number of technical issues with the api-ref section
including:
- Added missing headers
- The header descriptions were made specific to whether they
 are used in requests or responses and the verb in question
 (example: Content-Length in object HEAD is the object size,
 not the response body length).
- Added references to API features such as bulk delete.
- Many typographical fixes (e.g., spaces in the middle
 of header names)
- Restored xml and json account/container listing
 examples.
The following areas were not updated and it is proposed
to defer them to a subsequent update. This is because
I don't have time or their merit is debatable:
- ACLs (as used in a Keystone context) are not
 described.
- Account create/delete is not described.
- I left List Endpoints as-is.
Change-Id: I315b4e550b7d10880fbc00fce9311127ba609c2d

In RFC 7233, response body size of range requests with parameter
'bytes=N-M' is (M - N + 1). And response of object GET request with
range parameter in current Swift implementation is according to the
RFC. However, in current api reference explains that response body
size of object GET request with 'Range: bytes=10-15' is five
( != 15 - 10 + 1).
This patch fixes the api reference explanation.
Change-Id: I8371864f8e5adb42c1e56b7ea26c556ea1252728

Currently, Swift api-ref is not configured with logABug feature.
When users click "Report bug" button, it leads to "openstack-manuals"
which is default.
Change-Id: I3b6fb410000637ff03d99110d440de88a5adc30c

Change-Id: Ib4aa4a26814273efafa3453237d18acf8cc966cb

Clarify that synced segment container names must be the same
when syncing large objects.
Also add multipart-menifest query string option to API ref
for object GETs.
Change-Id: Ib2d2a1e6c1e5eff215fc75c2b49e7d6758b17b7e
Partial-Bug: #1613681
Closes-Bug: #1613316 

This change introduces the concept of a "versioning mode" for
versioned_writes. The following modes are supported:
 * stack
 When deleting, check whether any previous versions exist in the
 versions container. If none is found, the object is deleted. If the
 most-recent version in the versions container is not a delete
 marker, it is copied into the versioned container (overwriting the
 current version if one exists) and then deleted from the versions
 container. This preserves the previous behavior.
 If the most-recent version in the versions container is a delete
 marker and a current version exists in the versioned container, the
 current version is deleted. If the most-recent version in the
 versions container is a delete marker and no current version exists
 in the versioned container, we copy the next-most-recent version
 from the versions container into the versioned container (assuming
 it exists and is not a delete marker) and delete both the
 most-recent version (i.e., the delete marker) and the just-copied
 next-most-recent version from the versions container.
 With this mode, DELETEs to versioned containers "undo" operations
 on containers. Previously this was limited to undoing PUTs, but now
 it will also undo DELETEs performed while in "history" mode.
 * history
 When deleting, check whether a current version exists in the
 versioned container. If one is found, it is copied to the versions
 container. Then an empty "delete marker" object is also put into the
 versions container; this records when the object was deleted.
 Finally, the original current version is deleted from the versioned
 container. As a result, subsequent GETs or HEADs will return a 404,
 and container listings for the versioned container do not include
 the object.
 With this mode, DELETEs to versioned containers behave like DELETEs
 to other containers, but with a history of what has happened.
Clients may specify (via a new X-Versions-Mode header) which mode a
container should use. By default, the existing "stack" mode is used.
Upgrade consideration:
======================
Clients should not use the "history" mode until all proxies in the
cluster have been upgraded. Attempting to use the "history" mode during
a rolling upgrade may result in some requests being served by proxies
running old code (which necessarily uses the "stack" mode), leading to
data loss.
Change-Id: I555dc17fefd0aa9ade681aa156da24e018ebe74b

This brings in RST plus YAML files, migrated from the source for [0].
The migration explanation is found on the openstack-dev mailing list [1].
Project instruction is in the OpenStack Documentation Contributor Guide [2].
A patch for publishing this source is in [3].
The conf.py and the tox environment are standard across other projects.
[0]http://developer.openstack.org/api-ref-objectstorage-v1.html
[1]http://lists.openstack.org/pipermail/openstack-dev/2016-May/093765.html
[2]http://docs.openstack.org/contributor-guide/api-guides.html
[3]https://review.openstack.org/#/c/313015/
Change-Id: Ifebc65b188c4f2ba35b61c0deae5ec24401df7f9