Open Stack

In fact, nova should be careful about changing number of retries for
neutron client.
It's known that under significant load (people test serial VM creation)
neutron client may timeout on POST operation which does port creation;
retrying this again leads to multiple fixed IPs assigned to a VM

Thanks,
Eugene.


On Wed, May 28, 2014 at 12:09 AM, Kyle Mestery <mestery at noironetworks.com>wrote:

> I'm not aware of any such change at the moment, no.
>
> On Tue, May 27, 2014 at 3:06 PM, Paul Ward <wpward at us.ibm.com> wrote:
> > Great!  Do you know if there's any corresponding nova changes to support
> > this as a conf option that gets passed in to this new parm?
> >
> >
> >
> > Kyle Mestery <mestery at noironetworks.com> wrote on 05/27/2014 01:56:12
> PM:
> >
> >> From: Kyle Mestery <mestery at noironetworks.com>
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> <openstack-dev at lists.openstack.org>,
> >> Date: 05/27/2014 02:00 PM
> >> Subject: Re: [openstack-dev] [neutron] Supporting retries in
> neutronclient
> >
> >
> >>
> >> On Tue, May 27, 2014 at 12:48 PM, Paul Ward <wpward at us.ibm.com> wrote:
> >> > Currently, neutronclient is hardcoded to only try a request once in
> >> > retry_request by virtue of the fact that it uses self.retries as the
> >> > retry
> >> > count, and that's initialized to 0 and never changed.  We've seen an
> >> > issue
> >> > where we get an ssl handshaking error intermittently (seems like more
> of
> >> > an
> >> > ssl bug) and a retry would probably have worked.  Yet, since
> >> > neutronclient
> >> > only tries once and gives up, it fails the entire operation.  Here is
> >> > the
> >> > code in question:
> >> >
> >> > https://github.com/openstack/python-neutronclient/blob/master/
> >> neutronclient/v2_0/client.py#L1296
> >> >
> >> > Does anybody know if there's some explicit reason we don't currently
> >> > allow
> >> > configuring the number of retries?  If not, I'm inclined to propose a
> >> > change
> >> > for just that.
> >> >
> >> There is a review to address this in place now [1]. I've given a -1
> >> due to a trivial reason which I hope Jakub will address soon so we can
> >> land this patch in the client code.
> >>
> >> Thanks,
> >> Kyle
> >>
> >> [1] https://review.openstack.org/#/c/90104/
> >>
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20140528/80566896/attachment.html>