Skip to content
Snippets Groups Projects
  1. Sep 29, 2020
  2. Sep 28, 2020
  3. Sep 25, 2020
  4. Sep 24, 2020
  5. Sep 23, 2020
  6. Sep 22, 2020
    • Pierre Riteau's avatar
      Reduce the use of SQLAlchemy connection pooling · c8177202
      Pierre Riteau authored
      When the internal VIP is moved in the event of a failure of the active
      controller, OpenStack services can become unresponsive as they try to
      talk with MariaDB using connections from the SQLAlchemy pool.
      
      It has been argued that OpenStack doesn't really need to use connection
      pooling with MariaDB [1]. This commit reduces the use of connection
      pooling via two configuration options:
      
      - max_pool_size is set to 1 to allow only a single connection in the
        pool (it is not possible to disable connection pooling entirely via
        oslo.db, and max_pool_size = 0 means unlimited pool size)
      - lower connection_recycle_time from the default of one hour to 10
        seconds, which means the single connection in the pool will be
        recreated regularly
      
      These settings have shown better reactivity of the system in the event
      of a failover.
      
      [1] http://lists.openstack.org/pipermail/openstack-dev/2015-April/061808.html
      
      Change-Id: Ib6a62d4428db9b95569314084090472870417f3d
      Closes-Bug: #1896635
      c8177202
    • Radosław Piliszek's avatar
      Fix default mode in haproxy_single_service_split · a45ef7cc
      Radosław Piliszek authored
      haproxy_single_service_listen (the default template) was already fine.
      
      Closes-Bug: #1896591
      TrivialFix
      
      Change-Id: Id68fe19ea87565aa36fb74f2a2ca66cb951169f6
      a45ef7cc
    • Michal Nasiadka's avatar
      Allow setting container_proxy per service · f257e79a
      Michal Nasiadka authored
      Currently there is no option to set container_proxy only for one service
      (e.g. magnum). This change adds this option.
      
      Change-Id: Ia938ee660ebe8ce84321f721b6292b0b58a06e20
      f257e79a
  7. Sep 21, 2020
  8. Sep 18, 2020
  9. Sep 17, 2020
  10. Sep 14, 2020
  11. Sep 12, 2020
    • Radosław Piliszek's avatar
      [CI] Ensure network is set for Zun · 7a3072e9
      Radosław Piliszek authored
      If we don't set it, then Zun chooses one randomly (the first one
      from Neutron).
      This may break if it is a network that is not available on
      target hosts, e.g. external via L3 agent router.
      
      Since capsules do not support nets yet [1], this patch ensures
      desired network creation order in init-runonce instead.
      
      [1] https://bugs.launchpad.net/zun/+bug/1895263
      
      Change-Id: Iaa113dcfb826164a2772d2c91d34ec0236be0817
      7a3072e9
  12. Sep 10, 2020
Loading