On Sat, Jun 11, 2016 at 3:03 PM, Mike Spreitzer <[email protected]> wrote:
> 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?). Well, with a label you can make the Neutron Port have an SG that forbids pinging. > > > 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. This is the reason I'd lean against using pinging. I think using get_port should do it for now. > > > Thanks, > Mike > > > > From: Mohammad Banikazemi/Watson/IBM@IBMUS > To: "OpenStack Development Mailing List \(not for usage > questions\)" <[email protected]> > 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 > > [image: 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]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 <[email protected]> > To: "OpenStack Development Mailing List (not for usage questions)" < > [email protected]> > 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 <*[email protected]* > <[email protected]>> 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: > *[email protected]?subject:unsubscribe* > <http://[email protected]?subject:unsubscribe> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev* > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
