<div dir="ltr">+1 to Matt. </div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 13, 2014 at 10:03 AM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
On 6/12/2014 8:58 PM, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 6/12/2014 5:58 PM, Christopher Yeoh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 13, 2014 at 8:06 AM, Michael Still <<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a><br>
<mailto:<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>>> wrote:<br>
<br>
    In light of the recent excitement around quota classes and the<br>
    floating ip pollster, I think we should have a conversation about the<br>
    review guidelines we'd like to see for API changes proposed against<br>
    nova. My initial proposal is:<br>
<br>
      - API changes should have an associated spec<br>
<br>
<br>
+1<br>
<br>
      - API changes should not be merged until there is a tempest<br>
change to<br>
    test them queued for review in the tempest repo<br>
<br>
<br>
+1<br>
<br>
Chris<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</blockquote>
<br>
We do have some API change guidelines here [1].  I don't want to go<br>
overboard on every change and require a spec if it's not necessary, i.e.<br>
if it falls into the 'generally ok' list in that wiki.  But if it's<br>
something that's not documented as a supported API (so it's completely<br>
new) and is pervasive (going into novaclient so it can be used in some<br>
other service), then I think that warrants some spec consideration so we<br>
don't miss something.<br>
<br>
To compare, this [2] is an example of something that is updating an<br>
existing API but I don't think warrants a blueprint since I think it<br>
falls into the 'generally ok' section of the API change guidelines.<br>
<br>
[1] <a href="https://wiki.openstack.org/wiki/APIChangeGuidelines" target="_blank">https://wiki.openstack.org/<u></u>wiki/APIChangeGuidelines</a><br>
[2] <a href="https://review.openstack.org/#/c/99443/" target="_blank">https://review.openstack.org/#<u></u>/c/99443/</a><br>
<br>
</blockquote>
<br></div></div>
I think I'd like to say I think something about something a few more times... :)<div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>