Open Stack

2016-02-13 19:05 GMT+08:00 Andrew Laski <andrew at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160215/8dbf2845/attachment.html>