Correct me if I’m wrong, but with nova-net, ‘nova boot’ automatically gives it one nic with an IP, right?
So how is this changing that behavior? Making it harder to use, for the sake of preserving a really unusual corner case (no net with neutron), seems a much worse user experience here. Thanks, doug > On Feb 12, 2016, at 1:51 PM, Ed Leafe <e...@leafe.com> 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. > > - -- > > - -- 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
