[openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

Doug Wiegley dougwig at parksidesoftware.com
Fri Feb 12 21:03:42 UTC 2016

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.


> On Feb 12, 2016, at 1:51 PM, Ed Leafe <ed at leafe.com> wrote:
> 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
> 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
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list