Fix account quota mw for handling a bad source path

The copy source must be container/object.
This patch avoids the server to return
an internal server error when user provides
a path without a container.

Change-Id: I8ea4e62b2a00c4b4a1666d30411a6c93a4f848a5
Fixes: bug #1254626
Fix ineffective expect header test

The test for expect header being sent
with non-zero object PUTs doesn't seem
to check its results, so passes whether
the expect header is set or not.

Change-Id: Ic74233c19e48aba43e63501467565e305ed399c3
Added a test for empty metadata

Here added a test for setting empty object metadata
and checking its value in response headers.

Change-Id: I460302661d150364a95bcd7f0ebbbc2a1e95507a
Make cors work better.

CORS doesn't really work with swift right now. OPTIONS calls for the most part
work but for so called "simple cross-site requests" (i.e. those that don't
require a pre-flight OPTIONS request) Swift always returns the Origin it was
given as the Access-Control-Allow-Origin in the response. This makes CORS
"work" for these requests but if you actually wanted the javascript user agent
to restrict anything for you it wouldn't be able to!

You can duplicate the issue with updated CORS test page:

http://docs.openstack.org/developer/swift/cors.html#test-cors-page

And a public container with an 'X-Container-Meta-Access-Control-Allow-Origin'
that does NOT match the webserver hosting the test-cors-page.

e.g.

with a public container that accepts cross-site requests from "example.com":

`swift post cors-container -m access-control-allow-origin:example.com -r .r:*`

You could point your browser at a copy of the test-cors-page on your
filesystem (the browser will will send 'Origin: null')

Without a token the XMLHttpRequest will not request any custom headers (i.e.
Access-Control-Request-Headers: x-auth-token) and the request will be made
with-out a preflight OPTIONS request (which Swift would have denied anyway
because the origin's don't match)

i.e. fill in "http://saio:8080/v1/AUTH_test/cors-container" for "URL" and
leave "Token" blank.

You would expect that the browser would not complete the request because
"Origin: null" does not match the configured "Access-Control-Allow-Origin:
example.com" on the container metadata, and indeed with this patch - it won't!

Also:

The way cors is set up does not play well with certain applications for swift.
If you are running a CDN on top of swift and you have the
Access-Control-Allow-Origin cors header set to * then you probably want the *
to be cached on the the CDN, not the Origin that happened to result in an
origin request.

Also:

If you were unfortunate enough to allow cors headers to be saved directly
onto objects then this allows them to supersede the headers coming from the
container.

NOTE: There is a change is behavior with this patch. Because its cors, a
      spec that was created only to cause annoyance to all, I'll write out
      what's being changed and hopefully someone will speak up if it breaks
      there stuff.

previous behavior: When a request was made with a Origin header set the
                   cors_validation decorator would always add that origin as
                   the Access-Control-Allow-Origin header in the response-
                   whether the passed origin was a match with the container's
                   X-Container-Meta-Access-Control-Allow-Origin or not, or even
                   if the container did not have CORS set up at all.
new behavior: If strict_cors_mode is set to True in the proxy-server.conf
              (which is the default) the cors_validation decorator will only
              add the Access-Control-Allow-Origin header to the response when
              the request's Origin matches the value set in
              X-Container-Meta-Access-Control-Allow-Origin. NOTE- if the
              container does not have CORS set up it won't just magically start
              working. Furthremore, if the Origin doesn't match the
              Access-Control-Allow-Origin - a successfully authorized request
              (either by token or public ACL) won't be *denied* - it just
              won't include the Access-Control-Allow-Origin header (it's up
              to the security model in the browser to cancel the request
              if the response doesn't include a matching Allow-Origin
              header).  On the other hand, if you want to restrict requests
              with CORS, you can actually do it now.

              If you are worried about breaking current functionality you
              must set:

              strict_cors_mode = False

              in the proxy-server.conf. This will continue with returning the
              passed in Origin as the Access-Control-Allow-Origin in the
              response.

previous: If you had X-Container-Meta-Access-Control-Allow-Origin set to *
          and you passed in Origin: http://hey.com you'd get
          Access-Control-Allow-Origin: http://hey.com back. This was true for
          both OPTIONS and regular reqs.
new: With X-Container-Meta-Access-Control-Allow-Origin set to * you get * back
     for both OPTIONS and regular reqs.

previous: cors headers saved directly onto objects (by allowing them to be
          saved via the allowed_headers config in the object-server conf)
          would be overridden by whatever container cors you have set up.
new: For regular (non-OPTIONS) calls the object headers will be kept. The
     container cors will only be applied to objects without the
     'Access-Control-Allow-Origin' and 'Access-Control-Expose-Headers' headers.
     This behavior doesn't make a whole lot of sense for OPTIONS calls so I
     left that as is. I don't think that allowing cors headers to be saved
     directly onto objects is a good idea and it should be discouraged.

DocImpact

Change-Id: I9b0219407e77c77a9bb1133cbcb179a4c681c4a8
DRY out common.constraints a bit more

Change-Id: If8a71692b79e381036b34245e09697ac1009beca
make probetests work with conf.d configs

Change-Id: I451ff4629730a334ac1bd8fc6cd75de95314e153
Merge "DRY out common.constraints a bit more"
Merge "make probetests work with conf.d configs"
Merge "Make cors work better."
Merge "Added a test for empty metadata"
Merge "Fix ineffective expect header test"
Merge "Fix account quota mw for handling a bad source path"
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
Storage policy support for REST API

There are two major pieces in this diff: the container piece and the
object piece.

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.

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: I983c7fb0cc39df002600586aa990f10d277a4b67
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
Send policy index on sync and async update

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