Open Stack

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.

The question brought aboud ping vs operational status is a very good one.
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.
I know some plugins - like ML2 - are adding (or have recently added)
mechanism to improve this situation.

Pinging a port might seem the most reliable way of knowing whether a port
is up but this has issues:
- false positives (or negatives according to which event you are trying to
verify!)
- security groups getting in the way
- need to be able to reach container interfaces, which might lead to have
"health checking agents" to implement this.

I think that if:
- you are not using DHCP
- you can clear identify the sets of ports you are waiting on
- you are using the ML2-based reference implementation (or any other impl
which does not do round-trips to the backend on GET operations)

You should be ok with polling. I'm not sure however if a backoff mechanisms
is applicable in this case.

Salvatore




On 13 June 2016 at 21:00, Rick Jones <rick.jones2 at hpe.com> wrote:

> On 06/10/2016 03:13 PM, Kevin Benton wrote:
>
>> Polling should be fine. get_port operations a relatively cheap operation
>> for Neutron.
>>
>
> 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."
>
> Fixed, short poll intervals can run the risk of congestive collapse "at
> scale."
>
> rick jones
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160613/ae2c439a/attachment-0001.html>