Update documentation for using keystone auth

Cleanup and add clarification to the documentation
for using Keystone auth.

Update to refer to auth_token middleware being
distributed as part of the keystomemiddelware project
rather than keystone.

Include capabilities (/info) in the list of reasons
why delay_auth_decision might need to be set in
auth_token middleware config.

Add description of the project_id:user_id format
for container ACLs and emphasize that ids rather than
names should be used since this patch has now merged:
https://review.openstack.org/#/c/86430

DocImpact
blueprint keystone-v3-support
Change-Id: Idda4a3dcf8240474f1d2d163016ca2d40ec2d589
Move multipart MIME parser into utils

Over on the EC branch, we need to be able to parse multipart MIME
documents in the object server. The formpost middleware has a
perfectly good MIME parser, but it seems sort of awful to import
things from formpost in swift/obj/server.py, so I pulled it out into
common.utils.

Change-Id: Ieb4c05d02d8e4ef51a3a11d26c503786b1897f60
Return correct number of changed partitions

When a ring is rebalanced the number of changed partitions is counted.
Before this patch partitions might be rebalanced, but actually no data
is moved - for example, when a partition is assigned to the same device
as before. This results in a wrong number of reassigned partitions that
is shown to the user.

This patch remembers the partition allocation before the rebalance, and
compares it to the new allocation after a rebalance. Only partitions
that are stored on a different device than before are counted.

Partial-Bug: 1367826
Also-By: Florent Flament <florent.flament-ext@cloudwatt.com>
Change-Id: Iacfd514df3af351791f9191cef78cff1b3e2645f
Merge "Move multipart MIME parser into utils"
container.merge_items bug

When replicated container entries get round-tripped through json, they wind up
with unicode objects for names.  This causes equality checks to fail against
container entries, and you can wind up with duplicate records.  My bad.

Change-Id: I3aee2ad8dbd3a617efe37e887cfb902a3e4a1646
Zero-copy object-server GET responses with splice()

This commit lets the object server use splice() and tee() to move data
from disk to the network without ever copying it into user space.

Requires Linux. Sorry, FreeBSD folks. You still have the old
mechanism, as does anyone who doesn't want to use splice. This
requires a relatively recent kernel (2.6.38+) to work, which includes
the two most recent Ubuntu LTS releases (Precise and Trusty) as well
as RHEL 7. However, it excludes Lucid and RHEL 6. On those systems,
setting "splice = on" will result in warnings in the logs but no
actual use of splice.

Note that this only applies to GET responses without Range headers. It
can easily be extended to single-range GET requests, but this commit
leaves that for future work. Same goes for PUT requests, or at least
non-chunked ones.

On some real hardware I had laying around (not a VM), this produced a
37% reduction in CPU usage for GETs made directly to the object
server. Measurements were done by looking at /proc/<pid>/stat,
specifically the utime and stime fields (user and kernel CPU jiffies,
respectively).

Note: There is a Python module called "splicetee" available on PyPi,
but it's licensed under the GPL, so it cannot easily be added to
OpenStack's requirements. That's why this patch uses ctypes instead.

Also fixed a long-standing annoyance in FakeLogger:

    >>> fake_logger.warn('stuff')
    >>> fake_logger.get_lines_for_level('warn')
    []
    >>>

This, of course, is because the correct log level is 'warning'. Now
you get a KeyError if you call get_lines_for_level with a bogus log
level.

Change-Id: Ic6d6b833a5b04ca2019be94b1b90d941929d21c8
Test for unicode names in AccountBroker.merge_items()

ContainerBroker.merge_items() had a bug in it where non-ASCII Unicode
names would possibly result in duplicate entries in container
databases. AccountBroker.merge_items() doesn't do the same
bulk-operations tricks that ContainerBroker does, so it doesn't
currently have the bug. This commit just adds a test to ensure the bug
doesn't creep in should someone decide to make AccountBroker look more
like ContainerBroker someday.

Change-Id: Id2ac129828dbdf55b609d839ce4d9d42437ee0a3
Fixes several typos (Swift)

Corrects spelling errors found in comments.

Change-Id: I228a888e3f256569ea32ef1613092dbd63e13c62
Add "--no-overlap" option to swift-dispersion populate

This change allows the user to use a "--no-overlap" parameter when
running the tool multiple times. It will increase the coverage by
whatever is specified in the dispersion_coverage field of the conf
file in a manner where existing container/objects are left in place
and no partition is populated more than once.

Related-Bug: #1233045

Change-Id: I139fed2f4c967ba18d073b7ecd1e946ed4da1271
Merge "Fixes several typos (Swift)"
Merge "Test for unicode names in AccountBroker.merge_items()"
Imported Translations from Transifex

Change-Id: Ibd8882766a87c6d77e786f7635b1290391e43f10
direct_client not passing args between some functions

The call to _get_direct_account_container in direct_get_account
has several of its args =None instead of set to the value passed
to direct_get_account.

The same applies to _get_direct_account_container in
direct_get_container.

The direct_get_container is only called by the account-reaper
and this bug will have limited impact on it. The marker,
maintained in reap_container, is ignored by direct_get_container.
This is not as bad as it sounds, if the account-reaper successfully
deletes the first 10K objects, assuming the container has > 10K
objects, the next call to direct_get_container will in fact return
the next 10K objects even though it sets marker=None (assuming the
first 10K objects were successfully deleted).

This patch also updates test_direct_get_account and
test_direct_get_container to ensure the appropriate
args are included in the connection query_string.

Closes-Bug: #1369558
Change-Id: If1c8aa1240d38354ebc9b1ebca92dc1c8c36cb5f
Merge "Add "--no-overlap" option to swift-dispersion populate"
Merge "Update documentation for using keystone auth"
Reject overly-taxing ranged-GET requests

RFC 7233 says that servers MAY reject egregious range-GET requests
such as requests with hundreds of ranges, requests with non-ascending
ranges, and so on.

Such requests are fairly hard for Swift to process. Consider a Range
header that asks for the first byte of every 10th MiB in a 4 GiB
object, but in some random order. That'll cause a lot of seeks on the
object server, but the corresponding response body is quite small in
comparison to the workload.

This commit makes Swift reject, with a 416 response, any ranged GET
request with more than fifty ranges, more than three overlapping
ranges, or more than eight non-increasing ranges.

This is a necessary prerequisite for supporting multi-range GETs on
large objects. Otherwise, a malicious user could construct a Range
header with hundreds of byte ranges where each individual byterange
requires the proxy to contact a different object server. If seeking
all over a disk is bad, connecting all over the cluster is way worse.

DocImpact

Change-Id: I4dcedcaae6c3deada06a0223479e611094d57234
Added instructions to create a label or UUID to the XFS volume and mount using it.

Change-Id: Idcaf16a278d6c34770af9b1f17d69bdd94fb86b7
Fix profile tests to clean up its tempdirs.

Change-Id: I363651046cf414e14f15affd834043aabd5427c0
Merge "Imported Translations from Transifex"
Add container_count to policy_stat table

Start tracking the container count per policy including reporting
it in account HEAD and supporting installations where the DB
existed before the updated schema.

Migration is triggered by the account audtior; if the database is
un-migrated it will continue to report policy_stats without the per
policy container_count keys.

Closes-Bug: #1367514
Change-Id: I07331cea177e19b3df303609a4ac510765a19162