On 19 February 2016 at 16:28, Andrew Laski <and...@lascii.com> wrote: > 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.
Consider a user that uses these four clouds: * nova-network flat DHCP * nova-network VLAN manager * neutron with a single provider network setup * neutron where user needs to create their own network For the first three, the user specifies no network, and they just get a single NIC with some semi-sensible IP address, likely with a gateway to the internet. For the last one, the user ends up with a network with zero NICs. If they then go and configure a network in neutron (and they can now use the new easy one shot give-me-a-network CLI), they start to get VMs just like they would have with nova-network VLAN manager. We all agree the status quo is broken. For me, this is a bug in the API where we need to fix the consistency. Because its a change in the behaviour, it needs to be gated by a micro version. Now, if we step back and created this again, I would agree that --nic=auto is a good idea, so its explicit. However, all our users are used to automatic being the default, all be it a very patchy default. So I think the best evolution here is to fix the inconsistency by making a VM with no network being the explicit option (--no-nic or something?), and failing the build if we are unable to get a nic using an "automatic guess" route. So now the default is more consistent, and those that what a VM with no NIC have a way to get their special case sorted. I think this means I like "option 2" in the summary mail on the ops list. Thanks, johnthetubaguy __________________________________________________________________________ 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
