Print pipeline names in the reported pipeline

When current code modifies the pipeline, it prints the entry point
names instead of the names used to construct the pipeline. This is
inconvenient because a sysadmin cannot copy and paste from the log.

We already save the pipeline name into contexts in most cases, so
the fix simply reuses that to provide friendly names.

Fixes bug: 1311802

Change-Id: Ic76baf1360cd521f140fa1980029ccbce58f1717
Fixed a handful of typos

Change-Id: I8cb2de27818332be587df7321ef567f8399910a9
Merge "Print pipeline names in the reported pipeline"
Add Storage Policy Support

The basic idea here is to replace the use of a single object ring in
the Application class with a collection of object rings. The
collection includes not only the Ring object itself but the policy
name assocaited with it, the filename for the .gz and any other
metadata associated with the policy that may be needed. When
containers are created, a policy (thus a specific obj ring) is
selected allowing apps to specify policy at container creation time
and leverage policies simply by using different containers for object
operations.

The policy collection is based off of info in the swift.conf file.
The format of the sections in the .conf file is as follows:

swift.conf format:

    [storage-policy:0]
    name = chicken

    [storage-policy:1]
    name = turkey
    default = yes

With the above format:

- Policy 0 will always be used for access to existing containers
  without the policy specified. The ring name for policy 0 is always
  'object', assuring backwards compatiblity. The parser will always
  create a policy 0 even if not specified

- The policy with 'default=yes' is the one used for new container
  creation. T allows the admin to specify which policy is used without
  forcing the application to add the metadata.

This commit simply introduces storage policies and the loading
thereof; nobody's using it yet. That will follow in subsequent
commits.

Change-Id: Ica05f41ecf3adb3648cc9182f11f1c8c5c678985
Implements: blueprint storage-policies
Add Storage Policy Documentation

Add overview and example information for using Storage Policies.

Also updates SAIO makerings script and swift.conf to tie in with
the docs and create a 2nd policy as part of the SAIO install.

Change-Id: I6f11f7a1bdaa6f3defb3baa56a820050e5f727f1
Implements: blueprint storage-policies
Expose storage policies in /info

Change-Id: I3a4e88bc1bef704ef50369dec34bbdfca1c600ef
Implements: blueprint storage-policies
Add policy support to containers

Containers now have a storage policy index associated with them,
stored in the container_stat table. This index is only settable at
container creation time (PUT request), and cannot be changed without
deleting and recreating the container. This is because a container's
policy index will apply to all its objects, so changing a container's
policy index would require moving large amounts of object data
around. If a user wants to change the policy for data in a container,
they must create a new container with the desired policy and move the
data over.

Change-Id: I56480ca9e631fa19526cadfe4699bc340913f41a
Add policy support to objects

Objects now have a storage policy index associated with them as well;
this is determined by their filesystem path. Like before, objects in
policy 0 are in /srv/node/$disk/objects; this provides compatibility
on upgrade. (Recall that policy 0 is given to all existing data when a
cluster is upgraded.) Objects in policy 1 are in
/srv/node/$disk/objects-1, objects in policy 2 are in
/srv/node/$disk/objects-2, and so on.

Containers now have a storage policy index associated with them,
stored in the container_stat table. This index is only at container
creation time, and cannot be changed without deleting and recreating
the container. This is because a container's policy index applies to
all its objects, so changing a container's policy index would require
moving large amounts of object data around.  Thus, if it is desired to
change the policy for data in a container, the supported method would
be to create a new container with the desired policy and move the data
over.

This commit does not address replicators, auditors, or updaters except
where method signatures changed. They'll still work if your cluster
has only one storage policy, though.

Change-Id: I459f3ed97df516cb0c9294477c28729c30f48e09

Conflicts:
	test/unit/obj/test_server.py
	test/unit/proxy/controllers/test_obj.py

fixup simple proxy obj controller test

Change-Id: I65751f7a21c374c4936edf920c3ede4338df560f
Add Storage Policy Support to list_endpoints

This patch makes list_endpoints policy aware so that the object is
looked up in the right ring and its actual locations returned to the
client.

Change-Id: Ic33f54d806e85c969f65e6feab8ab45b16648975
Add storage policy support to object updates

The object server will now send its storage policy index to the
container server synchronously and asynchronously (via async_pending).

