On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote: > On 02/19/2016 09:30 AM, Andrew Laski wrote: > > > > > > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: > >> On Feb 12, 2016, at 14:49, Jay Pipes <jaypi...@gmail.com> wrote: > >> > >>> This would be my preference as well, even though it's technically a > >>> backwards-incompatible API change. > >>> > >>> The idea behind get-me-a-network was specifically to remove the current > >>> required complexity of the nova boot command with regards to networking > >>> options and allow a return to the nova-net model where an admin could > >>> auto-create a bunch of unassigned networks and the first time a user > >>> booted an instance and did not specify any network configuration (the > >>> default, sane behaviour in nova-net), one of those unassigned networks > >>> would be grabbed for the troject, I mean prenant, sorry. > >>> > >>> So yeah, the "opt-in to having no networking at all with a > >>> --no-networking or --no-nics option" would be my preference. > >> > >> +1 to this, especially opting in to have no network at all. It seems most > >> friendly to me to have the network allocation automatically happen if > >> nothing special is specified. > >> > >> This is something where it seems like we need a "reset" to a default > >> behavior that is user-friendly. And microversions is the way we have to > >> "fix" an undesirable current default behavior. > > > > The question I would still like to see addressed is why do we need to > > have a default behavior here? The get-me-a-network effort is motivated > > by the current complexity of setting up a network for an instance > > between Nova and Neutron and wants to get back to a simpler time of > > being able to just boot an instance and get a network. But it still > > isn't clear to me why requiring something like "--nic auto" wouldn't > > work here, and eliminate the confusion of changing a default behavior. > > The point was the default behavior was a major concern to people. It's > not like this was always the behavior. If you were (or are) on nova net, > you don't need that option at all.
Which is why I would prefer to shy away from default behaviors. > > The major reason we implemented API microversions was so that we could > make the base API experience better for people, some day. One day, we'll > have an API we love, hopefully. Doing so means that we do need to make > changes to defaults. Deprecate some weird and unmaintained bits. > > The principle of least surprise to me is that you don't need that > attribute at all. Do the right thing with the least amount of work. > Instead of making the majority of clients and users do extra work > because once upon a time when we brought in neutron a thing happen. The principal of least surprise to me is that a user explicitly asks for something rather than relying on a default that changes based on network service and/or microversion. This is the only area in the API where something did, and would, happen without explicitly being requested by a user. I just don't understand why it's special compared to flavor/image/volume which we require to be explicit. But I think we just need to agree to disagree here. > > -Sean > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > 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
