NetApp fix for vsadmin role failure for ssc

The ssc feature does not work with vserver admin
role. If the user is a vsadmin then he does cannot
use the ssc feature fully. This fix checks the access
and issues apis appropriately and also handles error
conditions.

Closes-Bug: #1253657

Change-Id: Ibc4409e5d5e6e36bba41e5f59dd94c05b87b1cde
(cherry picked from commit 20667f7d49eed88ddd528be73293a624b3af1ba0)
Add valid check and unit tests on quota class

1.Cinder quota class hard_limit’s value should larger than -1 (-1 is a flag
value for unlimited).
2.Add unit tests for quota class.
3.Add quota_classes extension enabled in unitest, so as to do
unitest for quota_classes' update operation.

Closes-bug: #1245360

Change-Id: Ie483db1bdbd4fac875de26abab8ebebd96f4938b
(cherry picked from commit 8b6d51ea04a65d846b0e92a11e191327360d7427)
Fix volume transfer href issue

The volume transfer collection in url defined as "os-volume-tranfer",
but I got another define "tranfers" in href url. They are different.
So it should be modify.

closes-bug: #1242980
Change-Id: I69a43012f2bb70ce5fc7b0331d2759527a261170
(cherry picked from commit b104d1c0c70898b59b6668970e05cebadecd064a)
GlusterFS: Synchronize additional operations

create_cloned_volume() and copy_volume_to_image() should also be
locked against other driver operations to prevent collisions
from concurrent updates of snapshot metadata or volume file data.

Closes-Bug: #1267983

(cherry picked from commit 06999f610afc3a123f7a54895e39d690301a8eba)

Change-Id: Idd6158bfbe4dc049c33fa58b40d3d570fc244d01
GlusterFS: Fix deadlock in volume clone

The create_cloned_volume path could deadlock due to
create_cloned_volume and create/delete_snapshot using the same
lock for synchronization.

Refactor the calls to create/delete snapshot to call the inner
method which does not use a lock.

Introduced by "06999f6 GlusterFS: Synchronize additional op..."

Related-Bug: 1267983
Closes-Bug: 1272092

(cherry picked from commit e9722f09dfd4b58e40afbf285ab9a7738a641dca)

Note: Effectively includes most changes from "8772714 Pylint fixes ..."
to resolve conflicts.
(cherry picked from commit 8772714b4fcb2d05ae7f0bfe5cfd0fa660ab9100)

Conflicts:
        cinder/volume/drivers/glusterfs.py

Change-Id: I84ca34b201c10644faa047f1c9274c14bcdd0359
Delete volume transfer in volume_destroy function

Doing volume force delete operation on volume-A will change volume-A's
status to 'deleted', so all related data about volume-A should be deleted.
Now current version's volume_destroy function doesn't delete related data
of volume transfer. If there is volume transfer about volume-A, first do
force delete operation on volume A, and thus the volume-A's transfer data
would be residual. So remove the related data of volume transfer in
volume_destroy function.

Change-Id: Id80a6e0cc061fccb02af60706244be043abdd72d
Closes-Bug: #1270785
(cherry picked from commit 19d8040d61d453ec3916d74c628189ca0b54ac59)
Update quota-set throw 500 error

The server doesn't check whether the parameter "quota_set" or
"quota_class_set" is in request
body.So the 500 error has been thrown.

We should catch the KeyError and transfer the KeyError to
400(HTTPBadRequest) instead of 500.

Closes-Bug: #1249971
(cherry picked from commit 2ed2f3aff8eee70e02eb995780af292057cfcad4)
Change-Id: I01260c77efa50324f3d203888689cdb1e94d2c21
Raise max header size to accommodate large tokens

The max header is exceeded in the following scenario
- Auth tokens built with a keystone v3 API catalog
- A catalog with approximately 8 or more endpoints defined

An equivalent fix will be required for all projects which use
eventlet.wsgi.

Copied from https://review.openstack.org/#/c/33362/

Closes-Bug: 1190149

Change-Id: I3fcb196b25a7a477b799c8dfa2ff5115977ca06d
(cherry picked from commit aa1ba1f0176af286506e4188628e5acbb8f7f0e6)
Merge "Delete volume transfer in volume_destroy function" into stable/havana
Merge "Raise max header size to accommodate large tokens" into stable/havana
VMware: Fixed upload-to-image for available volume

Cinder generally does not allow upload-to-image operation on a volume
that is 'in-use'. This can however be over-ridden using the '--force True'
flag. The VMware driver cannot support upload-to-image when the volume is
in-use. This is a restriction for the VMware driver alone. When the user forces
an upload on a volume that is 'in-use' the Cinder api layer sets the volume
status to 'uploading' and calls into the driver code to upload. In this
scenario the VMware driver needs to fail the operation.

The current driver code here does this check wrongly by looking for volume
status of 'in-use'. Fixing this check to identify an in-use volume correctly.

Fixes bug: 1237338

(cherry picked from commit a2b774c0ce2a1aaa9cdfc7d7c4c4d642f1bfc3d1)

Change-Id: If54edfdc242a7a1bff442b6bb4c5a9865eede1dc
Merge "Add valid check and unit tests on quota class" into stable/havana
Merge "Fix volume transfer href issue" into stable/havana
Merge "GlusterFS: Synchronize additional operations" into stable/havana
Merge "GlusterFS: Fix deadlock in volume clone" into stable/havana
Merge "VMware: Fixed upload-to-image for available volume" into stable/havana
Merge "NetApp fix for vsadmin role failure for ssc" into stable/havana
Merge "Update quota-set throw 500 error" into stable/havana
User a more accurate max_delay for reconnects

In an HA deployment, a 60 seconds delay between reconnects can be quite
problematic. This patch changes the delay calculation by setting the max
delay to 5s and by changing the way it is increased.

Unfortunately, this is one of the places where both our main drivers are
not consistent. Rabbit's driver uses configuration parameters for this
whereas qpid's driver has never had one. However, I would prefer not
adding configuration paremeters to qpid's driver for the following
reasons:

    1. Most of OpenStack services depend on the messaging layer, hence
    they need it to be available. A 5s delay seems to be reasonable and
    I could argue the need of tune it further. Although so frequent
    reconnects can add load to the network, that wouldn't be the main
    issue if one of the brokers go down.
    2. We're trying to move away from configuration options towards using
    transport URL. This path is still not clear and I would
    prefer avoiding adding new options until we clear it out.

Closes-bug: #1281148

Change-Id: I537015f452eb770acba41fdedfe221628f52a920
(cherry picked from commit 8b628d1e024f787dbb93d508117d9148388c0590)
Update ensure()/reconnect() to catch MessagingError

The error handling code that gets connections reset if necessary
caught ConnectionError. It really needs to catch MessagingError,
which ConnectionError inherits from. There are other types of
MessagingErrors that may occur, such as InternalError, and they need
to cause the connection to reset, as well.

This fix has already been merged into oslo.messaging.

Closes-bug: #1303890
Change-Id: Ic5082b74a362ded8b35cbc75cf178fe6e0db62d0
(cherry picked from commit 234f64d608266f43d8856ff98c89ceba6699d752)