Open Stack

Hi Russell,

I have assigned you as the approver of bp "nova-api-validation-fw",
please approve it or give some comments.
  https://blueprints.launchpad.net/nova/+spec/nova-api-validation-fw

The implementation of core part is almost complete.
now waiting for blueprint approval.
  https://review.openstack.org/#/c/25358/


Thanks,
Ken'ichi Ohmichi

---
On Tue, 16 Jul 2013 13:37:15 +0900
"Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp> wrote:
> 
> Hi Russell,
> 
> I assigned you as the approver of bp "nova-api-validation-fw",
> so could you take a look at this bp?
> 
> You have changed the priority from Medium to Low these days.
> Could you show your concerns about this bp if you have.
> 
> 
> Thanks
> Ken'ichi Ohmichi
> 
> ---
> On Tue, 9 Jul 2013 20:45:57 +0900
> "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp> wrote:
> > 
> > Hi,
> > 
> > The blueprint "nova-api-validation-fw" has not been approved yet.
> > I hope the core patch of this blueprint is merged to Havana-2,
> > because of completing comprehensive API validation of Nova v3 API
> > for Havana release. What should we do for it?
> > 
> > 
> > The summary of "nova-api-validation-fw":
> >   * The patch review is in good progress.
> >   * "nova-api-validation-fw" is API input validation framework.
> >   * Simplify the code in the extensions of Nova v3 API.
> >   * Define API schema with JSON Schema.
> >   * Define common data formats to standardize whole of Nova v3 API.
> >   * Possible to choose APIs which are applied with this framework.
> >   * Possible to migrate other web framework.
> > 
> > 
> > The details of "nova-api-validation-fw" are the following:
> > 
> > * The patch review is in good progress.
> >   7 reviewers have marked +1 now.
> >   We are waiting for the approval of this blueprint before merging the
> >   patch. (https://review.openstack.org/#/c/25358/)
> > 
> > * "nova-api-validation-fw" is API input validation framework.
> >   This framework validates API parameters in a request body before the
> >   execution of API method. If the parameter is invalid, nova-api returns
> >   a BadRequest response including its reason.  
> > 
> > * Simplify the code in the extensions of Nova v3 API.
> >   There are a lot of validation code in each API method.
> >   After applying this framework, we will be able to separate them from
> >   API methods by defining API schema. That makes the code more readable.
> >   Also through trying to define API schema of each API, we will find the
> >   lacks of validation code and complement them for better v3 API.
> >   Necessary API schemas are for API which contains a request body. They
> >   are 37 APIs on Nova v3 API now, and they will increase later because
> >   the tasks, which port v2 API to v3 API, is in progress.
> > 
> > * Define API schema with JSON Schema.
> >   JSON Schema contains many features for validation, the details are
> >   written on http://json-schema.org/.
> >   Here is the schema of v3 keypairs API as a sample:
> >   == Request body sample of keypairs API ===============
> >   {
> >     "keypair": {
> >         "name": "keypair-dab428fe-6186-4a14-b3de-92131f76cd39",
> >         "public_key": "ssh-rsa AAAAB3NzaC1yc2EA[..]== Generated by Nova"
> >   }
> >   == API schema of keypairs API ========================
> >   {
> >       'type': 'object',
> >       'properties': {
> >           'keypair': {
> >               'type': 'object',
> >               'properties': {
> >                   'name': {'type': 'string', 'minLength': 1, 'maxLength': 255},
> >                   'public_key': {'type': 'string'},
> >               },
> >               'required': ['name'],
> >           },
> >       },
> >       'required': ['keypair'],
> >   }
> > 
> > * Define common data formats to standardize whole of Nova v3 API.
> >   We can define common data formats with FormatChecker of JSON Schema
> >   library.
> > 
> >   e.g. Data format of 'boolean':
> >     @jsonschema.FormatChecker.cls_checks('boolean')
> >     def validate_boolean_format(instance):
> >         return instance.upper() == 'TRUE' or instance.upper() == 'FALSE'
> > 
> >   The formats can be used in API schema:
> >     'onSharedStorage': {
> >         'type': 'string', 'format': 'boolean',
> >     },
> > 
> >   By re-using these common formats in many API schemas, that will be
> >   able to standardize whole of Nova v3 API.
> > 
> > * Possible to choose APIs which are applied with this framework.
> >   We can apply this framework to Nova v3 API only, the existing API (v2) can
> >   be out of scope of this framework.
> > 
> > * Possible to migrate other web framework.
> >   The API validation of this framework is executed with the decorator of API
> >   method, that means this framework does not depend on web framework.
> >   Also when migrating other web framework(e.g. Pecan/WSME) in the future, we
> >   will be able to use this framework.
> > 
> > 
> > Thanks
> > Ken'ichi Ohmichi
> > 
> > ---
> > On Fri, 5 Jul 2013 16:27:39 +0900
> > "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp> wrote:
> > > 
> > > Hi,
> > > 
> > > I have submitted a blueprint[1] and a patch[2] for Nova API validation.
> > > I request someone to review the blueprint and hopefully approve it.
> > > 
> > > This blueprint was approved once, but the Definition has been changed to
> > > Discussion because we discussed what is better validation mechanism "WSME
> > > original validation or JSON Schema". IIUC, we have found the advantages
> > > of JSON Schema through the discussion. [3]
> > > 
> > > Also we have found the way to overlap JSON Schema with WSME, so we will
> > > be able to use JSON Schema also when the web framework of Nova is changed
> > > to WSME. [4]
> > > 
> > > My latest patch has been implemented with JSON Schema[2], and I think API
> > > validation with JSON Schema is useful for Nova v3 API, because the API has
> > > complex API parameters and JSON Schema can check complex parameters naturally. 
> > > 
> > > 
> > > Any comments are welcome :-)
> > > 
> > > [1]: https://blueprints.launchpad.net/openstack/?searchtext=nova-api-validation-fw
> > > [2]: https://review.openstack.org/#/c/25358/
> > > [3]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/009824.html
> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009926.html
> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009937.html
> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/009970.html
> > >  - http://lists.openstack.org/pipermail/openstack-dev/2013-June/010057.html
> > > [4]: http://lists.openstack.org/pipermail/openstack-dev/2013-June/010814.html
> > > 
> > > 
> > > Thanks
> > > Ken'ichi Ohmichi
> > > 
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev