Open Stack

On Fri, Jun 10, 2016 at 5:18 PM, Neil Jerram <neil at tigera.io> wrote:

> Yes, that all makes sense - thanks for explaining.
>
>     Neil
>
>
> On Fri, Jun 10, 2016 at 3:50 PM Mohammad Banikazemi <mb at us.ibm.com> wrote:
>
>> 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?
>>
>
That means going for the current version in the patch, right?


>
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> 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/72abe88a/attachment.html>