Skip to content
Snippets Groups Projects
  1. Dec 12, 2024
  2. Aug 12, 2024
  3. Jan 02, 2024
  4. Nov 30, 2023
  5. Jan 13, 2023
    • Matt Crees's avatar
      Add a flag to handle RabbitMQ high availability · 09df6fc1
      Matt Crees authored
      A combination of durable queues and classic queue mirroring can be used
      to provide high availability of RabbitMQ. However, these options should
      only be used together, otherwise the system will become unstable. Using
      the flag ``om_enable_rabbitmq_high_availability`` will either enable
      both options at once, or neither of them.
      
      There are some queues that should not be mirrored:
      * ``reply`` queues (these have a single consumer and TTL policy)
      * ``fanout`` queues (these have a TTL policy)
      * ``amq`` queues (these are auto-delete queues, with a single consumer)
      An exclusionary pattern is used in the classic mirroring policy. This
      pattern is ``^(?!(amq\\.)|(.*_fanout_)|(reply_)).*``
      
      Change-Id: I51c8023b260eb40b2eaa91bd276b46890c215c25
      09df6fc1
  6. Jan 05, 2023
  7. Jul 12, 2022
    • Michal Arbet's avatar
      Add api_workers for each service to defaults · 3e8db91a
      Michal Arbet authored
      Render {{ openstack_service_workers }} for workers
      of each openstack service is not enough. There are
      several services which has to have more workers because
      there are more requests sent to them.
      
      This patch is just adding default value for workers for
      each service and sets {{ openstack_service_workers }} as
      default, so value can be overrided in hostvars per server.
      Nothing changed for normal user.
      
      Change-Id: Ifa5863f8ec865bbf8e39c9b2add42c92abe40616
      3e8db91a
  8. Jun 20, 2022
  9. Jun 09, 2022
    • Will Szumski's avatar
      Add keystone_authtoken.service_type · 49006e56
      Will Szumski authored
      Fixes an issue where access rules failed to validate:
      
          Cannot validate request with restricted access rules. Set
          service_type in [keystone_authtoken] to allow access rule validation
      
      I've used the values from the endpoint. This was mostly a straight
      forward copy and paste, except:
      
      - versioned endpoints e.g cinderv3 where I stripped the version
      - monasca has multiple endpoints associated with a single service. For
        this, I concatenated logging and monitoring to be logging-monitoring.
      
      Closes-Bug: #1965111
      Change-Id: Ic4b3ab60abad8c3dd96cd4923a67f2a8f9d195d7
      49006e56
  10. May 28, 2022
    • Radosław Piliszek's avatar
      Do not use keystone_admin_url et al · 7ca9349b
      Radosław Piliszek authored
      Following up on [1].
      The 3 variables are only introducing noise after we removed
      the reliance on Keystone's admin port.
      
      [1] I5099b08953789b280c915a6b7a22bdd4e3404076
      
      Change-Id: I3f9dab93042799eda9174257e604fd1844684c1c
      7ca9349b
  11. Jun 23, 2021
    • Mark Goddard's avatar
      magnum: Add CA certificate configuration for internal TLS · 48f0957a
      Mark Goddard authored
      Magnum has various sections in its configuration file for OpenStack
      clients. When internal TLS is enabled, these may need a CA certificate
      to be specified.
      
      This change adds a CA certificate configuration, based on
      openstack_cacert, for all clients using internal endpoints.
      
      Note: we are explicitly not adding the configuration for the
      [magnum_client] ca_file and [drivers] openstack_ca_file options, since
      these use the public endpoint by default. These options may be
      provided via custom configuration if necessary.
      
      Change-Id: Ie59b3777c0a2c142b580addd67e279bc4b2f2c90
      Co-Authored-By: Kyle Dean
      Closes-Bug: #1919389
      48f0957a
    • wu.chunyang's avatar
      Remove unused region_name option · e888dabc
      wu.chunyang authored
      follow: https://review.opendev.org/c/openstack/kolla-ansible/+/791980
      Change-Id: I7231ae0b2702d56879092a2c34b7f8bb3b07f50b
      e888dabc
  12. Jun 22, 2021
  13. 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
  14. Sep 17, 2020
    • Mark Goddard's avatar
      Support TLS encryption of RabbitMQ client-server traffic · 761ea9a3
      Mark Goddard authored
      This change adds support for encryption of communication between
      OpenStack services and RabbitMQ. Server certificates are supported, but
      currently client certificates are not.
      
      The kolla-ansible certificates command has been updated to support
      generating certificates for RabbitMQ for development and testing.
      
      RabbitMQ TLS is enabled in the all-in-one source CI jobs, or when
      The Zuul 'tls_enabled' variable is true.
      
      Change-Id: I4f1d04150fb2b5af085b762890092f87ae6076b5
      Implements: blueprint message-queue-ssl-support
      761ea9a3
  15. Aug 03, 2020
    • likui's avatar
      Update conf for magnum · 908845d3
      likui authored
      Deprecated: Option "cafile" from group "keystone_authtoken" is deprecated.
      Use option "cafile" from group "keystone_auth".
      
      Change-Id: Ia372b1b73afc0bea6a68dcd156cf963c01e3f3ab
      908845d3
  16. Jul 01, 2020
    • Bharat Kunwar's avatar
      Use public interface for Magnum client and trustee Keystone interface · 78bb5942
      Bharat Kunwar authored
      While all other clients should use internalURL, the Magnum client itself
      and Keystone interface for trustee credentials should be publicly
      accessible (upstream default when no config is specified) since
      instances need to be able to reach them.
      
      Closes-Bug: #1885420
      Change-Id: I74359cec7147a80db24eb4aa4156c35d31a026bf
      78bb5942
  17. Jun 25, 2020
  18. Apr 03, 2020
  19. Jan 13, 2020
    • James Kirsch's avatar
      Configure services to use Certificate Authority · c15dc203
      James Kirsch authored
      Include a reference to the globally configured Certificate Authority to
      all services. Services use the CA to verify HTTPs connections.
      
      Change-Id: I38da931cdd7ff46cce1994763b5c713652b096cc
      Partially-Implements: blueprint support-trusted-ca-certificate-file
      c15dc203
  20. Oct 16, 2019
    • Radosław Piliszek's avatar
      Implement IPv6 support in the control plane · bc053c09
      Radosław Piliszek authored
      Introduce kolla_address filter.
      Introduce put_address_in_context filter.
      
      Add AF config to vars.
      
      Address contexts:
      - raw (default): <ADDR>
      - memcache: inet6:[<ADDR>]
      - url: [<ADDR>]
      
      Other changes:
      
      globals.yml - mention just IP in comment
      
      prechecks/port_checks (api_intf) - kolla_address handles validation
      
      3x interface conditional (swift configs: replication/storage)
      
      2x interface variable definition with hostname
      (haproxy listens; api intf)
      
      1x interface variable definition with hostname with bifrost exclusion
      (baremetal pre-install /etc/hosts; api intf)
      
      neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network
      
      basic multinode source CI job for IPv6
      
      prechecks for rabbitmq and qdrouterd use proper NSS database now
      
      MariaDB Galera Cluster WSREP SST mariabackup workaround
      (socat and IPv6)
      
      Ceph naming workaround in CI
      TODO: probably needs documenting
      
      RabbitMQ IPv6-only proto_dist
      
      Ceph ms switch to IPv6 mode
      
      Remove neutron-server ml2_type_vxlan/vxlan_group setting
      as it is not used (let's avoid any confusion)
      and could break setups without proper multicast routing
      if it started working (also IPv4-only)
      
      haproxy upgrade checks for slaves based on ipv6 addresses
      
      TODO:
      
      ovs-dpdk grabs ipv4 network address (w/ prefix len / submask)
      not supported, invalid by default because neutron_external has no address
      No idea whether ovs-dpdk works at all atm.
      
      ml2 for xenapi
      Xen is not supported too well.
      This would require working with XenAPI facts.
      
      rp_filter setting
      This would require meddling with ip6tables (there is no sysctl param).
      By default nothing is dropped.
      Unlikely we really need it.
      
      ironic dnsmasq is configured IPv4-only
      dnsmasq needs DHCPv6 options and testing in vivo.
      
      KNOWN ISSUES (beyond us):
      
      One cannot use IPv6 address to reference the image for docker like we
      currently do, see: https://github.com/moby/moby/issues/39033
      (docker_registry; docker API 400 - invalid reference format)
      workaround: use hostname/FQDN
      
      RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4.
      This is due to old RabbitMQ versions available in images.
      IPv4 is preferred by default and may fail in the IPv6-only scenario.
      This should be no problem in real life as IPv6-only is indeed IPv6-only.
      Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will
      no longer be relevant as we supply all the necessary config.
      See: https://github.com/rabbitmq/rabbitmq-server/pull/1982
      
      For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed
      to work well). Older Ansible versions are known to miss IPv6 addresses
      in interface facts. This may affect redeploys, reconfigures and
      upgrades which run after VIP address is assigned.
      See: https://github.com/ansible/ansible/issues/63227
      
      Bifrost Train does not support IPv6 deployments.
      See: https://storyboard.openstack.org/#!/story/2006689
      
      
      
      Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c
      Implements: blueprint ipv6-control-plane
      Signed-off-by: default avatarRadosław Piliszek <radoslaw.piliszek@gmail.com>
      bc053c09
  21. Aug 15, 2019
    • Rafael Weingärtner's avatar
      Standardize the configuration of "oslo_messaging" section · 22a6223b
      Rafael Weingärtner authored
      After all of the discussions we had on
      "https://review.opendev.org/#/c/670626/2", I studied all projects that
      have an "oslo_messaging" section. Afterwards, I applied the same method
      that is already used in "oslo_messaging" section in Nova, Cinder, and
      others. This guarantees that we have a consistent method to
      enable/disable notifications across projects based on components (e.g.
      Ceilometer) being enabled or disabled. Here follows the list of
      components, and the respective changes I did.
      
      * Aodh:
      The section is declared, but it is not used. Therefore, it will
      be removed in an upcomming PR.
      
      * Congress:
      The section is declared, but it is not used. Therefore, it will
      be removed in an upcomming PR.
      
      * Cinder:
      It was already properly configured.
      
      * Octavia:
      The section is declared, but it is not used. Therefore, it will
      be removed in an upcomming PR.
      
      * Heat:
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Ceilometer:
      Ceilometer publishes some messages in the rabbitMQ. However, the
      default driver is "messagingv2", and not ''(empty) as defined in Oslo;
      these configurations are defined in ceilometer/publisher/messaging.py.
      Therefore, we do not need to do anything for the
      "oslo_messaging_notifications" section in Ceilometer
      
      * Tacker:
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Neutron:
      It was already properly configured.
      
      * Nova
      It was already properly configured. However, we found another issue
      with its configuration. Kolla-ansible does not configure nova
      notifications as it should. If 'searchlight' is not installed (enabled)
      the 'notification_format' should be 'unversioned'. The default is
      'both'; so nova will send a notification to the queue
      versioned_notifications; but that queue has no consumer when
      'searchlight' is disabled. In our case, the queue got 511k messages.
      The huge amount of "stuck" messages made the Rabbitmq cluster
      unstable.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=1478274
      https://bugs.launchpad.net/ceilometer/+bug/1665449
      
      * Nova_hyperv:
      I added the same configurations as in Nova project.
      
      * Vitrage
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Searchlight
      I created a mechanism similar to what we have in AODH, Cinder, Nova,
      and others.
      
      * Ironic
      I created a mechanism similar to what we have in AODH, Cinder, Nova,
      and others.
      
      * Glance
      It was already properly configured.
      
      * Trove
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Blazar
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Sahara
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Watcher
      I created a mechanism similar to what we have in AODH, Cinder, Nova,
      and others.
      
      * Barbican
      I created a mechanism similar to what we have in Cinder, Nova,
      and others. I also added a configuration to 'keystone_notifications'
      section. Barbican needs its own queue to capture events from Keystone.
      Otherwise, it has an impact on Ceilometer and other systems that are
      connected to the "notifications" default queue.
      
      * Keystone
      Keystone is the system that triggered this work with the discussions
      that followed on https://review.opendev.org/#/c/670626/2
      
      . After a long
      discussion, we agreed to apply the same approach that we have in Nova,
      Cinder and other systems in Keystone. That is what we did. Moreover, we
      introduce a new topic "barbican_notifications" when barbican is
      enabled. We also removed the "variable" enable_cadf_notifications, as
      it is obsolete, and the default in Keystone is CADF.
      
      * Mistral:
      It was hardcoded "noop" as the driver. However, that does not seem a
      good practice. Instead, I applied the same standard of using the driver
      and pushing to "notifications" queue if Ceilometer is enabled.
      
      * Cyborg:
      I created a mechanism similar to what we have in AODH, Cinder, Nova,
      and others.
      
      * Murano
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Senlin
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Manila
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Zun
      The section is declared, but it is not used. Therefore, it will
      be removed in an upcomming PR.
      
      * Designate
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      * Magnum
      It was already using a similar scheme; I just modified it a little bit
      to be the same as we have in all other components
      
      Closes-Bug: #1838985
      
      Change-Id: I88bdb004814f37c81c9a9c4e5e491fac69f6f202
      Signed-off-by: default avatarRafael Weingärtner <rafael@apache.org>
      22a6223b
  22. Mar 06, 2019
    • Jim Rollenhagen's avatar
      Use keystone_*_url var in all configs · 2e4e6050
      Jim Rollenhagen authored
      We're duplicating code to build the keystone URLs in nearly every
      config, where we've already done it in group_vars. Replace the
      redundancy with a variable that does the same thing.
      
      Change-Id: I207d77870e2535c1cdcbc5eaf704f0448ac85a7a
      2e4e6050
  23. Aug 15, 2018
    • Murali Annamneni's avatar
      Include default_docker_volume_type for magnum.conf · e1c5bbd9
      Murali Annamneni authored
      To create a magnum cluster, its required to specify
      'default_docker_volume_type' with some default value (default cinder
       volume type). And, it also enables users to select
      diffferent cinder volume types for their volumes.
      
      Change-Id: I50b4c436875e4daac48a14fc1e119136eb5fd844
      e1c5bbd9
  24. Aug 07, 2018
  25. Jun 01, 2018
    • Zhangfei Gao's avatar
      osprofiler support redis · ce809aea
      Zhangfei Gao authored
      Currently osprofiler only choose elasticsearch,
      which is only supported on x86.
      On other platform like aarch64 osprofiler can
      not be used since no elasticsearch package.
      
      Enable osprofiler by enable_osprofiler: "yes",
      which choose elasticsearch by default.
      Choose redis by enable_redis: "yes" & osprofiler_backend: "redis"
      On platform without elasticsearch support like aarch64
      set enable_elasticsearch: "no"
      
      Change-Id: I68fe7a33e11d28684962fc5d0b3d326e90784d78
      ce809aea
  26. Apr 18, 2018
    • Kevin TIBI's avatar
      Fix SSL api for multiple services · a81a5d5d
      Kevin TIBI authored
      If SSL is enabled, api of multiple services returns
      wrong external URL without https prefix.
      
      Removal of condition for deletion of http  header.
      
      Change-Id: I4264e04d0d6b9a3e11ef7dd7add6c5e166cf9fb4
      Closes-Bug: #1749155
      Closes-Bug: #1717491
      a81a5d5d
  27. Mar 09, 2018
    • ZhongShengping's avatar
      Duplicated [oslo_policy] · af87ad7c
      ZhongShengping authored
      Remove duplicated [oslo_policy] in magnum.conf.
      
      Change-Id: I69c82e31d7041d7e8f9c31ba1bf54f0906f2a6dc
      Closes-Bug: #1754593
      af87ad7c
  28. Jan 22, 2018
  29. Jan 12, 2018
  30. Nov 22, 2017
    • Andrew Smith's avatar
      Add support for hybrid messaging backends · fd1d3af0
      Andrew Smith authored
      This commit separates the messaging rpc and notify transports in order
      to support separate and different oslo.messaging backends
      
      This patch:
      * add rpc and notify variables
      * update service role conf templates
      * add example to globals.yaml
      * add release note
      
      Implements: blueprint hybrid-messaging
      Change-Id: I34691c2895c8563f1f322f0850ecff98d11b5185
      fd1d3af0
  31. Jul 13, 2017
  32. Jul 06, 2017
  33. Jul 04, 2017
    • Bertrand Lallau's avatar
      Magnum: update clients config groups · fdc75cdd
      Bertrand Lallau authored
      * add additional options called 'endpoint_type' for each of config groups
      related to openstack clients used by Magnum.
      * add Glance, Neutron and Nova config groups.
      
      Change-Id: Ie74979e05c4f5763674ba2fc5b9f07bd51ad9454
      fdc75cdd
  34. Jun 02, 2017
  35. May 23, 2017
  36. Apr 12, 2017
  37. Mar 10, 2017
  38. Jan 24, 2017
Loading