On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote: > On Feb 12, 2016, at 14:49, Jay Pipes <jaypi...@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-requ...@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) __________________________________________________________________________ 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
