[Openstack-operators] [nova] Do you, or your users, have input on how get-me-a-network should work in Nova?

Matt Riedemann mriedem at linux.vnet.ibm.com
Mon Feb 22 15:58:33 UTC 2016



On 2/20/2016 5:29 PM, Matt Riedemann wrote:
>
>
> On 2/19/2016 4:48 PM, Kris G. Lindgren wrote:
>>
>>
>> ___________________________________________________________________
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy
>>
>>
>>
>>
>>
>>
>>
>> On 2/19/16, 10:07 AM, "Matt Riedemann" <mriedem at linux.vnet.ibm.com>
>> wrote:
>>
>>> There is a long contentious dev thread going on here [1] about how Nova
>>> should handle the Neutron auto-allocate-topology API (referred to as the
>>> 'get-me-a-network' effort).
>>>
>>> The point is to reduce the complexity for users to simply boot an
>>> instance and be able to ssh into it without having to first setup
>>> networks/subnets/routers in neutron and then specify a nic when booting
>>> the instance. If the planets are aligned, and no nic is provided (or
>>> available to the project), then nova would call the new neutron API to
>>> auto-allocate the network and use that to create a port to associate
>>> with the instance.
>>>
>>> There is existing behavior in Nova where you can boot an instance and
>>> get no networking with neutron as the backend. You can later add
>>> networking by attaching an interface. The nova dev team has no idea how
>>> common this use case is though.
>>>
>>> There will be a microversion to the nova API with the get-me-a-network
>>> support. The debate is what the default behavior should be when using
>>> that microversion. The options are basically:
>>>
>>> 1. If no nic is provided at boot and none are available, don't provide a
>>> network (existing behavior). If the user wants a network auto-allocated,
>>> they specify something like: --nic=auto
>>
>> This is my preferred choice - keep the functionality exactly the same
>> as the way it is today.  Users (if this is available) can opt-in.  Not
>> 100% familiar with micro-version - but is it possible to opt-out of
>> this micro-version all together, but have other, later, micro-versions?
>
> Users/clients opt into a microversion by specifying a header with the
> version in the request. You can't skip microversions. If your client
> support 2.10 and then you wanted to support 2.18, for example, you have
> to also build in support for handling 2.11-2.17.
>
>>
>>
>>>
>>> In this case the user has to opt into auto-allocating the network.
>>>
>>> 2. If no nic is provided at boot and none are available, nova will
>>> attempt to auto-allocate the network from neutron. If the user
>>> specifically doesn't want networking on instance create (for whatever
>>> reason), they have to opt into that behavior with something like:
>>> --nic=none
>>>
>>> This is closer in behavior to how booting an instance works with
>>> nova-network, but it is a change in the default behavior for the neutron
>>> case, and that is a cause for concern for any users that have written
>>> tools to expect that default behavior.
>>
>>
>> I don't like this but I think other people might.  Really I would like
>> to see a config option detailing how the cloud admin wants to handle
>> this behavior.
>
> With the push for more consistent API behavior across public OpenStack
> clouds, making the API configurable with config options is not really a
> thing we want to do anymore since it's not discoverable. If cloud A
> doesn't support this but cloud B does, even though you've specified the
> same microversion for both, it's confusing and unreliable. Of course we
> already have some of this situation already since not all of the virt
> driver backends support 100% of the REST API, but I don't think we want
> to add to that if we can help it.

Thinking about this again today, nova is going to be checking that the 
auto-allocate-topolocy extension is enabled in neutron. So if you just 
don't enable that extension, you've effectively disabled the nic=auto 
option in nova. Basically like a config option.

>
>>
>>>
>>> 3. If no nic is provided at boot and none are available, fail the
>>> request and force the request to be explicit, i.e. provide a specific
>>> nic, or auto, or none. This is a fail-fast scenario to force users to
>>> really state what they want.
>>
>> I don't like this option at all.  You are chaning what people must
>> provide on the bootline and this as far as I can tell is a breaking
>> change.
>
> Yes it's a breaking change, but with a microversion you have to opt into
> it, so you have to be aware of it when you make the request. Just FYI.
>
>>
>>>
>>> --
>>>
>>> As with any microversion change, we hope that users are reading the docs
>>> and aware of the changes in each microversion, but we can't guarantee
>>> that, so changing default behavior (case 2) requires discussion and
>>> input, especially from outside the dev team.
>>>
>>> If you or your users have any input on this, please respond in this
>>> thread of the one in the -dev list.
>>>
>>> [1]
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086437.html
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-operators mailing list