Cinder v2 API allows creating a volume with a quoted (single or double
quotes or even unbalanced number of quotes) display name. But when we
try to get info for such volume, we end up getting an error message
saying that no volume with such a name or ID exists. This error is due
to the inadvertent stripping of quotes from the filter in the api layer.
The api call eventually comes to check_volume_filters() in
cinder/volume/api.py. The invocation of ast.literal_eval() inside this
method strips the quotes for certain quoted strings leading to this
incorrect filtering. ast.literal_eval() is used to convert string
representations into python objects which are then used to frame the
SQL queries in the db layer. For example, the string "[1,2]" for a
filter (not the display name filter) gets converted to a list object
and results in an "IN" operation being emitted in the SQL query as
opposed to an exact match.
When display_name does not contain any quotes or contains an unbalanced
number of quotes, then ast.literal_eval() throws (just like the Python
interpreter would throw for an unquoted string literal or one with
unbalanced number of quotes). We handle this by ignoring the exception
and using the raw input value as the filter and moving on. For string
containing balanced number of quotes, such as, '"foo"',
ast.literal_eval() succeeds and returns the input with the surrounding
quotes stripped (just like how the python interpreter strips quotes
from a string literal to initialize a string var's value in memory).
To always use the raw user input string as the filter value, we can
either not pass string inputs to ast.literal_eval() or encode the
string using encode("string-escape") so that we get the original string
back after passing through ast.literal_eval(). We choose the former as
the latter buys us nothing.
Change-Id: I48e0aea801ccb011cb974eea3d685bb9f35c61b2
Closes-Bug: #1503485
This flips the tox.ini to always use constraints installation for
all targets. It drops the extra -constraints targets in the process.
This makes it so there is no developer change required to operate in our
new world order.
Change-Id: I2b56835edb2d75b7c871aae030e909578dbb958d
Depends-On: Iecd35d6bc3b1e9e0ed31b48a34e4149d34d55ac2
This adds the 'cascade' parameter to volume delete,
which deletes snapshots along with a volume in
one call.
This is done in the volume manager, and not in
a driver-optimized way, which will be a later
improvement.
Blueprint: del-vols-with-snaps
Change-Id: I33d15b76d4bd0de14c635d404b2c97096c977a58
Erroneous space in "rule: admin_api" was introduced in change Ibbd6f47c370d8f10c08cba358574b55e3059dcd1
oslo_policy regards space as a separator,
and fails to parse this rule: http://paste.openstack.org/show/488452/
Change-Id: I5de45c97a06b7ddecb36c2a1793c4f3fd5fd21d6
Currently delete_snapshot return True or False to indicate
whether the snapshot is really deleted on the array. This
is useless and just write for unit tests. Now we will remove
the return value and add another unit test for delete_snapshot.
Closes-Bug: #1549584
Change-Id: I17fea61e3c0f5565ab04bc82f172e638480f45dc
Currently we didn't match the ip in the iqn accurately,
now we will fix this in this patch.
Closes-Bug: #1545914
Change-Id: I32232fcc6cad733b0dd8fa8c323297f6fbac3137
Sometimes when we rename a LUN on the array, we should
add some description to record some information like
volume id on cinder side. This patch will enable this.
Closes-Bug: #1537304
Change-Id: Ib156e61b5b1e305c41426cf5c6001dd44770140c
When attaching or detaching hypermetro volume, the initialization
instance has three parameters, but the function definition has five
parameters.
Change-Id: I8343a7b75e02962c321a838de148acc54498f952
Closes-Bug: #1545971
In SE 8.x PercentSynced no longer works for VMAX3 as a criteria to
determine whether a device is synched or not. Luckily 'CopyState'
works for both VMAX2 and VMAX3 and is backward compatible with 7.6.x.
Change-Id: I443e5f17f3c0e779ebdfd868bcd05cb85b52f525
Closes-Bug: #1517103
This is something that confuses folks and isn't centrally
located. So... add it to the devref docs and hope that
developers read it.
There's tons of detail we can add in the future of course,
but this at least clears up some of the common misconceptions
that exist currently.
Change-Id: Ic5fb8da06d18fac3369a91a525accc75c1d28100
The super secret formula states that the error messages should
use '_' instead of '_LE'. This patch changes the ones introduced
in Replication V2.1.
Change-Id: I9a4b87421eeda69ca918cbf869f2990ef113e158
This focuses the replication work on a specific use case,
and eliminates some of the ambiguity in earlier versions.
Additionally this implementation addresses needs for
devices that do replication based on the whole backend-device
or on Pools.
Use case:
DR scenario, where a storage device is rendered inoperable.
This implementation allows the preservation of user data
for those volumes that are of type replication-enabled.
The goal is NOT to make failures completely transparent
but instead to preserve data access while an Admin tries
to rebuild/recover his/her cloud.
It's very important to note that we're no longer interested in
dealing with replication in Cinder at a Volume level. The concept
of have "some" volumes failover, and "others" left behind, proved
to not only be overly complex and difficult to implement, but we
never identified a concrete use-case where one would use failover
in a scenario where some volumes would stay and be accessible on
a primary but other may be moved and accessed via a secondary.
In this model, it's host/backend based. So when you failover,
you're failing over an entire backend. We heavily leverage
existing resources, specifically services, and capabilities.
Implements: blueprint replication-update
Change-Id: If862bcd18515098639f94a8294a8e44e1358c52a
