Open Stack

Sorry for chiming in late.

It sounds natural to me that when no --nic option is specified and no
neutron network exists 'get-me-a-network' feature is used.
After a network for a project is created by a get-me-a-network or when
a project already has one network,
a user do not need to specify --nic option to launch an instance. I
think it is a consistent user experience.

"--nic auto" makes sense to some extent but it forces users to use
"--nic auto" option always (for a consistent behavior).

As already discussed, it will change the current behavior in a case
where there is no network,
but users have knowledge that they need to create a network first and
it is rare that a user wants to boot an instance without a network.


Regarding Horizon, I think we can support more user-friendly interaction.
The current launch instance form selects a network as default when
only one network exists.
We can do similar for 'get-me-a-network' case.
Horizon checks if there is a network for a project and if a network
does not exis
 and get-me-a-network is supported by both nova and neutron,
we can show 'auto-allocate' network as a default selection.
A user can continue to launch an instance with get-me-a-network,
or cancel launching an instance and create a network as he wants.

Thanks,
Akihiro


2016-02-20 12:06 GMT+09:00 Armando M. <armamig at gmail.com>:
>
>
> 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
>
>
>
> __________________________________________________________________________
> 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
>