Open Stack

On 2/22/2016 2:27 PM, Sean Dague wrote:
> On 02/22/2016 02:50 PM, Andrew Laski wrote:
>>
>>
>> On Mon, Feb 22, 2016, at 02:42 PM, Matt Riedemann wrote:
>>>
>>>
>>> On 2/22/2016 5: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.
>>>>
>>>> 	-Sean
>>>>
>>>
>>> Is nic only required when using neutron? Or as part of the microversion
>>> are we also going to enforce this for nova-network, because if so, that
>>> seems like a step backward. But if we don't enforce that check for both
>>> neutron and nova-network, then we have differences in the API again.
>>
>> I think it makes sense to require it in both cases and keep users
>> blissfully unaware of which networking service is in use.
>
> +1
>
> This should make the experience between both far more consistent. It
> means making n-net API applications do a bit more work then now, but
> it's explicit.
>
> It also means the CLI experience should continue to be the same, because
> --nic=auto is implied.
>
> 	-Sean
>

OK, here is the spec so we can move discussion there now:

https://review.openstack.org/#/c/283206/

-- 

Thanks,

Matt Riedemann