Open Stack

On Thu, 7 Aug 2014 11:58:43 +1200
Robert Collins <robertc at robertcollins.net> wrote:

> 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 ?

At the moment when cleaning up we don't know if a port was autocreated
by Nova or was passed to us initially through the API. And there can be
a long period of time between the initial server creation request and
failure/cleanup - the API layer responds to the client well before the
server has successfully started or failed.

I think this sort of logic is much better handled above the REST API
layer- which doesn't have to mean duplicated code in multiple clients
- it can for example be handled by client libraries such as
python-novaclient or openstackclient and neutron related errors more
directly returned to the client rather than having them proxied
all the way through Nova.

Chris