<div dir="ltr">Hi, <div><br></div><div>Just to align this thread again here is what i'm thinking. In the current nova api when launching an instance it takes the following params related to networks: </div><div><br></div>
<div> curl -i <a href="http://10.34.104.185:8774/v2/d4e4332d5f8c4a8eab9fcb1345406cb0/servers">http://10.34.104.185:8774/v2/d4e4332d5f8c4a8eab9fcb1345406cb0/servers</a> -X POST <br></div><div>{<snip/> "networks": [{"port": "44f789ec-612d-46c5-befc-2706df3ab0d2"}]}}<br>
</div><div>{<snip/> "networks": [{"uuid": "e6a6b169-ce03-450b-9046-0f7b08528dde"}]}}' <-- if this is passed in nova-compute calls into quantum to create the port. <br></div><div>
<br></div><div>(I believe fixed_ip is also an option but quantum doesn't use that so i'm leaving it out)<br></div><div><br></div><div>I think moving forward we should change horizon to create a port in quantum and then pass the port-id to nova-api (thus not slowing down nova-api). In order to continue supporting the current api if a request is made passing in 'networks': [{'uuid': .. we should create the port from nova-api. Doing both of these will solve the quota issue. (Changing horizon to create the ports ahead of time will allow nova-api to not be slowed down unless someone passes in a network). </div>
<div><br></div><div><br></div><div>Then, moving forward in the nova v3 api we should only accept port's and not networks to the nova-api therefore requiring someone to create a port in quantum and pass that to nova. </div>
<div><br></div><div style>What do you guys think?</div><div style><br></div><div style>Thanks, </div><div style><br></div><div style>Aaron</div><div><br></div><div style><br></div><div><br></div><div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, May 20, 2013 at 10:55 AM, Chris Behrens <span dir="ltr"><<a href="mailto:cbehrens@codestud.com" target="_blank">cbehrens@codestud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On May 20, 2013, at 10:48 AM, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>> wrote:</div><br></div>
<blockquote type="cite"><div style="word-wrap:break-word"><br><div><div class="im"><div>On May 17, 2013, at 4:55 PM, Chris Behrens <<a href="mailto:cbehrens@codestud.com" target="_blank">cbehrens@codestud.com</a>> wrote:</div>
</div><div class="im"><blockquote type="cite"><div style="word-wrap:break-word"><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">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></div></blockquote></div></div><div class="im"><div><blockquote type="cite"><div style="word-wrap:break-word"><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></blockquote><div><br></div><div>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.</div>
<div><br></div></div></div></div></blockquote><br></div><div>Yes, this is true and I'd be fine with that as well. It seemed like the original intent was to be able to provide a failure message via the API, however. And that's the part I disagree with, because any implementation (without some sort of caching of ports, etc) will impact API response times.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>- Chris</div><div><br></div><br></font></span></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>