Skip to content
Snippets Groups Projects
  1. Dec 16, 2024
    • Pierre Riteau's avatar
      Avoid double quotes in HAProxy configuration · 3f7787cf
      Pierre Riteau authored
      This avoids generating HAProxy configuration for Keystone that contains
      double quotes. Although not invalid, it is unlike the rest of the
      configuration.
      
      Change-Id: I49bf9a45b8d926f85a4c2bc3308d0f1fd698309a
      (cherry picked from commit 20cc842f)
      3f7787cf
  2. Oct 26, 2024
  3. Sep 12, 2024
  4. Sep 03, 2024
    • Roman Krček's avatar
      Refactor dev mode · b3275272
      Roman Krček authored
      Build upon changes in kolla which change strategy of installing projects
      in containers when in dev mode. This fixes problems where when package
      file manifest changes, the changes were not reflected in to
      devmode-enabled container.
      
      It changes the strategy of installing projects in dev mode in containers.
      Instead of bind mounting the project's git repository to the venv
      of the container, the repository is bind mounted to
      /dev-mode/<project_name> from which the it is installed using pip
      on every startup of the container using kolla_install_projects script.
      
      Also updates docs to reflect the changes.
      
      Depends-On: https://review.opendev.org/c/openstack/kolla/+/925712
      
      
      Closes-Bug: #1814515
      Singed-off-by: default avatarRoman Krček <roman.krcek@tietoevry.com>
      Change-Id: If191cd0e3fcf362ee058549a1b6c244d109b6d9a
      b3275272
  5. Jul 19, 2024
    • Michal Arbet's avatar
      Add support for docker_image_name_prefix · ae86e3a0
      Michal Arbet authored
      The Kolla project supports building images with
      user-defined prefixes. However, Kolla-ansible is unable
      to use those images for installation.
      
      This patch fixes that issue.
      
      Closes-Bug: #2073541
      Change-Id: Ia8140b289aa76fcd584e0e72686e3786215c5a99
      ae86e3a0
  6. Mar 21, 2024
  7. Mar 15, 2024
  8. Dec 28, 2023
  9. Nov 15, 2023
  10. Oct 06, 2023
  11. Jun 28, 2023
  12. Dec 21, 2022
    • Matt Crees's avatar
      Integrate oslo-config-validator · 6c2aace8
      Matt Crees authored
      Regularly, we experience issues in Kolla Ansible deployments because we
      use wrong options in OpenStack configuration files. This is because
      OpenStack services ignore unknown options. We also need to keep on top
      of deprecated options that may be removed in the future. Integrating
      oslo-config-validator into Kolla Ansible will greatly help.
      
      Adds a shared role to run oslo-config-validator on each service. Takes
      into account that services have multiple containers, and these may also
      use multiple config files. Service roles are extended to use this shared
      role. Executed with the new command ``kolla-ansible validate-config``.
      
      Change-Id: Ic10b410fc115646d96d2ce39d9618e7c46cb3fbc
      6c2aace8
  13. Oct 03, 2022
    • Jakub Darmach's avatar
      Keystone OIDC JWKS fix · 98929761
      Jakub Darmach authored
      JWT failed to validate on auth-oidc endpoint used by openstack cli
      with "could not find key with kid: XX" error. To fix this we need
      to use jwks provided in "jwks_uri" by OIDC metadata endpoint.
      
      Missing "ServerName" directive from vhost config causes redirection
      to fail in some cases when external tls is enabled.
      
        - added "keystone_federation_oidc_jwks_uri" variable
        - added "OIDCOAuthVerifyJwksUri" to keystone vhost config
        - added "ServerName" to keystone vhost config
        - jinja templating additional whitespace trimmed to
          correct end result indentation and empty newlines
      
      Closes-bug: 1990375
      Change-Id: I4f5c1bd8be8e23cf6299ca4bdfd79e9d98c9a9eb
      98929761
  14. Sep 26, 2022
  15. Sep 21, 2022
  16. Aug 09, 2022
  17. 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
  18. 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
  19. May 26, 2022
  20. May 23, 2022
  21. May 17, 2022
  22. Apr 20, 2022
  23. Mar 22, 2022
  24. Feb 23, 2022
  25. Dec 31, 2021
    • Pierre Riteau's avatar
      Move project_name and kolla_role_name to role vars · 56fc74f2
      Pierre Riteau authored
      Role vars have a higher precedence than role defaults. This allows to
      import default vars from another role via vars_files without overriding
      project_name (see related bug for details).
      
      Change-Id: I3d919736e53d6f3e1a70d1267cf42c8d2c0ad221
      Related-Bug: #1951785
      56fc74f2
  26. Aug 17, 2021
    • Michal Arbet's avatar
      Use Docker healthchecks for keystone-fernet container · 90fd9152
      Michal Arbet authored
      This change enables the use of Docker healthchecks for
      keystone-fernet container. It checks if "key 0" has
      right permissions, and if rsync is able to distribute
      keys to other keystones.
      
      Implements: blueprint container-health-check
      Change-Id: I17bea723d4109e869cd05d211f6f8e4653f46e17
      90fd9152
  27. Jun 23, 2021
    • Mark Goddard's avatar
      Use ansible_facts to reference facts · ade5bfa3
      Mark Goddard authored
      By default, Ansible injects a variable for every fact, prefixed with
      ansible_. This can result in a large number of variables for each host,
      which at scale can incur a performance penalty. Ansible provides a
      configuration option [0] that can be set to False to prevent this
      injection of facts. In this case, facts should be referenced via
      ansible_facts.<fact>.
      
      This change updates all references to Ansible facts within Kolla Ansible
      from using individual fact variables to using the items in the
      ansible_facts dictionary. This allows users to disable fact variable
      injection in their Ansible configuration, which may provide some
      performance improvement.
      
      This change disables fact variable injection in the ansible
      configuration used in CI, to catch any attempts to use the injected
      variables.
      
      [0] https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars
      
      Change-Id: I7e9d5c9b8b9164d4aee3abb4e37c8f28d98ff5d1
      Partially-Implements: blueprint performance-improvements
      ade5bfa3
  28. Feb 15, 2021
    • Pedro Henrique's avatar
      Add support to OpenID Connect Authentication flow · f3fbe837
      Pedro Henrique authored
      
      This pull request adds support for the OpenID Connect authentication
      flow in Keystone and enables both ID and access token authentication
      flows. The ID token configuration is designed to allow users to
      authenticate via Horizon using an identity federation; whereas the
      Access token is used to allow users to authenticate in the OpenStack CLI
      using a federated user.
      
      Without this PR, if one wants to configure OpenStack to use identity
      federation, he/she needs to do a lot of configurations in the keystone,
      Horizon, and register quite a good number of different parameters using
      the CLI such as mappings, identity providers, federated protocols, and
      so on. Therefore, with this PR, we propose a method for operators to
      introduce/present the IdP's metadata to Kolla-ansible, and based on the
      presented metadata, Kolla-ansible takes care of all of the
      configurations to prepare OpenStack to work in a federated environment.
      
      Implements: blueprint add-openid-support
      Co-Authored-By: default avatarJason Anderson <jasonanderson@uchicago.edu>
      Change-Id: I0203a3470d7f8f2a54d5e126d947f540d93b8210
      f3fbe837
  29. Oct 05, 2020
    • Michal Nasiadka's avatar
      Use Docker healthchecks for core services · c52a89ae
      Michal Nasiadka authored
      This change enables the use of Docker healthchecks for core OpenStack
      services.
      Also check-failures.sh has been updated to treat containers with
      unhealthy status as failed.
      
      Implements: blueprint container-health-check
      Change-Id: I79c6b11511ce8af70f77e2f6a490b59b477fefbb
      c52a89ae
  30. Aug 10, 2020
    • Mark Goddard's avatar
      Mount /etc/timezone based on host OS · 146b00ef
      Mark Goddard authored
      Previously we mounted /etc/timezone if the kolla_base_distro is debian
      or ubuntu. This would fail prechecks if debian or ubuntu images were
      deployed on CentOS. While this is not a supported combination, for
      correctness we should fix the condition to reference the host OS rather
      than the container OS, since that is where the /etc/timezone file is
      located.
      
      Change-Id: Ifc252ae793e6974356fcdca810b373f362d24ba5
      Closes-Bug: #1882553
      146b00ef
  31. Apr 09, 2020
    • Dincer Celik's avatar
      Introduce /etc/timezone to Debian/Ubuntu containers · 4b5df0d8
      Dincer Celik authored
      Some services look for /etc/timezone on Debian/Ubuntu, so we should
      introduce it to the containers.
      
      In addition, added prechecks for /etc/localtime and /etc/timezone.
      
      Closes-Bug: #1821592
      Change-Id: I9fef14643d1bcc7eee9547eb87fa1fb436d8a6b3
      4b5df0d8
    • James Kirsch's avatar
      Add support for encrypting backend Keystone HAProxy traffic · b475643c
      James Kirsch authored
      This patch introduces an optional backend encryption for Keystone
      service. When used in conjunction with enabling TLS for service API
      endpoints, network communcation will be encrypted end to end, from
      client through HAProxy to the Keystone service.
      
      Change-Id: I6351147ddaff8b2ae629179a9bc3bae2ebac9519
      Partially-Implements: blueprint add-ssl-internal-network
      b475643c
  32. Mar 06, 2020
  33. Jan 30, 2020
    • Mark Goddard's avatar
      Python 3: Use distro_python_version for dev mode · 5a786436
      Mark Goddard authored
      In dev mode currently the python source is mounted under python2.7
      site-packages. This change fixes this to use the distro_python_version
      variable to ensure dev mode works with Python 3 images.
      
      Change-Id: Ieae3778a02f1b79023b4f1c20eff27b37f481077
      Partially-Implements: blueprint python-3
      5a786436
  34. Jan 10, 2020
    • Mark Goddard's avatar
      CentOS 8: Support variable image tag suffix · 9755c924
      Mark Goddard authored
      For the CentOS 7 to 8 transition, we will have a period where both
      CentOS 7 and 8 images are available. We differentiate these images via a
      tag - the CentOS 8 images will have a tag of train-centos8 (or
      master-centos8 temporarily).
      
      To achieve this, and maintain backwards compatibility for the
      openstack_release variable, we introduce a new 'openstack_tag' variable.
      This variable is based on openstack_release, but has a suffix of
      'openstack_tag_suffix', which is empty except on CentOS 8 where it has a
      value of '-centos8'.
      
      Change-Id: I12ce4661afb3c255136cdc1aabe7cbd25560d625
      Partially-Implements: blueprint centos-rhel-8
      9755c924
  35. 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
  36. Sep 17, 2019
  37. 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
  38. May 17, 2019
    • binhong.hua's avatar
      Make kolla-ansible support extra volumes · 12ff28a6
      binhong.hua authored
      When integrating 3rd party component into openstack with kolla-ansible,
      maybe have to mount some extra volumes to container.
      
      Change-Id: I69108209320edad4c4ffa37dabadff62d7340939
      Implements: blueprint support-extra-volumes
      12ff28a6
Loading