Open Stack

+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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>