Hi Russell, Doug, Thanks for your comments, I'm really glad to talk about this with you.
> -----Original Message----- > From: Doug Hellmann [mailto:doug.hellm...@dreamhost.com] > Sent: Saturday, August 03, 2013 6:14 AM > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Nova] Review request: Blurprint of API > validation > > > > > On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant <rbry...@redhat.com> wrote: > > > On 07/09/2013 07:45 AM, Ken'ichi Ohmichi 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? > > > I apologize for taking so long to address this. > > Here is my current take on this based on reviewing discussions, code, > and talking to others about it. > > From a high level, API input validation is obviously a good thing. > Having a common framework to do it is better. What complicates this > submission is the effort to standardize on Pecan/WSME for APIs > throughout OpenStack. > > We've discussed WSME and jsonschema on the mailing list. There are > perhaps some things that can be expressed using jsonschema, but not WSME > today. So, there are some notes on > https://etherpad.openstack.org/NovaApiValidationFramework showing how > the two could be used together at some point. However, I don't think > it's really desirable long term. It seems a bit awkward, and some > information gets duplicated. > > We had previously established that using WSME was the long term goal > here. Going forward with jsonschema with the current nova APIs is a > benefit in the short term, but I do not think it's necessarily in > support of the long term goal if there isn't consensus that combining > WSME+jsonschema is a good idea. > > This sort of thing affects a lot of code, so the direction is important. > I do not think we should proceed with this. It seems like the best > thing to do that helps the long term goal is to work on migrating our > API to WSME. In particular, I think we could do this for the v3 API, > since it's not going to be locked down until Icehouse. At the same > time, we should contribute back to WSME to add the features we feel are > missing to allow the types of validation we would like to do. > > If there is significant disagreement with this decision, I'm happy to > continue talking about it. However, I really want to see consensus on > this and how it fits in with the long term goals before moving forward. > > > > When we discussed this earlier, there was concern about moving to a > completely new toolset for the new API in Havana because of other > changes going on at the same time (something to do with extensions, IIRC). > I agreed it made sense to stick with our current tools to avoid adding > risk to the schedule. If that schedule has slipped into the next release, > or if you feel there is time after all, then I would also prefer to go > ahead with the general consensus reached at the Havana summit and use WSME. > > Given a little time, I think we can come up with something better than the > method of combining WSME and jsonschema proposed in the etherpad linked > above, which effectively requires us to declare the types of the parameters > twice in different formats. As Russell said, if we need to add to WSME to > make it easier to use, we should do that. That's a good point. The sample code on the etherpad[1] requires to define API schema twice for single API, and that would be workload against implementing API schema when Pecan/WSME has been used. So how about adding jsonschema support to WSME? If doing that, we will be able to use good validation based on jsonschema only by defining a single API schema. > I am working on getting WSME onto stackforge, to make contributions easier > (it's on bitbucket now, but using hg and pull requests is pretty different > from our normal review process and may add friction for some people). That would be good info, if the above idea gets consensus. I will start investigating how to implement jsonschema support for WSME after this discussion, and try contributing the above stackforge WSME. > We ran into a few tricky spots because of the wide variety of test configu- > rations in play, and that caused some delays. I think those issues are > worked out (especially with the Python 3.3 build systems available now), > so I will be picking that work up in a week or two (I'm traveling next week). Have a good travell:-) Thanks Ken'ichi Ohmichi --- [1]: https://etherpad.openstack.org/NovaApiValidationFramework _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
