On 02/22/2016 06: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.
I'd be cool with this, too.
Best,
-jay
__________________________________________________________________________
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
