Skip to content
Snippets Groups Projects
  1. Apr 19, 2021
    • Doug Szumski's avatar
      Extend support for custom Grafana dashboards · d01192c1
      Doug Szumski authored
      The current behaviour is to support supplying a single
      folder of Grafana dashboards which can then be populated
      into a single folder in Grafana. Some users may wish
      to have sub-folders of Dashboards, and load these into
      separate dashboard folders in Grafana via a custom
      provisioning file. For example, a user may have a
      sub-folder of Ceph dashboards that they wish to keep
      separate from OpenStack dashboards. This patch supports
      sub-folders whilst not affecting the original mechanism.
      
      Trivial-Fix
      
      Change-Id: I9cd289a1ea79f00cee4d2ef30cbb508ac73f9767
      d01192c1
  2. Apr 12, 2021
  3. Apr 08, 2021
  4. Apr 07, 2021
    • Michal Arbet's avatar
      Refactor mariadb to support shards · 09b3c6ca
      Michal Arbet authored
      
      Kolla-ansible is currently installing mariadb
      cluster on hosts defined in group['mariadb']
      and render haproxy configuration for this hosts.
      
      This is not enough if user want to have several
      service databases in several mariadb clusters (shards).
      
      Spread service databases to multiple clusters (shards)
      is usefull especially for databases with high load
      (neutron,nova).
      
      How it works ?
      
      It works exactly same as now, but group reference 'mariadb'
      is now used as group where all mariadb clusters (shards)
      are located, and mariadb clusters are installed to
      dynamic groups created by group_by and host variable
      'mariadb_shard_id'.
      
      It also adding special user 'shard_X' which will be used
      for creating users and databases, but only if haproxy
      is not used as load-balance solution.
      
      This patch will not affect user which has all databases
      on same db cluster on hosts in group 'mariadb', host
      variable 'mariadb_shard_id' is set to 0 if not defined.
      
      Mariadb's task in loadbalancer.yml (haproxy) is configuring
      mariadb default shard hosts as haproxy backends. If mariadb
      role is used to install several clusters (shards), only
      default one is loadbalanced via haproxy.
      
      Mariadb's backup is working only for default shard (cluster)
      when using haproxy as mariadb loadbalancer, if proxysql
      is used, all shards are backuped.
      
      After this patch will be merged, there will be way for proxysql
      patches which will implement L7 SQL balancing based on
      users and schemas.
      
      Example of inventory:
      
      [mariadb]
      server1
      server2
      server3 mariadb_shard_id=1
      server4 mariadb_shard_id=1
      server5 mariadb_shard_id=2
      server6 mariadb_shard_id=3
      
      Extra:
      wait_for_loadbalancer is removed instead of modified as its role
      is served by check already. The relevant refactor is applied as
      well.
      
      Change-Id: I933067f22ecabc03247ea42baf04f19100dffd08
      Co-Authored-By: default avatarRadosław Piliszek <radoslaw.piliszek@gmail.com>
      09b3c6ca
    • Mark Goddard's avatar
      masakari: fix minor issues with instance monitor · 0b0dd358
      Mark Goddard authored
      * Don't generate masakari.conf for instance monitor
      * Don't generate masakari-monitors.conf for API or engine
      * Use a consistent name for dimensions -
        masakari_instancemonitor_dimensions
      * Fix source code paths in dev mode
      
      Change-Id: I551f93c9bf1ad6712b53c316074ae1df84e4352b
      0b0dd358
  5. Apr 06, 2021
  6. Mar 30, 2021
  7. Mar 26, 2021
  8. Mar 25, 2021
  9. Mar 24, 2021
  10. Mar 16, 2021
    • Bartosz Bezak's avatar
      Add support for custom grafana dashboards · a9e30382
      Bartosz Bezak authored
      Allow users to import custom grafana dashboards.
      Dashboards as JSON files should be placed into
      "{{ node_custom_config }}/grafana/dashboards/" folder.
      
      Change-Id: Id0f83b8d08541b3b74649f097b10c9450201b426
      a9e30382
    • Doug Szumski's avatar
      Upgrade service configuration for ELK 7 · c2e08be4
      Doug Szumski authored
      ELK 7 requires some minor changes from the existing ELK 6 config.
      
      Depends-On: Icfa3db5788b25f70ee75411dbaf20d8d4a6a734b
      Change-Id: I9815d202a77da0477aea43d714a5def8a24724fa
      c2e08be4
  11. Mar 15, 2021
  12. Mar 13, 2021
  13. Mar 11, 2021
    • Mark Goddard's avatar
      Disable Docker iptables and bridge networking by default · aec027c4
      Mark Goddard authored
      In I165199fc98fb98f227f2a20284e1bab03ef65b5b and
      Ic745300b27e50132d80d03787fa4abfada2d0173 we provided flags to disable
      Docker's control of iptables and bridge networking respectively. The
      original behaviour was maintained for backwards compatibility, to allow
      the patches to be backported.
      
      This patch changes the default behaviour to disable the manipulation of
      iptables and disabling bridge networking.
      
      Related-Bug: #1849275
      Related-Bug: #1848249
      
      Change-Id: I4e8206f13a847ff79e06c36d22068597458b6c3d
      aec027c4
    • Dincer Celik's avatar
      [docker] Added a new flag to disable default network · 4053a0af
      Dincer Celik authored
      Docker is using 172.17.0.0/16 by default for bridge networking on
      docker0, and this might cause routing problems for operator networks.
      
      This change introduces docker_disable_default_network to disable the
      bridge networking by putting "bridge: none"[1] to daemon.json
      
      Bridge networking does not work without iptables, so we set the default
      for docker_disable_default_network to
      docker_disable_default_iptables_rules.
      
      For better defaults, this feature will be enabled by default in
      Wallaby.
      
      [1] https://docs.docker.com/engine/reference/commandline/dockerd/
      
      Change-Id: Ic745300b27e50132d80d03787fa4abfada2d0173
      Closes-Bug: #1848249
      Related-Bug: #1849275
      4053a0af
    • LinPeiWen's avatar
      Use Docker healthchecks for elasticsearch services · 10f79eda
      LinPeiWen authored
      This change enables the use of Docker healthchecks for elasticsearch services.
      Implements: blueprint container-health-check
      
      Change-Id: Ib50d56cc206a80b20a4f96e95bcdd8d11269234f
      10f79eda
    • LinPeiWen's avatar
      Use Docker healthchecks for kibana services · 28dbde6a
      LinPeiWen authored
      This change enables the use of Docker healthchecks for kibana services.
      Implements: blueprint container-health-check
      
      Change-Id: If7525e193c245435410b4071aed6d3b566424219
      28dbde6a
  14. Mar 10, 2021
  15. Mar 09, 2021
    • wuchunyang's avatar
      Use User and Group variables instead of sudo · 13b6d692
      wuchunyang authored
      use User and Group in octavia-interface service.
      this way looks more graceful
      
      this change also fix the octavia-interface does not restart
      when the octavia-interface.service changed.
      
      Change-Id: I9d253d7519b1774985d165a080047fdbecd321b4
      13b6d692
  16. Mar 08, 2021
  17. Mar 07, 2021
  18. Mar 05, 2021
    • Pierre Riteau's avatar
      Remove whitespace around equal signs in zookeeper.cfg · 2b723ead
      Pierre Riteau authored
      The merge_configs action plugin is updated with an option to control
      whether whitespace should be used around equal signs. The default
      remains to use whitespace: only zookeeper.cfg doesn't use them.
      
      This is to avoid issues with the zkCleanup.sh script which expects no
      whitespace. The ZooKeeper documentation also uses no whitespace in
      configuration file examples.
      
      Change-Id: Ia082a1c002cc4e8b04f7696fdee827b747c6d13f
      Closes-Bug: #1917490
      2b723ead
  19. Mar 04, 2021
    • Doug Szumski's avatar
      Add variable for changing Apache HTTP timeout · 647ff667
      Doug Szumski authored
      In services which use the Apache HTTP server to service HTTP requests,
      there exists a TimeOut directive [1] which defaults to 60 seconds. APIs
      which come under heavy load, such as Cinder, can sometimes exceed this
      which results in a HTTP 504 Gateway timeout, or similar. However, the
      request can still be serviced without error. For example, if Nova calls
      the Cinder API to detach a volume, and this operation takes longer
      than the shortest of the two timeouts, Nova will emit a stack trace
      with a 504 Gateway timeout. At some time later, the request to detach
      the volume will succeed. The Nova and Cinder DBs then become
      out-of-sync with each other, and frequently DB surgery is required.
      
      Although strictly this category of bugs should be fixed in OpenStack
      services, it is not realistic to expect this to happen in the short
      term. Therefore, this change makes it easier to set the Apache HTTP
      timeout via a new variable.
      
      An example of a related bug is here:
      
      https://bugs.launchpad.net/nova/+bug/1888665
      
      Whilst this timeout can currently be set by overriding the WSGI
      config for individual services, this change makes it much easier.
      
      Change-Id: Ie452516655cbd40d63bdad3635fd66693e40ce34
      Closes-Bug: #1917648
      647ff667
    • Doug Szumski's avatar
      Support bypassing Monasca Log API for control plane logs · ca1a80ab
      Doug Szumski authored
      This change allows a user to forward control plane logs
      directly to Elasticsearch from Fluentd, rather than via
      the Monasca Log API when Monasca is enabled. The Monasca
      Log API can continue to handle tenant logs.
      
      For many use cases this is simpler, reduces resource
      consumption and helps to decouple control plane logging
      services from tenant logging services.
      
      It may not always be desired, so is optional and off by
      default.
      
      Change-Id: I195e8e4b73ca8f573737355908eb30a3ef13b0d6
      ca1a80ab
    • Doug Szumski's avatar
      Support disabling Monasca alerting pipeline · 44409784
      Doug Szumski authored
      The Monasca alerting pipeline provides multi-tenancy alerts and
      notifications. It runs as an Apache Storm topology and generally
      places a significant memory and CPU burden on monitoring hosts,
      particularly when there are lot of metrics. This is fine if the
      alerting service is in use, but sometimes it is not. For example
      you may use Prometheus for monitoring the control plane, and
      wish to offer tenants a monitoring service via Monasca without
      alerting and notification functionality. In this case it makes
      sense to disable this part of the Monasca pipeline and this patch
      adds support for that.
      
      If the service is ever re-enabled, all alerts and notifications
      should spawn back automatically since they are persisted in the
      central mysql database cluster.
      
      Change-Id: I84aa04125c621712f805f41c8efbc92c8e156db9
      44409784
  20. Mar 03, 2021
    • Doug Szumski's avatar
      Disable Monasca Log Metrics service by default · a52d6612
      Doug Szumski authored
      The Log Metrics service is an admin only service. We now have
      support in Fluentd via the Prometheus plugin to create metrics
      from logs. These metrics can be scraped into Monasca or Prometheus.
      It therefore makes sense to deprecate this service, starting by
      disabling it by default, and then removing it in the Xena release.
      This should improve the stability of the Monasca metrics pipeline
      by ensuring that all metrics pass via the Monasca API for
      validation, and ensure that metrics generated from logs are
      available to both Prometheus and Monasca users by default.
      
      Change-Id: I704feb4434c1eece3eb00c19dc5f934fd4bc27b4
      a52d6612
Loading