Open Stack

On May 17, 2013, at 4:55 PM, Chris Behrens <cbehrens at codestud.com> wrote:

> 
> On 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."
> 
> I object to any change that's going to slow down API responses for create (or really for '*').  We want the API to return as quickly as possible.  There are things that happen in the background for this reason where otherwise it may be nice to receive an error via the API.  I believe that this is one of those cases.

> 
> Ultimately the problem here is a user not having enough insight into errors that occur during the build process.  Users are supposed to be able to look at instance faults to figure out why something failed.  Perhaps faults need to be re-thought or perhaps we're just not using them enough.  But I completely disagree with adding queries to quantum in nova-api during the build request.

Just because we do it on the 'api' side, it doesn't mean that nova has to wait to return to the user. This could be put into a greenthread or sent off to conductor/orchestrator/scheduler to handle before calling down to the compute node.

Vish

> 
> 
>> 
>> 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 this is the solution to keep the API at least as responsive as it is today, then I think we need to look at this first… not 'later'.
> 
> - Chris
> 
> _______________________________________________
> 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/98c8283d/attachment.html>