[openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port isActive

Mohammad Banikazemi mb at us.ibm.com
Fri Jun 10 14:49:16 UTC 2016


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



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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160610/18da1ae0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160610/18da1ae0/attachment.gif>


More information about the OpenStack-dev mailing list