Open Stack

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

-- 
Sean Dague
http://dague.net