Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160610/1898fd11/attachment.html>