Open Stack

On 6 August 2014 22:23, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
>
> On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen <aaronorosen at gmail.com> wrote:
>>
>>
>>
>>
>> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton <gkotton at vmware.com> wrote:
>>>
>>>
>>>
>>> From: Aaron Rosen <aaronorosen at gmail.com>
>>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Date: Wednesday, August 6, 2014 at 10:09 AM
>>>
>>> To: OpenStack List <openstack-dev at lists.openstack.org>
>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>> forward
>>>
>>>
>>> On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton <gkotton at vmware.com> wrote:
>>>>
>>>>
>>>>
>>>> On 8/5/14, 8:53 PM, "Russell Bryant" <rbryant at redhat.com> wrote:
>>>>
>>>> >On 08/05/2014 01:23 PM, Gary Kotton wrote:
>>>> >> Ok, thanks for the clarification. This means that it will not be done
>>>> >> automagically as it is today ­ the tenant will need to create a
>>>> >> Neutron
>>>> >> port and then pass that through.
>>>> >
>>>> >FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>>>> >like to get rid of automatic port creation, but can't do that in the
>>>> >current stable API.
>>>>
>>>> Can you elaborate on what you mean here? What are the issues with port
>>>> creation?
>>>>
>>>
>>> Having nova-compute create ports for neutron is problematic if timeouts
>>> occur between nova and neutron as you have to garbage collect neutron ports
>>> in nova to cleanup (which was the cause of several bug in the cache handing
>>> allowing ports to leak into the info_cache in nova).  Pushing this out to
>>> the tenant is less orchestration nova has to do.
>>>
>>> [gary] my take on this is that we should allocate this via the n-api and
>>> not via the nova compute (which is far too late in the process. But that is
>>> another discussion :)
>>
>>
>> I agree, I had actually proposed this here:
>> https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
>> :),   though there are some issues we need to solve in neutron first --
>> allowing the mac_address on the port to be updated in neutron. This is
>> required for bare metal support as when the port is created we don't know
>> which physical mac will need to be mapped to the port.
>>>
>>>
>
>
> I think that in the long term (when we can do an API rev) we should just be
> getting rid of the automatic port creation completely with the updated Nova
> API. I don't see why the Nova API needs to do proxying work to neutron to
> create the port when the client can do it directly with neutron (perhaps via
> some convenience client code if desired). It removes the complexity of the
> garbage collection on failure issues in Nova that we currently have.

I'm astounded by this proposal - it doesn't remove the garbage
collection complexity at all - it transfers it from our code - Nova -
onto end users. So rather than one tested and consolidated
implementation, we'll have one implementation in saltstack, one
implementation in heat, one implementation in Juju, one implementation
in foreman etc.

In what possible way is that an improvement ?

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud