Open Stack

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.

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). We
ran into a few tricky spots because of the wide variety of test
configurations 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).

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130802/a71a97ab/attachment.html>