Open Stack

Hi,

Sorry for my slow replies. I was out of the office Thursday/Friday.
Catching up on this thread now.


On Sat, May 18, 2013 at 7:47 AM, Gary Kotton <gkotton at redhat.com> wrote:

>  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> 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.
>
> Prefetching already created ports on the nova-api side will most likely be
to slow to have any affect in the case when a user creates a port and then
immediately boots an instance. The slowness I mentioned in the blueprint
was about if we were to take the approach of having nova-api create the
ports in quantum (in this case there would be nothing to prefetch).  Also,
using cached information for the creation of an instance in my opinion
seems like it can be problematic. (Using cached info for getting  ips on an
instance though is a different story).

Aaron

>
>
>
>>  Thanks
>> Gary
>>
>>
>>  Thanks,
>>
>> Aaron
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> 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/07d64201/attachment.html>