>plus I think a VM with a network is kinda nonsensical, On the contrary, that's when I find them the most useful! On Feb 12, 2016 14:33, "Doug Wiegley" <doug...@parksidesoftware.com> wrote:
> > > On Feb 12, 2016, at 3:17 PM, Andrew Laski <and...@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 <and...@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 <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 > >>> > >>> > __________________________________________________________________________ > >>> 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 > > > > > __________________________________________________________________________ > > 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 >
__________________________________________________________________________ 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
