<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 15, 2013, at 10:59 PM, Gary Kotton <<a href="mailto:gkotton@redhat.com">gkotton@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
On 05/15/2013 10:53 PM, Aaron Rosen wrote:
<blockquote cite="mid:CANAD0X9fgp2GV_R5xU1XrZMCNb08m4hDh1DwyeSgRWxxRArLJw@mail.gmail.com" type="cite">
<div dir="ltr">
<div>Hi, <br>
<br>
</div>
I created the following blueprint and wanted to hear what the
community though before starting on it. <br>
<div>
<div><br>
<a moz-do-not-send="true" href="https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port">https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port</a><br>
</div>
</div>
</div>
</blockquote>
<br>
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."<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><br>
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)<br></div></blockquote><div><br></div><div>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'.</div><div><br></div><div>- Chris</div><div><br></div></div></body></html>