Open Stack

> On Feb 12, 2016, at 3:17 PM, Andrew Laski <andrew at lascii.com> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016, at 04:53 PM, Doug Wiegley wrote:
>> 
>>> 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.
> 
> I'm not suggesting that the default boot be unusable. I'm saying that
> just like it's required to pass in a flavor and image/volume to boot an
> instance why not require the user to specify something about the
> network. And that network request can be as simple as specifying "auto"
> or "none". That seems to meet all of the requirements without the
> confusion of needing to guess what the default behavior will be when
> it's left off because it can apparently mean different things based on
> which backed is in use. For users that don't read the docs they'll get
> an immediate failure response indicating that they need to specify
> something about the network versus the current and proposed state where
> it's not clear what will happen unless they've read the docs on
> microversions and understand which network service is being used.

I understand what you’re saying, and we’re almost down to style here. We have the previous nova-net ‘nova boot’ behavior, plus I think a VM with a network is kinda nonsensical, so adding that hoop for the default case doesn’t make sense to me. I’m not sure we’ll convince each other here, and that’s ok, I’ve said my peace.  :-)

Thanks,
doug

> 
>> 
>> 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
>> 
>> 
>> __________________________________________________________________________
>> 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