<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div></div></div><div><blockquote type="cite" class=""><div class=""><div class="">we did not backport it due to the db migration bug but its fixed form stein on upstream.<br class="">given we have not had issue backporting <a href="https://review.opendev.org/#/c/591607/" class="">https://review.opendev.org/#/c/591607/</a> without <br class=""><a href="https://review.opendev.org/#/c/614167/20" class="">https://review.opendev.org/#/c/614167/20</a> downstream i think it would be resonable to do upstream.<br class=""></div></div></blockquote><div><br class=""></div>If it could be backported to Rocky and maybe even Queens, for those who still run Queens, I’m sure it would be strongly</div><div>appreciated (at least we would since we wouldn’t have to patch manually when we update packages)<br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""> Couldn’t it just have a configuration option to enable it? While I’m not convinced it can fix the root cause of our<br class="">problem, it could at least contribute to the stability of our and other people’s Openstack cluster.<br class=""></blockquote>so this is a subtel thing. its not really a nova bug. its an issue where invalid data is returned by neuton and that<br class="">currupts the nova database. The force refesh will heal nova if and only if the neutron issue that casue the issue in the<br class="">first place is resovled. if the neutron issue is not fix then the force refresh will contiune to force update the nova<br class="">networking info cache with incomplete data.<br class=""><br class="">so if you never have a netuon issue that returns invalid data then you will never need this patch<br class="">if you do for say because you broke the neutron policy file then this backprot will fix the nova database only<br class="">once the policy issue is corrected. we have had several large customer that have had issue with neutron due to<br class="">misconfiging the polify file or due to a third part sdn contol who maintianed port information in an external db<br class="">seperate form neutron. in the case of the policy file customer this self healing worked once they corrected the issue.<br class="">in the case of the sdn contoler customer it did not until the sdn vendor fix the sdn contols db. once it returned<br class="">correct data again the periodic task healed nova.<br class=""></div></div></blockquote><div><br class=""></div><div>That’s interesting because we run a very basic neutron + openvswitch setup with default policies. Additionally,</div><div>we have tested the nova patch I mentioned earlier for a long while and it seemed to at least prevent the instances </div><div>from losing their port. Doesn’t that imply that neutron has consistently returned correct data in our setup in particular? </div><div>So our issue could be elsewhere? I could be wrong and it’s not a hill I’m willing to die on, I’m just pointing out my own </div><div>observations.</div><br class=""><div>Jean-Philippe Méthot</div><div>Senior Openstack system administrator</div><div>Administrateur système Openstack sénior</div><div>PlanetHoster inc.</div><div>4414-4416 Louis B Mayer<br class="">Laval, QC, H7P 0G1, Canada<br class="">TEL : +1.514.802.1644 - Poste : 2644<br class="">FAX : +1.514.612.0678<br class="">CA/US : 1.855.774.4678<br class="">FR : 01 76 60 41 43<br class="">UK : 0808 189 0423</div></div><br class=""></body></html>