Open Stack

On 19 February 2016 at 09:49, John Garbutt <john at johngarbutt.com> wrote:

> On 19 February 2016 at 16:28, Andrew Laski <andrew at lascii.com> wrote:
> > 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.
>
> Consider a user that uses these four clouds:
> * nova-network flat DHCP
> * nova-network VLAN manager
> * neutron with a single provider network setup
> * neutron where user needs to create their own network
>
> For the first three, the user specifies no network, and they just get
> a single NIC with some semi-sensible IP address, likely with a gateway
> to the internet.
>
> For the last one, the user ends up with a network with zero NICs. If
> they then go and configure a network in neutron (and they can now use
> the new easy one shot give-me-a-network CLI), they start to get VMs
> just like they would have with nova-network VLAN manager.
>
> We all agree the status quo is broken. For me, this is a bug in the
> API where we need to fix the consistency. Because its a change in the
> behaviour, it needs to be gated by a micro version.
>
> Now, if we step back and created this again, I would agree that
> --nic=auto is a good idea, so its explicit. However, all our users are
> used to automatic being the default, all be it a very patchy default.
> So I think the best evolution here is to fix the inconsistency by
> making a VM with no network being the explicit option (--no-nic or
> something?), and failing the build if we are unable to get a nic using
> an "automatic guess" route. So now the default is more consistent, and
> those that what a VM with no NIC have a way to get their special case
> sorted.
>

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

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.

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!)

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

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.

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.

Cheers,
Armando


>
> I think this means I like "option 2" in the summary mail on the ops list.
>
> Thanks,
> johnthetubaguy
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160219/bff22ba8/attachment.html>