Open Stack

Hi Gary,

No what I meant was since nova-api would be creating the ports for the
requested networks in quantum (rather than when the instance lands on a
nova compute node)  that the api call to launch an instance to nova-api
would take longer. That said there was some discussion around this in
#openstack-nova and one thing that was discussed was possibly removing the
creation of ports from nova and have something else orchestrate this
process (similar to how we can currently do nova boot --nic port-id= )

Best,

Aaron


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)
>
> 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/20130515/dd44fca4/attachment.html>