On 4/24/2017 8:45 AM, Jadhav, Pooja wrote:
Hi Devs,
I want your opinion about bug: https://bugs.launchpad.net/nova/+bug/1680130
When user passes incorrect formatted UUID, volume UUID like:
11111111-2222-4444-5555--666666666666(please note double hyphen) for
attaching a volume to an instance using "volume-attach" API then it
results into DBDataError with following error message: "Data too long
for column 'volume_id'". The reason is in database
"block_device_mapping" table has "volume_id" field of 36 characters only
so while inserting data to the table through 'BlockDeviceMapping' object
it raises DBDaTaError.
In current code, volume_id is of ‘UUID’ format so it uses
"is_uuid_like"[4] method of oslo_utils and in this method, it removes
all the hyphens and checks 32 length UUID and returns true or false. As
"11111111-2222-4444-5555--666666666666" this UUID treated as valid and
further it goes into database table for insertion, as its size is more
than 36 characters it gives DBDataError.
There are various solutions we can apply to validate volume UUID in this
case:
Solution 1:
We can restrict the length of volume UUID using maxlength property in
schema validation.
Advantage:
This solution is better than solution 2 and 3 as we can restrict the
invalid UUID at schema [1] level itself by adding 'maxLength'[2].
Solution 2:
Before creating a volume BDM object, we can check that the provided
volume is actually present or not.
Advantage:
Volume BDM creation can be avoided if the volume does not
exists.
Disadvantage:
IMO this solution is not better because we need to change the current
code. Because in the current code after creating volume BDM it is
checking volume is exists or not.
We have to check volume existence before creating volume BDM object. For
that we need to modify the "_check_attach_and_reserve_volume" method
[3]. But this method get used at 3 places. According to it, we have to
modify all the occurrences as per behavior.
Solution 3:
We can check UUID in central place means in "is_uuid_like" method of
oslo_utils [4].
Advantage:
If we change the "is_uuid_like" method then same issue might be solved
for the rest of the APIs.
Disadvantage:
IMO this also not a better solution because if we change the
"is_uuid_like" method then it will affect on several different projects.
Please let me know your opinion for the
same.
[1]
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/volumes.py#L65
[2]
https://github.com/openstack/nova/blob/master/nova/api/validation/parameter_types.py#L297
[3] https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3721
[4]
https://github.com/openstack/oslo.utils/blob/master/oslo_utils/uuidutils.py#L45
______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Is "11111111-2222-4444-5555--666666666666" actually getting past the
jsonschema validation check when attaching a volume to a server? Because
that's looking for a uuid:
https://github.com/openstack/nova/blob/0039231719d2a02c59e7cd76631e2ff03cc86b0d/nova/api/validation/parameter_types.py#L298
--
Thanks,
Matt
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
