On 2/22/2016 2:27 PM, Sean Dague wrote:
On 02/22/2016 02:50 PM, Andrew Laski wrote:
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.
+1
This should make the experience between both far more consistent. It
means making n-net API applications do a bit more work then now, but
it's explicit.
It also means the CLI experience should continue to be the same, because
--nic=auto is implied.
-Sean
OK, here is the spec so we can move discussion there now:
https://review.openstack.org/#/c/283206/
--
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