Each storage policy gets its own async_pending directory under
/srv/node/$disk/objects-$N, so there's no need to change the on-disk
pickle format; the policy index comes from the async_pending's
filename. This avoids any hassle on upgrade. (Recall that policy 0's
objects live in /srv/node/$disk/objects, not objects-0.)

Also clean up a couple little things in the object updater. Now it
won't abort processing when it encounters a file (not directory) named
"async_pending-\d+", and it won't process updates in a directory that
does not correspond to a storage policy.

That is, if you have policies 1, 2, and 3, but there's a directory on
your disk named "async_pending-5", the updater will now skip over that
entirely. It won't even bother doing directory listings at all. This
is a good idea, believe it or not, because there's nothing good that
the container server can do with an update from some unknown storage
policy. It can't update the listing, it can't move the object if it's
misplaced... all it can do is ignore the request, so it's better to
just not send it in the first place. Plus, if this is due to a
misconfiguration on one storage node, then the updates will get
processed once the configuration is fixed.

Change-Id: I07c730bebaee068f75024fa9c2fa9e11e295d9bd
Add Storage Policy Support to the Auditor

This patch makes the object auditor policy-aware, so it'll audit
objects in any storage policy.

Change-Id: I94e3a7937d9814b9ecef6ca35371e245a43513d3
Add storage policy support for the Replicator

This makes it so that objects stored in all policies get replicated
properly. This is only for rsync replication, not ssync.

Change-Id: Ifdb4624841f35953ba80189e669d3ef15d5563fd
Add Storage Policy Support to ssync

This patch makes ssync policy aware so that clusters using storage
policies and ssync replication will replicate objects in all policies.

Change-Id: I64879077676d764c6330e03734fc6665bb26f552
Put X-Timestamp in object 404 responses

This way the container reconciler can tell (sometimes) that an object
was deleted at a certain time.

Change-Id: Idaba3255f4109e5150d6c457f913c600fd8923eb
Allow overriding of storage policy index.

This is something the reconciler will need so that it can GET from one
policy, PUT in another, and then DELETE from the first one again.

Change-Id: Icd32332e330a967f634f96f29670671270eb074e
Add Storage Policy Support to Account HEAD

This change updates the account HEAD handler to report out per
policy object and byte usage for the account.  Cumulative values
are still reported and policy names are used in the report
out (unless request is sent to an account server directly in
which case policy indexes are used for easier accounting).

Below is an example of the relevant HEAD response for a cluster
with 3 policies and just a few small objects:

   X-Account-Container-Count: 3
   X-Account-Object-Count: 3
   X-Account-Bytes-Used: 21
   X-Storage-Policy-Bronze-Object-Count: 1
   X-Storage-Policy-Bronze-Bytes-Used: 7
   X-Storage-Policy-Silver-Object-Count: 1
   X-Storage-Policy-Silver-Bytes-Used: 7
   X-Storage-Policy-Gold-Object-Count: 1
   X-Storage-Policy-Gold-Bytes-Used: 7

Change-Id: I5ec251f9a8014dd89764340de927d09466c72221
Implements: blueprint storage-policies
Move Storage Policy validation from parser to class

Currently we validate Storage Policy conflicts while parsing
swift.conf in parse_storage_policies. This let's us get away
with unnatural things in tests like patch_policies with two
policies that have the same name.

Additionally this change makes the rules a bit easier to
identify and assure coverage.

Change-Id: I6cd48e5a3b3658e106ecd20df0b04fd804c028a4
Implements: blueprint storage-policies
Fix issue with account broker and pre-SPI databases

Set a DEFAULT storage_policy_index for existing container rows during
migration.

Copy existing object_count and bytes_used in policy_stat table during
migration.

Change-Id: I6b3f591bad455dcd072056c28fc5a37c3f618e40
Implements: blueprint storage-policies
Fixes versioning function tests with non-zero default policy

In each PUT, proxy-server will do HEAD request for container sync
and checking the object versions. This patch makes proxy-server
knows the non-zero default policy when HEADing

Change-Id: I29c5715a9dbc11d9f2ca9ccdfa7655beadf354f8
Minor refactor of storage policy helper functions

Pulled from a larger pending review where it became clear that
we didn't need to keep adding get_data_dir(index) type routines
so this patch makes a generic function in the policy module that
constructs strings given a base and a policy index then others
can use it directly or as a partial (as is done with get_data_dir()
for example)

Change-Id: Ia3bed58f4b8d52f44b8ab3e8fad8014231c19c50
Implements: blueprint storage-policies