Open Stack

> On Feb 12, 2016, at 2:15 PM, Andrew Laski <andrew at lascii.com> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:03 PM, Doug Wiegley wrote:
>> 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.
> 
> I was just going off of the behavior Matt described, that it was
> possible to boot with no network by leaving that out of the request. If
> the behavior already differs based on what networking backend is in use
> then we've put users in a bad spot, and IMO furthers my case for having
> explicit parameters in the request. I'm really not seeing how "--nic
> auto|none" is any harder than leaving all network related parameters off
> of the boot request, and it avoids potential confusion as to what will
> happen.

It hurts discoverability, and “expectedness”. If I’m new to openstack, having it default boot unusable just means the first time I use ’nova boot’, I’ll end up with a useless VM. People don’t read docs first, it should “just work” as far as that’s sane. And OpenStack has a LOT of these little annoyances for the sake of strict correctness while optimizing for an unusual or rare case.

The original stated goal of this simpler neutron api was to get back to the simpler nova boot. I’d like to see that happen.

Thanks,
doug

> 
>> 
>> Thanks,
>> doug
>> 
>> 
>>> On Feb 12, 2016, at 1:51 PM, Ed Leafe <ed at 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-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
> 
> __________________________________________________________________________
> 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