<div dir="ltr">That does seem like a nice middle ground for the cache staleness. Since this behavior is needed for quantum, does it make sense to just have the API a bit more latent only for the quantum case? That is essentially what you would be doing, you just get to avoid doing the work of plumbing a new API call on the quantum side.
<div><br></div><div>-Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 1:29 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.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><div class="h5"><div>On Jun 4, 2013, at 11:48 AM, Chris Behrens <<a href="mailto:cbehrens@codestud.com" target="_blank">cbehrens@codestud.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><br><div><div>On Jun 4, 2013, at 11:11 AM, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><br><div><div>On Jun 4, 2013, at 8:38 AM, Mike Wilson <<a href="mailto:geekinutah@gmail.com" target="_blank">geekinutah@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr">Doug,<div><br></div><div>I'm glad you've brought this up. We had a similar issue to your own initially. I'm not sure our solution is the best one, but it is at least a springboard for discussion. As far as we could tell instance_nw_info is populated and cached because it is costly to generate the nw_info structure. We were seeing 5 separate calls to the quantum API to generate that structure whenever get_instance_nw_info was called. We are on Folsom, but I don't think the behavior has changed. What we ended up doing was implementing a instance_nw_info API in quantum that basically does all 5 calls in a single mysql query and returns the structure that nova wants to put together. We also patched nova to always call the quantum API instead of fetching a cache from the db. This solved two problems:</div>
<div><br></div><div>1. No stale caches</div><div>2. Reduced the number of calls going to the quantum API by 80%</div><div><br></div><div>This may not be the prettiest solution, but without it there is no way we would be able to scale quantum across a large number of nodes. Also the stale cache problem really affects usability. Maybe there is a better reason for having that sitting in the database. I'm sure people more knowledgeable than myself can chime in on this.</div>
</div></blockquote></div></div></blockquote><div><br></div><div>So that would be a call to quantum on every single 'nova show'? I find that unacceptable. Anything that increases API latency is probably not the right answer.</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><div><br></div>This seems like a reasonable approach to me, but I worry about nova list when there are a large number of instances. Perhaps a bulk get_nw_info request with a list of instance_uuids would work?</div>
</blockquote><br></div><div>I tried this before we got the info_cache in place (the single call for multiple uuids). It was horrid… but the calls were going across RPC, not HTTP, at the time. I still don't expect it to be much better with HTTP.</div>
<div><br></div><div>What is the real problem here? Isn't it that nova is returning data via nova-api that it probably shouldn't? nova doesn't need to know floating IPs in order to configure an instance, right? (obviously this must be the case, since this thread is talking about updating them via talking to quantum directly.) If this is the case, then it doesn't seem like nova-api should expose them at all. They are completely an implementation in quantum. (Or maybe that's true when nova-network goes away? :) Nova did need to configure *some* IP addresses on the instances, however, so those would be fine to expose. Nova obviously knows about them because it potentially had to inject the config.</div>
<div><br></div><div>So, my general opinion on all of this is:</div><div><br></div><div>1) nova-api should only return network information that it needed to know in order to configure the instance. nova *has* to have correct data in order to configure an instance properly.</div>
<div>2) nova should not have to query quantum to return real time status of an instance. If it has to do this, we're exposing the data in the wrong place. I heard that 'images' is being removed from nova-api in v3. Not sure if this is true or not. But perhaps there's certain network information that should be removed from v3 if it doesn't belong there.</div>
</div></blockquote><div><br></div></div></div>I think this is all fine for v3, but the fact that v2 is returning stale floating ip data is bad. So we need some solution for v2 that improves this. We could provide the potentially stale data in list/detail and force an update on get. It might be a good middle ground.</div>
<div><br></div><div>Vish</div><div><br><blockquote type="cite"><div style="word-wrap:break-word"><div><br></div><div>- Chris</div><div><br></div></div><div class="im">_______________________________________________<br>OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</div></blockquote></div><br></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>