Open Stack

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[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