Open Stack

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-request at 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