Open Stack

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.

> 
> - -- 
> 
> - -- 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev