[Bug 1522130] Re: Openstack API Charms have a naive haproxy connection timeout

James Page james.page at ubuntu.com
Thu Jan 28 14:06:05 UTC 2016


** Changed in: nova-cloud-controller (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: neutron-api (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: keystone (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: glance (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: cinder (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: openstack-dashboard (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: ceph-radosgw (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: swift-proxy (Juju Charms Collection)
       Status: Fix Committed => Fix Released

** Changed in: ceilometer (Juju Charms Collection)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to cinder in Juju Charms Collection.
Matching subscriptions: charm-bugs
https://bugs.launchpad.net/bugs/1522130

Title:
  Openstack API Charms have a naive haproxy connection timeout

Status in ceilometer package in Juju Charms Collection:
  Fix Released
Status in ceph-radosgw package in Juju Charms Collection:
  Fix Released
Status in cinder package in Juju Charms Collection:
  Fix Released
Status in glance package in Juju Charms Collection:
  Fix Released
Status in keystone package in Juju Charms Collection:
  Fix Released
Status in neutron-api package in Juju Charms Collection:
  Fix Released
Status in nova-cloud-controller package in Juju Charms Collection:
  Fix Released
Status in openstack-dashboard package in Juju Charms Collection:
  Fix Released
Status in swift-proxy package in Juju Charms Collection:
  Fix Released

Bug description:
  On OpenStack API charms haproxy sets timeout connection to 1 second.
  This is reasonable only in an ideal scenario. Connections to backends
  on a busy cloud may take much longer. Even haproxy docs suggest 4 to 5
  seconds [1].

  defaults
      log global
      mode tcp
      option tcplog
      option dontlognull
      retries 3
      timeout queue 1000
      timeout connect 1000

  This causes mysterious errors like the following:

  On neutron-api:
  ConnectionRefused: Unable to establish connection to http://10.245.161.159:9696/v2.0/security-groups.json

  On keystone:
  ERROR: HTTPConnectionPool(host='10.5.51.133', port=5000): Max retries exceeded with url: /v2.0/tokens (Caused by <class 'httplib.BadStatusLine'>: '')

  On nova-cloud-controller:
  requests.exceptions.ConnectionError: HTTPConnectionPool(host='10.245.161.158', port=8774): Max retries exceeded with url: /v2/ba51369fa6444c6d9c2be7264675741f/servers/373ed532-9819-4f2b-b32a-4d27147d0338/os-interface (Caused by <class 'httplib.BadStatusLine'>: '')

  When max_retries is forced > 1 it becomes only slightly less opaque:

  urllib3.connectionpool - WARNING - Retrying (5 attempts remain) after
  connection broken by 'BadStatusLine("''",)':
  /v2/ba51369fa6444c6d9c2be7264675741f/servers/32eed1a0-6c9d-497f-b9fb-
  aac0fa748858/os-interface

  Set timeout connect (and timeout queue while we are at it) to sane
  defaults and optionally make this configurable.

  [1] https://cbonte.github.io/haproxy-
  dconv/configuration-1.5.html#4-timeout%20connect

To manage notifications about this bug go to:
https://bugs.launchpad.net/charms/+source/ceilometer/+bug/1522130/+subscriptions



More information about the Ubuntu-openstack-bugs mailing list