Open Stack

We've been taking validation out as issues have been reported (it was
removed from image-list recently for example).

Removing across the board probably does make sense.

>
> Agree with you. That's why I am asking about reasoning. Perhaps, we need to
> realize how to get rid of this in glanceclient.
>
> Best regards,
> Kairat Kushaev
>
> On Wed, Sep 30, 2015 at 7:04 PM, Jay Pipes <jaypipes at gmail.com> wrote:
>
>> On 09/30/2015 09:31 AM, Kairat Kushaev wrote:
>>
>>> Hi All,
>>> In short terms, I am wondering why we are validating responses from
>>> server when we are doing
>>> image-show, image-list, member-list, metadef-namespace-show and other
>>> read-only requests.
>>>
>>> AFAIK, we are building warlock models when receiving responses from
>>> server (see [0]). Each model requires schema to be fetched from glance
>>> server. It means that each time we are doing image-show, image-list,
>>> image-create, member-list and others we are requesting schema from the
>>> server. AFAIU, we are using models to dynamically validate that object
>>> is in accordance with schema but is it the case when glance receives
>>> responses from the server?
>>>
>>> Could somebody please explain me the reasoning of this implementation?
>>> Am I missed some usage cases when validation is required for server
>>> responses?
>>>
>>> I also noticed that we already faced some issues with such
>>> implementation that leads to "mocking" validation([1][2]).
>>>
>>
>> The validation should not be done for responses, only ever requests (and
>> it's unclear that there is value in doing this on the client side at all,
>> IMHO).
>>
>> -jay
>>
>> __________________________________________________________________________
>> 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
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150930/5b5dba74/attachment-0001.html>