Open Stack

On Sat, Jun 11, 2016 at 3:03 PM, Mike Spreitzer <mspreitz at us.ibm.com> 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 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
>
> [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 <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*
> <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://OpenStack-dev-request@lists.openstack.org?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: OpenStack-dev-request at lists.openstack.org?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: 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/20160612/5b1153ec/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/20160612/5b1153ec/attachment.gif>