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