<div dir="ltr">As for the notifier proposed above it is correct that neutron needs to be changed. This should not be a massive amount of work. Today it works with nova only pretty much because nova it's the only compute service it interacts with.<div><br></div><div>The question brought aboud ping vs operational status is a very good one.</div><div>In neutron status=UP for a port only means that L2 wiring (at least for most plugins) occurred on the port. Networking might not yet be fully ready.</div><div>I know some plugins - like ML2 - are adding (or have recently added) mechanism to improve this situation.</div><div><br></div><div>Pinging a port might seem the most reliable way of knowing whether a port is up but this has issues:</div><div>- false positives (or negatives according to which event you are trying to verify!)</div><div>- security groups getting in the way</div><div>- need to be able to reach container interfaces, which might lead to have "health checking agents" to implement this.</div><div><br></div><div>I think that if:</div><div>- you are not using DHCP</div><div>- you can clear identify the sets of ports you are waiting on</div><div>- you are using the ML2-based reference implementation (or any other impl which does not do round-trips to the backend on GET operations)</div><div><br></div><div>You should be ok with polling. I'm not sure however if a backoff mechanisms is applicable in this case.</div><div><br></div><div>Salvatore</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 June 2016 at 21:00, Rick Jones <span dir="ltr"><<a href="mailto:rick.jones2@hpe.com" target="_blank">rick.jones2@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/10/2016 03:13 PM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Polling should be fine. get_port operations a relatively cheap operation<br>
for Neutron.<br>
</blockquote>
<br></span>
Just in principle, I would suggest this polling have a back-off built into it.  Poll once, see the port is not yet "up" - wait a semi-random short length of time,  poll again, see it is not yet "up" wait a longer semi-random length of time, lather, rinse, repeat until you've either gotten to the limits of your patience or the port has become "up."<br>
<br>
Fixed, short poll intervals can run the risk of congestive collapse "at scale."<span class="HOEnZb"><font color="#888888"><br>
<br>
rick jones</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>