Open Stack

What about pinging?  BTW, from where would the pings come?

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?).

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.

Thanks,
Mike



From:   Mohammad Banikazemi/Watson/IBM at IBMUS
To:     "OpenStack Development Mailing List \(not for usage questions\)" 
<openstack-dev at lists.openstack.org>
Date:   06/10/2016 10:50 AM
Subject:        Re: [openstack-dev] [Kuryr] [Neutron] Waiting until 
Neutron Port    isActive



Hi Neil,

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,

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.

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?

Best,

Mohammad

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

From: Neil Jerram <neil at tigera.io>
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date: 06/10/2016 09:25 AM
Subject: Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port 
is Active



Hi Mohammad,

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?

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.

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.

Regards,
    Neil


On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi <mb at us.ibm.com> wrote:
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.

Here are a few options:

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.)
2- Alternatively, We could subscribe to the message queue and wait for 
such a port update event. 
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.

I was wondering if there are other and better options. 

Best,

Mohammad
__________________________________________________________________________
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
__________________________________________________________________________
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

__________________________________________________________________________
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/20160611/8d2f62af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160611/8d2f62af/attachment.gif>