I don't really like the idea of Nova pre-caching ports just in case - that would mean that a user who comes into the Quantum APi my now find their port quota exceeded because Nova is holding them in its cache Phil From: Gary Kotton [mailto:gkotton at redhat.com] Sent: 18 May 2013 15:48 To: Aaron Rosen Cc: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova][Quantum] Move quantum port creation to nova-api On 05/16/2013 05:02 PM, Aaron Rosen wrote: On Wed, May 15, 2013 at 10:59 PM, Gary Kotton <gkotton at redhat.com<mailto:gkotton at redhat.com>> wrote: On 05/15/2013 10:53 PM, Aaron Rosen wrote: Hi, I created the following blueprint and wanted to hear what the community though before starting on it. https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port In the BP you wrote: "The only downside I see of moving this logic into nova-api is that we would slow down the response time from nova-api to provision instances." This can be addressed by nova prefetching quantum ports. When nova needs a port is can be retrieved from a cached pool. This may be a way of addressing this at a later stage if the nova api is indeed a bottleneck when it comes to the quantum interface (please note that this currently happens on the compute node at the moment) If there are ports that are preallocated and cached in a pool of available ports on the nova-api node this won't work if running multiple nova-api nodes with a load balancer in front. Why? It is just an implementation detail. This information can be maintained in the nova database. Thanks Gary Thanks, Aaron _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130520/8cbdf27d/attachment.html>