<font size=2 face="sans-serif">What about pinging? BTW, from where
would the pings come?</font><br><br><font size=2 face="sans-serif">In the Docker/Swarm API today there
is no way to disable ping. However, once Kuryr's libnetwork plugin
is updated so that `docker network connect --ip=W.X.Y.Z ...` will latch
onto a matching pre-existing Neutron Port, if it exists, there will be
a way for a user to disable pings (right?).</font><br><br><font size=2 face="sans-serif">In the Kubernetes API there is now a
way to do something like security groups, it is called NetworkPolicy; it
is not yet well defined enough to say whether it gives the user a way to
disable pings.</font><br><br><font size=2 face="sans-serif">Thanks,<br>Mike</font><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Mohammad Banikazemi/Watson/IBM@IBMUS</font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"OpenStack Development
Mailing List \(not for usage questions\)" <openstack-dev@lists.openstack.org></font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">06/10/2016 10:50 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [openstack-dev]
[Kuryr] [Neutron] Waiting until Neutron Port isActive</font><br><hr noshade><br><br><br><font size=3>Hi Neil,<br><br>Currently, when a docker libnetwork "join" operation in Kuryr
is returned, it is not guaranteed that the network connectivity has been
established. There are containers that check for network connectivity as
the first thing they do when they come up and under heavy load some notice
there is no connectivity and simply bail out. I am trying to deal with
such a use case,<br><br>Thanks for pointing out that option 2 won't work for you. I think Salvatore
also alluded to that in his response. What you are suggesting with pinging
the container from the appropriate namespace may be worth a try but then
there may be containers that do not allow ingress traffic while they are
up and happy. So short of what Salvatore suggested in his earlier email
(and I am not sure if that can be done without additions to Neutron), we
are left with option 1.<br><br>Keep in mind that users can choose not to enable the blocking option and
things will be as they are right now. Would that be reasonable?<br><br>Best,<br><br>Mohammad<br><br></font><img src=cid:_1_B2433680B2432F480047BCE585257FCF alt="Inactive hide details for Neil Jerram ---06/10/2016 09:25:59 AM---Hi Mohammad, Why is the blocking needed? Is it to report som" style="border:0px solid;"><font size=3 color=#424282>Neil
Jerram ---06/10/2016 09:25:59 AM---Hi Mohammad, Why is the blocking needed?
Is it to report some kind of status back to</font><font size=3><br></font><font size=2 color=#5f5f5f><br>From: </font><font size=2>Neil Jerram <neil@tigera.io></font><font size=2 color=#5f5f5f><br>To: </font><font size=2>"OpenStack Development Mailing List (not for
usage questions)" <openstack-dev@lists.openstack.org></font><font size=2 color=#5f5f5f><br>Date: </font><font size=2>06/10/2016 09:25 AM</font><font size=2 color=#5f5f5f><br>Subject: </font><font size=2>Re: [openstack-dev] [Kuryr] [Neutron] Waiting
until Neutron Port is Active</font><font size=3><br></font><hr noshade><font size=3><br><br></font><font size=4><br>Hi Mohammad,</font><font size=3><br></font><font size=4><br>Why is the blocking needed? Is it to report some kind of status back
to Docker/Kubernetes, or to allow some follow-on action to happen?</font><font size=3><br></font><font size=4><br>When using networking-calico as the driver, I think that only option (1)
would work, out of the options you've suggested below. (3) doesn't
work, as you say, because Calico doesn't involve an L2 agent. Also
Calico doesn't use the RPC message queue for reporting port status, because
we've found that that message queue is in itself a scalability bottleneck.</font><font size=3><br></font><font size=4><br>I guess another option would be for the using system to determine for itself
when the port appears to be working, e.g. by the host pinging the container/pod's
IP address.</font><font size=3><br></font><font size=4><br>Regards,<br> Neil</font><font size=3><br><br></font><font size=4><br>On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi <</font><a href=mailto:mb@us.ibm.com><font size=4 color=blue><u>mb@us.ibm.com</u></font></a><font size=4>>
wrote:</font><br><font size=4>For the Kuryr project, in order to support blocking until
vifs are plugged in (that is adding config options similar to the following
options define in Nova: vif_plugging_is_fatal and vif_plugging_timeout),
we need to detect that the Neutron plugin being used is done with plugging
a given vif.<br><br>Here are a few options:<br><br>1- The simplest approach seems to be polling for the status of the Neutron
port to become Active. (This may lead to scalability issues but short of
having a specific goal for scalability, it is not clear that will be the
case.)<br>2- Alternatively, We could subscribe to the message queue and wait for
such a port update event. <br>3- It was also suggested that we could use l2 agent extension to detect
such an event but that seems to limit us to certain Neutron plugins and
therefore not acceptable.<br><br>I was wondering if there are other and better options. <br><br>Best,<br><br>Mohammad<br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: </font><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target=_blank><font size=4 color=blue><u>OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</u></font></a><font size=3 color=blue><u><br></u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target=_blank><font size=4 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><tt><font size=3>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</font></tt><tt><font size=3 color=blue><u><br></u></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=3 color=blue><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></tt></a><font size=3><br></font><p><tt><font size=2>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br></font></tt><p><p><BR>