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
