Open Stack

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.

> 
> 	-Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev