<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 7:39 AM, Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>
<br>
----- Original Message -----<br>
> Hi,<br>
><br>
> Sorry somehow I missed this email. I don't think you want to disable it,<br>
> though we can definitely have it run less often. The issue with disabling it<br>
> is if one of the notifications from neutron->nova never gets sent<br>
> successfully to nova (neutron-server is restarted before the event is sent<br>
> or some other internal failure). Nova will never update it's cache if the<br>
> heal_instance_info_cache_interval is set to 0.<br>
<br>
</div>The thing is, this periodic healing doesn't imply correctness either.<br>
In the case where you lose a notification and the compute node hosting<br>
the VM is hosting a non-trivial amount of VMs it can take (With the default<br>
of 60 seconds) dozens of minutes to update the cache, since you only<br>
update a VM a minute. I could understand the use of a sanity check if it<br>
was performed much more often, but as it is now it seems useless to me<br>
since you can't really rely on it.<br></blockquote><div><br></div><div>I agree with you. That's why we implemented the event callback so that the cache would be more up to date. In honesty you can probably safely disable the  heal_instance_info_cache_interval and things will probably be fine as we haven't seen many failures where events from neutron fail to send. If we find out this is the case we can definitely make the event sending notification logic in neutron much more robust by persisting events to the db and implementing retry logic on failure there to help ensure nova gets the notification. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What I'm trying to say is that with the inefficiency of the implementation,<br>
coupled with Neutron's default plugin inability to cope with a "large"<br>
amount of API calls, I feel like the disadvantages outweigh the<br>
advantages when it comes to the cache healing.<br></blockquote><div><br></div><div>Right the current heal_instance implementation has scaling issues as every compute node runs this task querying neutron. The more compute nodes you have the more querying. Hopefully the nova v3 api should solve this issue though as the networking information will no longer have to live in nova as well. So someone interested in this data network data can query neutron directly and we can avoid these type of caching issues all together :) <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
How would you feel about disabling it, optimizing the implementation<br>
(For example by introducing a new networking_for_instance API verb to Neutron?)<br>
then enabling it again?<br></blockquote><div><br></div><div>I think this is a good idea we should definitely implement something like this so nova can interface with less api calls.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><div class="h5"><br>
> The neutron->nova events help<br>
> to ensure that the nova info_cache is up to date sooner by having neutron<br>
> inform nova whenever a port's data has changed (@Joe Gordon - this happens<br>
> regardless of virt driver).<br>
><br>
> If you're using the libvirt virt driver the neutron->nova events will also be<br>
> used to ensure that the networking is 'ready' before the instance is powered<br>
> on.<br>
><br>
> Best,<br>
><br>
> Aaron<br>
><br>
> P.S: we're working on making the heal_network call to neutron a lot less<br>
> expensive as well in the future.<br>
><br>
><br>
><br>
><br>
> On Tue, May 27, 2014 at 7:25 PM, Joe Gordon < <a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Wed, May 21, 2014 at 6:21 AM, Assaf Muller < <a href="mailto:amuller@redhat.com">amuller@redhat.com</a> > wrote:<br>
><br>
><br>
> Dear Nova aficionados,<br>
><br>
> Please make sure I understand this correctly:<br>
> Each nova compute instance selects a single VM out of all of the VMs<br>
> that it hosts, and every <heal_instance_info_cache_interval> seconds<br>
> queries Neutron for all of its networking information, then updates<br>
> Nova's DB.<br>
><br>
> If the information above is correct, then I fail to see how that<br>
> is in anyway useful. For example, for a compute node hosting 20 VMs,<br>
> it would take 20 minutes to update the last one. Seems unacceptable<br>
> to me.<br>
><br>
> Considering Icehouse's Neutron to Nova notifications, my question<br>
> is if we can change the default to 0 (Disable the feature), deprecate<br>
> it, then delete it in the K cycle. Is there a good reason not to do this?<br>
><br>
> Based on the patch that introduced this function [0] you may be on to<br>
> something, but AFAIK unfortunately the neutron to nova notifications only<br>
> work in libvirt right now [1], so I don' think we can fully deprecate this<br>
> periodic task. That being said turning it off by default may be an option.<br>
> Have you tried disabling this feature and seeing what happens (in the gate<br>
> and/or in production)?<br>
><br>
<br>
</div></div>We've disabled it in a scale lab and didn't observe any black holes forming<br>
or other catastrophes.<br>
<div class=""><div class="h5"><br>
><br>
> [0] <a href="https://review.openstack.org/#/c/4269/" target="_blank">https://review.openstack.org/#/c/4269/</a><br>
> [1] <a href="https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse" target="_blank">https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse</a><br>
><br>
><br>
><br>
><br>
> Assaf Muller, Cloud Networking Engineer<br>
> Red Hat<br>
><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>
><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>
><br>
><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>
</div></div></blockquote></div><br></div></div>