I believe in this particular case it will just be doing get_port for the specific ports it is waiting to boot. Not polling every ports status for the lifetime of the port.
On Fri, Jun 10, 2016 at 11:52 PM, Gary Kotton <gkot...@vmware.com> wrote: > Hi, > If this is a handful of get_port then it is ok. If is is list_ports, where > provider network information has to be updated, that is very heavy on the > system. Today nova does a ton of polling to Neutron. That sometimes leads > to spikes in CPU. In addition to this there is the side affect of the log > file of Neutron being full and one may miss some critical logs. > Thanks > Gary > > From: Kevin Benton <ke...@benton.pub> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Saturday, June 11, 2016 at 1:13 AM > To: OpenStack List <openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port > isActive > > Polling should be fine. get_port operations a relatively cheap operation > for Neutron. > > Maybe for the future we can have a more pluggable version of the nova > callback notifier we have in Neutron like Salvatore pointed out. > > On Fri, Jun 10, 2016 at 7:49 AM, Mohammad Banikazemi <m...@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? >> >> 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 <n...@tigera.io> >> To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@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 <*m...@us.ibm.com* >> <m...@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-requ...@lists.openstack.org?subject:unsubscribe* >> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev