Open Stack

On Mon, Feb 22, 2016 at 10:58 AM, Matt Riedemann
<mriedem at linux.vnet.ibm.com> wrote:
>
>
> 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.

Only you kinda can't:
https://github.com/openstack/neutron/blob/aadf2f30f84dff3d85f380a7ff4e16dbbb0c6bb0/neutron/plugins/common/constants.py#L41

get-me-a-network is enabled by default, so if you're running a recent
enough Neutron you're just going to get that extension enabled.

>
>
>>
>>>
>>>>
>>>> 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
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators