[openstack-dev] [Nova] Review request: Blurprint of API validation
oomichi at mxs.nes.nec.co.jp
Mon Aug 5 00:20:06 UTC 2013
Hi Russell, Doug,
Thanks for your comments, I'm really glad to talk about this with you.
> -----Original Message-----
> From: Doug Hellmann [mailto:doug.hellmann at 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 <rbryant at 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 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:-)
More information about the OpenStack-dev