[openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

John Garbutt john at johngarbutt.com
Fri Feb 19 17:49:02 UTC 2016


On 19 February 2016 at 16:28, Andrew Laski <andrew at 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 <jaypipes at 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.

I think this means I like "option 2" in the summary mail on the ops list.

Thanks,
johnthetubaguy



More information about the OpenStack-dev mailing list