Open Stack

Hi,

Now we are implementing api validation framework for Oslo.
https://review.openstack.org/#/c/25884/
Through this process, we face difficult issue between strict validation and
compatibility.

Now Nova distinguishes string integer(ex. "10") as integer by int().
If passing parameter "0123", current Nova handles it as 123 because of
casting to integer.

>From the point view of strict validation, it is better to disallow integer
"0123".
However, from one of compatibility, it may be better to allow the value.

Also there is other issue of this kind.
Current "bool_from_str" type, which is used by parameter
"return_reservation_id" etc, is
distinguished to
  * True: True(boolean), not 0(int), "True"(str), "Yes"(str), "Y"(str)
  * False: Other everything
So now we can pass any value to parameter of "bool_from_str" type.
For strict validation, it is better to disallow except the following:
  * True(boolean), 1(int), "True"(str), "Yes"(str), "Y"(str)
  * False(boolean), 0(int), "False"(str), "No"(str), "N"(str)

IMO it is a good opportunity to adjust api validation, so I feel strict
validation is better. But this is not a strong opinion due to compatibility.

Any comments are welcome.


Thanks,
Ken'ichi Ohmichi

---

2013/3/27 Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>

>
> Hi Édouard,
>
> On Tue, 26 Mar 2013 14:01:16 +0100
> Édouard Thuleau <edouard.thuleau at gmail.com> wrote:
> >
> > Yes, very interesting.
> > Perhaps it could be mutualized between all OpenStack APIs. Why not
> > integrates it in the OpenStack common library (Oslo) ?
>
> Good point, Oslo is a nice implementation target from the viewpoint
> of whole OpenStack APIs.
> I guess the API validation will be executed in Resource.dispatch()
> of Oslo. Because now I think API schema definitions, which is used
> for API validation, are gotten from method attribute.
>
> openstack/common/wsgi.py
> 394     def dispatch(self, obj, action, *args, **kwargs):
> 395         """Find action-specific method on self and call it."""
> 396         try:
> 397             method = getattr(obj, action)
> 398         except AttributeError:
> 399             method = getattr(obj, 'default')
> 400         <<-- Here -->>
> 401         return method(*args, **kwargs)
>
> This will be changed by discussions.
>
>
> Thanks
> Ken'ichi Ohmichi
>
> ---
>
> > On Tue, Mar 26, 2013 at 1:24 PM, Sean Dague <sean at dague.net> wrote:
> >
> > > On 03/26/2013 06:09 AM, Ken'ichi Ohmichi wrote:
> > >
> > >>
> > >> Hi,
> > >>
> > >> This is RFC of blueprint nova-api-validation-fw.
> > >>    Blueprint: https://blueprints.launchpad.
> **net/nova/+spec/nova-api-**
> > >> validation-fw<
> https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw>
> > >>    Details  : https://wiki.openstack.org/**wiki/**
> > >> NovaApiValidationFramework<
> https://wiki.openstack.org/wiki/NovaApiValidationFramework>
> > >>
> > >> Nova has many RESTful APIs, and not all API parameters are completely
> > >> validated. We would like to propose an API validation framework to
> > >> implement comprehensive validation.
> > >> The benefits of this framework will be the followings:
> > >>   * Validate every API parameters.
> > >>   * Unify both message format and HTTP code of error response, if
> > >>     the same cause.
> > >>     ex) ".. is too short.", ".. is too long.", ".. is not integer."
> > >>   * Clarify the API parameter definitions.
> > >>   * Clean up codes by merging error handling methods.
> > >>
> > >> Using the JSON Schema library, we have created a prototype and
> examined
> > >> this API validation framework. The following URL is the prototype
> code.
> > >>    https://review.openstack.org/**25358<
> https://review.openstack.org/25358>
> > >>
> > >> We'd like to discuss the framework design, so any comments are
> welcome.
> > >>
> > >
> > > This looks like a nice start, and it would be really good to
> consolidate
> > > the validation to a central point. Have you submitted a design summit
> > > session on this as well?
> > >
> > >         -Sean
> > >
> > > --
> > > Sean Dague
> > > http://dague.net
> > >
> > >
> > > ______________________________**_________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org
> >
> > > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<
> 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/20130407/de08444f/attachment.html>