On Mon, Feb 22, 2016, at 02:42 PM, Matt Riedemann wrote: > > > On 2/22/2016 5:56 AM, Sean Dague wrote: > > On 02/19/2016 12:49 PM, John Garbutt wrote: > > <snip> > >> > >> 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. > > > > Thinking through this over the weekend. > > > > From the API I think I agree with Laski now. An API shouldn't doesn't > > typically need default behavior, it's ok to make folks be explicit. So > > making nic a required parameter is fine. > > > > "nic": "auto" > > "nic": "none" > > "nic": "$name" > > > > nic is now jsonschema enforced, 400 if not provided. > > > > that being said... I think the behavior of CLI tools should default to > > nic auto being implied. The user experience there is different. You use > > cli tools for one off boots of things, so should be as easy as possible. > > > > I think this is one of the places where the UX needs of the API and the > > CLI are definitely different. > > > > -Sean > > > > Is nic only required when using neutron? Or as part of the microversion > are we also going to enforce this for nova-network, because if so, that > seems like a step backward. But if we don't enforce that check for both > neutron and nova-network, then we have differences in the API again.
I think it makes sense to require it in both cases and keep users blissfully unaware of which networking service is in use. > > -- > > Thanks, > > Matt Riedemann > > > __________________________________________________________________________ > 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