Sorry for chiming in late. It sounds natural to me that when no --nic option is specified and no neutron network exists 'get-me-a-network' feature is used. After a network for a project is created by a get-me-a-network or when a project already has one network, a user do not need to specify --nic option to launch an instance. I think it is a consistent user experience.
"--nic auto" makes sense to some extent but it forces users to use "--nic auto" option always (for a consistent behavior). As already discussed, it will change the current behavior in a case where there is no network, but users have knowledge that they need to create a network first and it is rare that a user wants to boot an instance without a network. Regarding Horizon, I think we can support more user-friendly interaction. The current launch instance form selects a network as default when only one network exists. We can do similar for 'get-me-a-network' case. Horizon checks if there is a network for a project and if a network does not exis and get-me-a-network is supported by both nova and neutron, we can show 'auto-allocate' network as a default selection. A user can continue to launch an instance with get-me-a-network, or cancel launching an instance and create a network as he wants. Thanks, Akihiro 2016-02-20 12:06 GMT+09:00 Armando M. <arma...@gmail.com>: > > > On 19 February 2016 at 09:49, John Garbutt <j...@johngarbutt.com> wrote: >> >> 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. > > > As much as I can see why a '--nic auto' option makes sense to some, on the > other end, it implies that a user has implicit knowledge of how the system > actually works, i.e. he/she knows that a network with sane networking > settings is going to be provided on his/her behalf. But what happens if > he/she wants two NICs (or N for that matter)? Wouldn't --nic auto --nic auto > be an awkward command? This may require some validation, thus potentially > complicating the logic further either server or client side...yuk > > I appreciate that today the nova boot command allows the omission of the > --nic parameter and that the command outcome is different between > nova-network and neutron. No-one can change the fact that we're in a sticky > situation. > > IMO, all things considered, keeping the --nic param optional is the best way > forward, even if that means some short term pain for Neutron users (and > that's coming from me!) > > In fact, if we continue to keep --nic an optional parameter, we can > reconcile the behavior between nova-net and neutron (which is really the win > here - make different clouds behave alike). > > By omitting the parameter the user is really saying 'I don't care, give me > what you got'. Sure that means that by the micro-version bump Neutron users > lose the opportunity to boot without networks, but some might argue that > that behavior should have never made it in in the first place: as of today, > it's potentially race-y (in situations where VMs are booted in a loop and > someone else is provisioning networks under the hood) and inconsistent with > nova-net. > > So if we assume that users must state what they want (or not) the --no-nic > option sounds the most compelling to me. Hence I'd lean on option 2 as well. > > Cheers, > Armando > >> >> >> 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 > > > > __________________________________________________________________________ > 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