Updated development.environment.rst

Enhanced the discussion of tools/install_venv.py to say that it
installs the items listed in test-requirements.txt as well as
those listed in requirements.txt.

Re-wrapped the relevant paragraph.

Since the change to delete run_tests.sh and tools/install_venv.py
(https://review.openstack.org/#/c/76627/)
has been abandoned, the doc of install_venv.py should still be
accurate.

Change-Id: I5cfd9f179f40b2418129067d0940bfdbf47512cb
Closes-Bug: #1266671
Remove action-args from nova-manage help

During help [action_args [action_args ...]] could be
confusing for users

$ nova-manage network list -h
usage: nova-manage network list [-h]
         [action_args [action_args ...]]

Because of that action_args is set to "SUPPRESS" from the help

Change-Id: I0fdc480724d3b59a8eebb2d294f324441c5e46b2
Closes-Bug: #1260538
Include next link when default limit is reached

The /servers and /servers/detail APIs support pagination and a
"next" link should be included when more data is available, see
http://docs.openstack.org/api/openstack-compute/2/content/
Paginated_Collections-d1e664.html. In the documentation it states
that 'collections are required to contain atom "next" links'.

When the default "osapi_max" limit is reached then the "next" link
is not included in the API reply. In this case, the caller cannot
determine if there are any more servers and has no marker value
such that they can retrieve the rest of the servers.

For example, assume that there are 1050 VMs and the osapi_max value
is the default of 1000. The /servers API will return the first 1000
VMs but it will not include the "next" link; the caller has no way
to determine if there are more then 1000 VMs and no way to retrieve
the other 50 VMs.

The fix for this is to include the "next" link when the number of
servers being returned is the maximum limit, even if the "limit"
parameter is not supplied. Note: the caller could workaround this
by specifying the exact "osapi_max" limit value (ie, limit=1000)
on the API call but this requires that the caller knows the
configured limit.

Change-Id: I9b3da852b0ab11dc980524e2317ee876a3ec28b8
Closes-bug: 1288466
Use correct project/user for quotas

This fixes the compute manager to ensure the proper project_id/user_id
is used when making quota calls by converting most of the compute
manager code to use the new objects. This does not change the RPC
messages to the manager, yet.

Change-Id: I50601d12edef735f3c01ad73445e0826d05efc51
Closes-bug: 1271541
Remove unused quota_* calls from conductor

Compute manager's use of quota calls has been converted to using
objects internally and conductor's quota_commit and quota_rollback
methods are no longer used.

Change-Id: I6f43cb7f94775632e97d40e65ca08a3ba5dc195f
Use project/user from instance for quotas

If an admin confirms a resize, a periodic task auto-confirms a resize,
or if an admin reverts a resize, these should all use the instance
project/user for quota updates.

Closes-bug: 1271429
Closes-bug: 1278686
Closes-bug: 1278695

Change-Id: I1e128cd4035d0140e35582de795eb4d6fb8603f2
Make 'VDI too big' more verbose

Added sizes to error logging for easier debugging. Changed log level
from error to debug.

Change-Id: I397b79df8cae01d736733b7b141f3b4a8513f708
Note that XML support *may* be removed.

To be more accurate, note that XML support *may* be removed as early
as the Juno release.  I think there is still more discussion needed
around concrete usage data before the removal date is finalized.

Related thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-April/031608.html

Closes-bug: #1301384
Change-Id: I0415b50ec0b81bb56f5c0fa13bc6d01f8bec7865
Merge "Note that XML support *may* be removed."
Merge "Updated development.environment.rst"
Merge "Use correct project/user for quotas"
Merge "Remove unused quota_* calls from conductor"
Merge "Use project/user from instance for quotas"
Sync request_id middleware bug fix from oslo

There is a bug in request-id middleware that a subsequent API request
will overwrite a request-id of a previous request when multiple API
calls are processed in parallel in request_id middleware. This problem
was discovered when implementing nova change I5e370. Syncing the update
will allow that change to move forward.

oslo change to fix the middleware:
d7bd9dc37ac3d6bc171cd2e290c772633ad20a32

Change-Id: Ie7d8e831c43b9b246a30cef9a44a9e8a31ebe420
Merge "Make 'VDI too big' more verbose"
Merge "Sync request_id middleware bug fix from oslo"
Merge "Remove action-args from nova-manage help"
Merge "Include next link when default limit is reached"