Open Stack

On 22 February 2016 at 15:14, John Garbutt <john at johngarbutt.com> wrote:
> On 22 February 2016 at 12:01, Jay Pipes <jaypipes at gmail.com> wrote:
>> On 02/22/2016 06:56 AM, Sean Dague wrote:
>>> On 02/19/2016 12:49 PM, John Garbutt wrote:
>>> <snip>
>>>> 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.
>>>>
>>>> I think this means I like "option 2" in the summary mail on the ops list.
>>>
>>>
>>> Thinking through this over the weekend.
>>>
>>>  From the API I think I agree with Laski now. An API shouldn't doesn't
>>> typically need default behavior, it's ok to make folks be explicit. So
>>> making nic a required parameter is fine.
>>>
>>> "nic": "auto"
>>> "nic": "none"
>>> "nic": "$name"
>>>
>>> nic is now jsonschema enforced, 400 if not provided.
>>>
>>> that being said... I think the behavior of CLI tools should default to
>>> nic auto being implied. The user experience there is different. You use
>>> cli tools for one off boots of things, so should be as easy as possible.
>>>
>>> I think this is one of the places where the UX needs of the API and the
>>> CLI are definitely different.
>>
>> I'd be cool with this, too.
>
> +1 I am OK with this.
>
> Its an explicit API, its can be the same for nova-network and neutron,
> and supports the CLI behaviour folks want.
>
> Just to clarify with nic=auto, if there is no way to create a nic
> automatically (not allowed to do give-me-a-network, and no networks
> available, or the user has more than one network available, etc), we
> should fail the build of the server. Today I think we (sometimes?) end
> up falling back to nic=none, which seems totally counter to the
> explicit nature of the API. Its possible we could fail before the API
> returns, as least of the most likely reasons for failure (might need
> more neutron APIs - policy discovery - to do a more complete job of
> that).

Oh, I forgot to mention Horizon...

Talking with folks, since they require a network to be selected in the
create server flow, its likely they will use the new neutron API to
help populate their network drop down, rather than use these changes
in the Nova API. Although, I guess they might want to expose the new
nic=none option, thats not related to the key "first boot in a new
tenant" that we are trying to improve.

I think that means restricting our thoughts to just the Nova CLI and
direct API users, is OK. Although I am curious if that fits with
everyone's thinking about this topic?

Thanks,
johnthetubaguy