Open Stack

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.

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].

-melanie

[1] http://docs.openstack.org/developer/nova/api_microversion_history.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/f54867fe/attachment.pgp>