Open Stack

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.

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.

	-Sean

-- 
Sean Dague
http://dague.net