<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-02-13 19:05 GMT+08:00 Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On Fri, Feb 12, 2016, at 03:51 PM, Ed Leafe wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA512<br>
><br>
> On 02/12/2016 02:41 PM, Andrew Laski wrote:<br>
><br>
> >> I think if the point of the experience for this API is to be<br>
> >> working out<br>
> >>> of the box. So I very much like the idea of a defaults change<br>
> >>> here to the thing we want to be easy. And an explicit option to<br>
> >>> disable it if you want to do something more complicated.<br>
><br>
> > I think this creates a potential for confusing behavior for users.<br>
> > They're happily booting instances with no network on 2.1, as silly<br>
> > as that might be, and then decide "ooh I'd like to use fancy new<br>
> > flag foo which is available in 2.35". So they add the flag to their<br>
> > request and set the version to 2.35 and suddenly multiple things<br>
> > change about their boot process because they missed that 2.24(or<br>
> > whatever) changed a default behavior. If this fits within the scope<br>
> > of microversions then users will need to expect that, but it's<br>
> > something that would be likely to trip me up as a user of the API.<br>
><br>
> I agree - that's always been the trade-off with microversions. You<br>
> never get surprises, but you can't move to a new feature in 2.X<br>
> without also having to get everything that was also introduced in<br>
> 2.X-1 and before. The benefit, of course, is that the user will have<br>
> changed something explicitly before getting the new behavior, and at<br>
> least has a chance of figuring it out.<br>
<br>
</span>I completely agree with the idea that the form of a request/response<br>
could change in any number of backwards incompatible ways due to a<br>
microversion. That's easily discoverable through a published schema.<br>
What I'm struggling with is the idea that we would be comfortable<br>
changing the meaning of something, or a default behavior, with a<br>
microversion. There's no discoverability for that sort of change except<br>
to try it and see what happens or read the docs. But the potential for<br>
surprise is high and there's no immediate feedback on misusing the new<br>
API like there is if the form changes and JSONSchema validation kicks it<br>
back.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>If our goal is the client can auto-generated through all the discovery mechanism, then I agree with you. At least for now, we can implement that. Thinking of why we have to face behaviour changes, it due to too complex behaviour in a simple API I guess...</div><div> </div><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>
><br>
> - -- Ed Leafe<br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v2<br>
> Comment: GPGTools - <a href="https://gpgtools.org" rel="noreferrer" target="_blank">https://gpgtools.org</a><br>
> Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" rel="noreferrer" target="_blank">http://www.enigmail.net/</a><br>
><br>
> iQIcBAEBCgAGBQJWvkXeAAoJEKMgtcocwZqLdEwP/R36392zeHL55LR19ewoSg8/<br>
> U9MJEmZo2RiWaJBqWlRsBF5DSNzi7oNzhot8bOcY+aO7XQAs2kfG1QF9YMj/YfTw<br>
> iqsCtKNfdJZR1lNtq7u/TodkkFLP7gO8Q36efOYvAMIIlZlOoMAyvLWRxDGTGN+t<br>
> ahgnw2z6oQDpARb6Yx7NFjogjccTENdkuDNyLy/hmuUpvLyvhUDQC1EouVNHPglA<br>
> Sb8tQYSsdKDHrggs8b3XuJZjJXYvn0M4Knnw3i/0DAVoZamVfsnHJ1EWRfOh7hq3<br>
> +C+MJfzfyz5K46ikvjpuSGPPZ8rPPLR1gaih/W2fmXdvKG7NSK3sIUcgJZ7lm4rh<br>
> VpVDCRWi9rlPuJa4JIKlZ8h6NNMHwiEq8Ea+dP7lHnx0qp8EIxkPDBdU6sCmeUGM<br>
> tqBeHjUU7f8/fbZkOdorn1NAEZfXcRew3/BeFFxrmu6X8Z2XHHXMBBtlmehEoDHO<br>
> 6/BzZH3I/5VPcvFZQfsYYivBj3vtmB8cVLbUNpD3xBLyJKVFEwfmGkkYQTlL0KDx<br>
> B+bqNDw2pK72/qN39rjmdZY/cZ4vGfBGu2CzJxbX+Zn2E8Mgg5rAuARG0OCNg9ll<br>
> uuVBy37vbPNrNV9UZSkSjmRma/l8kl1IzBbszH0ENbH/ov3ngKB0xWiLc1pBZKC9<br>
> GcPgzIoclwLrVooRqOSf<br>
> =Dqga<br>
> -----END PGP SIGNATURE-----<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>