<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 4:35 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 07/09/2013 07:45 AM, Ken'ichi Ohmichi wrote:<br>

><br>
> Hi,<br>
><br>
> The blueprint "nova-api-validation-fw" has not been approved yet.<br>
> I hope the core patch of this blueprint is merged to Havana-2,<br>
> because of completing comprehensive API validation of Nova v3 API<br>
> for Havana release. What should we do for it?<br>
<br>
</div>I apologize for taking so long to address this.<br>
<br>
Here is my current take on this based on reviewing discussions, code,<br>
and talking to others about it.<br>
<br>
>From a high level, API input validation is obviously a good thing.<br>
Having a common framework to do it is better.  What complicates this<br>
submission is the effort to standardize on Pecan/WSME for APIs<br>
throughout OpenStack.<br>
<br>
We've discussed WSME and jsonschema on the mailing list.  There are<br>
perhaps some things that can be expressed using jsonschema, but not WSME<br>
today.  So, there are some notes on<br>
<a href="https://etherpad.openstack.org/NovaApiValidationFramework" target="_blank">https://etherpad.openstack.org/NovaApiValidationFramework</a> showing how<br>
the two could be used together at some point.  However, I don't think<br>
it's really desirable long term.  It seems a bit awkward, and some<br>
information gets duplicated.<br>
<br>
We had previously established that using WSME was the long term goal<br>
here.  Going forward with jsonschema with the current nova APIs is a<br>
benefit in the short term, but I do not think it's necessarily in<br>
support of the long term goal if there isn't consensus that combining<br>
WSME+jsonschema is a good idea.<br>
<br>
This sort of thing affects a lot of code, so the direction is important.<br>
 I do not think we should proceed with this.  It seems like the best<br>
thing to do that helps the long term goal is to work on migrating our<br>
API to WSME.   In particular, I think we could do this for the v3 API,<br>
since it's not going to be locked down until Icehouse.  At the same<br>
time, we should contribute back to WSME to add the features we feel are<br>
missing to allow the types of validation we would like to do.<br>
<br>
If there is significant disagreement with this decision, I'm happy to<br>
continue talking about it.  However, I really want to see consensus on<br>
this and how it fits in with the long term goals before moving forward.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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).</div>
<div><br></div><div>Doug</div><div><br></div></div></div></div>