+1. Provide a sanitize_uuid() or similar, which may be as simple as:
def sanitize_uuid(val):
try:
return uuid.UUID(val)
except ValueError:
raise SomePossiblyNewException(...)
UUID consumers are encouraged, but not required, to use it - so we
retain backward compatibility overall, and fixes like this one can be
implemented individually.
On 04/24/2017 08:53 AM, Doug Hellmann wrote:
> Excerpts from Jadhav, Pooja's message of 2017-04-24 13:45:07 +0000:
>> 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.
>
> Another option would be to convert the input value to a canonical form.
> So if is_uuid_like() returns true, then pass the value to a new function
> format_canonical_uuid() which would format it with the proper number of
> hyphens. That value could then be stored correctly.
>
> Doug
>
>>
>> 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
>>
>
> __________________________________________________________________________
> 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
>
__________________________________________________________________________
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
