<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 February 2016 at 09:49, John Garbutt <span dir="ltr"><<a href="mailto:john@johngarbutt.com" target="_blank">john@johngarbutt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 19 February 2016 at 16:28, Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>> wrote:<br>
> On Fri, Feb 19, 2016, at 11:14 AM, Sean Dague wrote:<br>
>> On 02/19/2016 09:30 AM, Andrew Laski wrote:<br>
>> ><br>
>> ><br>
>> > On Thu, Feb 18, 2016, at 05:34 PM, melanie witt wrote:<br>
>> >> On Feb 12, 2016, at 14:49, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>> >><br>
>> >>> This would be my preference as well, even though it's technically a backwards-incompatible API change.<br>
>> >>><br>
>> >>> 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.<br>
>> >>><br>
>> >>> So yeah, the "opt-in to having no networking at all with a --no-networking or --no-nics option" would be my preference.<br>
>> >><br>
>> >> +1 to this, especially opting in to have no network at all. It seems most<br>
>> >> friendly to me to have the network allocation automatically happen if<br>
>> >> nothing special is specified.<br>
>> >><br>
>> >> This is something where it seems like we need a "reset" to a default<br>
>> >> behavior that is user-friendly. And microversions is the way we have to<br>
>> >> "fix" an undesirable current default behavior.<br>
>> ><br>
>> > The question I would still like to see addressed is why do we need to<br>
>> > have a default behavior here? The get-me-a-network effort is motivated<br>
>> > by the current complexity of setting up a network for an instance<br>
>> > between Nova and Neutron and wants to get back to a simpler time of<br>
>> > being able to just boot an instance and get a network. But it still<br>
>> > isn't clear to me why requiring something like "--nic auto" wouldn't<br>
>> > work here, and eliminate the confusion of changing a default behavior.<br>
>><br>
>> The point was the default behavior was a major concern to people. It's<br>
>> not like this was always the behavior. If you were (or are) on nova net,<br>
>> you don't need that option at all.<br>
><br>
> Which is why I would prefer to shy away from default behaviors.<br>
><br>
>><br>
>> The major reason we implemented API microversions was so that we could<br>
>> make the base API experience better for people, some day. One day, we'll<br>
>> have an API we love, hopefully. Doing so means that we do need to make<br>
>> changes to defaults. Deprecate some weird and unmaintained bits.<br>
>><br>
>> The principle of least surprise to me is that you don't need that<br>
>> attribute at all. Do the right thing with the least amount of work.<br>
>> Instead of making the majority of clients and users do extra work<br>
>> because once upon a time when we brought in neutron a thing happen.<br>
><br>
> The principal of least surprise to me is that a user explicitly asks for<br>
> something rather than relying on a default that changes based on network<br>
> service and/or microversion. This is the only area in the API where<br>
> something did, and would, happen without explicitly being requested by a<br>
> user. I just don't understand why it's special compared to<br>
> flavor/image/volume which we require to be explicit. But I think we just<br>
> need to agree to disagree here.<br>
<br>
</div></div>Consider a user that uses these four clouds:<br>
* nova-network flat DHCP<br>
* nova-network VLAN manager<br>
* neutron with a single provider network setup<br>
* neutron where user needs to create their own network<br>
<br>
For the first three, the user specifies no network, and they just get<br>
a single NIC with some semi-sensible IP address, likely with a gateway<br>
to the internet.<br>
<br>
For the last one, the user ends up with a network with zero NICs. If<br>
they then go and configure a network in neutron (and they can now use<br>
the new easy one shot give-me-a-network CLI), they start to get VMs<br>
just like they would have with nova-network VLAN manager.<br>
<br>
We all agree the status quo is broken. For me, this is a bug in the<br>
API where we need to fix the consistency. Because its a change in the<br>
behaviour, it needs to be gated by a micro version.<br>
<br>
Now, if we step back and created this again, I would agree that<br>
--nic=auto is a good idea, so its explicit. However, all our users are<br>
used to automatic being the default, all be it a very patchy default.<br>
So I think the best evolution here is to fix the inconsistency by<br>
making a VM with no network being the explicit option (--no-nic or<br>
something?), and failing the build if we are unable to get a nic using<br>
an "automatic guess" route. So now the default is more consistent, and<br>
those that what a VM with no NIC have a way to get their special case<br>
sorted.<br></blockquote><div><br></div><div>As much as I can see why a '--nic auto' option makes sense to some, on the other end, it implies that a user has implicit knowledge of how the system actually works, i.e. he/she knows that a network with sane networking settings is going to be provided on his/her behalf. But what happens if he/she wants two NICs (or N for that matter)? Wouldn't --nic auto --nic auto be an awkward command? This may require some validation, thus potentially complicating the logic further either server or client side...yuk<br></div><div><br></div><div>I appreciate that today the nova boot command allows the omission of the --nic parameter and that the command outcome is different between nova-network and neutron. No-one can change the fact that we're in a sticky situation.</div><div><br></div><div>IMO, all things considered, keeping the --nic param optional is the best way forward, even if that means some short term pain for Neutron users (and that's coming from me!)</div><div><br></div><div>In fact, if we continue to keep --nic an optional parameter, we can reconcile the behavior between nova-net and neutron (which is really the win here - make different clouds behave alike).</div><div><br></div><div>By omitting the parameter the user is really saying 'I don't care, give me what you got'. Sure that means that by the micro-version bump Neutron users lose the opportunity to boot without networks, but some might argue that that behavior should have never made it in in the first place: as of today, it's potentially race-y (in situations where VMs are booted in a loop and someone else is provisioning networks under the hood) and inconsistent with nova-net.</div><div><br></div><div>So if we assume that users must state what they want (or not) the --no-nic option sounds the most compelling to me. Hence I'd lean on option 2 as well.</div><div><br></div><div>Cheers,</div><div>Armando</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think this means I like "option 2" in the summary mail on the ops list.<br>
<br>
Thanks,<br>
johnthetubaguy<br>
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>