Yep, the way we removed the validation is not good long term solution (IMO) because we still requesting the schema for unvalidated_model and I am not sure why do we need it. I will create a spec about it soon so we can discuss it in more details.
Best regards, Kairat Kushaev On Thu, Oct 1, 2015 at 2:44 PM, <[email protected]> wrote: > > 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 <[email protected]> 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: >>> [email protected]?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 >> > >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
