Open Stack

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.



> 
> While I get that a backward-incompatible change may appear to "sneak in"
> for a user specifying a later microversion to get an unrelated feature,
> it seems reasonable to me that a user specifying a microversion would
> consult the documentation for the version delta to get a clear picture of
> what to expect once they specify the new version. This of course hinges
> on users knowing how microversions work and being familiar with
> consulting documentation when changing versions. I hope that is the case
> and I hope this change will come with a very clear and concise release
> note with a link to [1].

I do hope that users read the documentation and aren't caught unaware if
we make a change like this. But we can make it even easier for them to
know that something has changed if instead of changing default behavior
we make that behavior explicit.


> 
> -melanie
> 
> [1]
> http://docs.openstack.org/developer/nova/api_microversion_history.html
> 
> __________________________________________________________________________
> 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
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)