On Thu, 7 Aug 2014 11:58:43 +1200 Robert Collins <robe...@robertcollins.net> wrote:
> On 6 August 2014 22:23, Christopher Yeoh <cbky...@gmail.com> wrote: > > > > On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen <aaronoro...@gmail.com> > > wrote: > >> > >> > >> > >> > >> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton <gkot...@vmware.com> > >> wrote: > >>> > >>> > >>> > >>> From: Aaron Rosen <aaronoro...@gmail.com> > >>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > >>> Date: Wednesday, August 6, 2014 at 10:09 AM > >>> > >>> To: OpenStack List <openstack-dev@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 <gkot...@vmware.com> > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 8/5/14, 8:53 PM, "Russell Bryant" <rbry...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
