Skip to content
Snippets Groups Projects
  1. 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
  2. Dec 01, 2022
  3. Nov 22, 2022
  4. Oct 04, 2022
  5. Sep 29, 2022
    • Marcin Juszkiewicz's avatar
      init-runonce: use CirrOS 0.6.0 · e17a0ca2
      Marcin Juszkiewicz authored
      CirrOS 0.6.0 was released yesterday. Has newer kernel and userspace,
      better network configuration (more IPv6 stuff) and some other
      improvements.
      
      Change-Id: Ife7767904efe64602531fa3eb163c78260650909
      e17a0ca2
  6. Sep 28, 2022
  7. Sep 27, 2022
  8. Aug 08, 2022
    • Monty Taylor's avatar
      Add clouds.yaml file and use it · 73a1812c
      Monty Taylor authored
      clouds.yaml[0] is a richer way to express configuration for OpenStack
      clouds. It's also fully supported by Ansible's OpenStack modules as
      well as python-openstackclient and openstacksdk. It's the future - who
      doesn't like the future?
      
      Write a file using both the public (default) and the internal endpoints
      for the admin user. Also, change all of the examples to reference it
      and to get python-openstackclient to use it too.
      
      [0] https://docs.openstack.org/openstacksdk/latest/user/guides/connect_from_config.html
      
      Implements: blueprint use-clouds-yaml
      Change-Id: I557d2e4975c7b3d3c713a556b9ba47af9567ce6e
      73a1812c
  9. Jul 27, 2022
  10. Jul 20, 2022
    • Michal Nasiadka's avatar
      init-runonce: Migrate to ECDSA keys · d2bc0b42
      Michal Nasiadka authored
      OpenSSH 8.8 has dropped support for RSA SHA-1 keys.
      ECDSA is FIPS approved, so probably it's a better
      direction than just changing to SHA-256.
      
      Change-Id: Id06d9d8912d9677dbe0f5a666f43a209664c94b4
      d2bc0b42
  11. Jul 19, 2022
    • Bryan Schwerer's avatar
      Corrected the config file to use when stopping neutron-openvswitch-agent · 570a1d43
      Bryan Schwerer authored
      The use of file ml12_conf.ini has been deprecated, replaced by /etc/neutron/plugins/ml2/openvswitch_agent.ini.
      
      The command to cleanup the agent still references the old file.  Just fix the filename
      
      https: //bugs.launchpad.net/kolla-ansible/+bug/1982222
      Change-Id: I0fe7f68eda55e0c7d9960016bba74f5ba1ae223e
      570a1d43
  12. May 13, 2022
  13. Apr 28, 2022
  14. Apr 20, 2022
  15. Apr 13, 2022
    • Christian Berendt's avatar
      ovs-dpdk: add ovs-dpdkctl.sh to the role itself · 89659b46
      Christian Berendt authored
      Currently the ovs-dpdkctl.sh file is present in the tools
      directory and the "Copying ovs-dpdkctl tool" task accesses it.
      
      This is bad practice. Files copied from a role should either be
      referenced by an absolute path or be part of the role itself.
      
      This change moves the ovs-dpdkctl.sh file in the files
      directory of the role.
      
      Change-Id: I01459d39207e54f270f32f37b4a5153c5a819347
      89659b46
  16. Mar 21, 2022
    • Mark Goddard's avatar
      libvirt: add nova-libvirt-cleanup command · 80b311be
      Mark Goddard authored
      Change Ia1239069ccee39416b20959cbabad962c56693cf added support for
      running a libvirt daemon on the host, rather than using the nova_libvirt
      container. It did not cover migration of existing hosts from using a
      container to using a host daemon.
      
      This change adds a kolla-ansible nova-libvirt-cleanup command which may
      be used to clean up the nova_libvirt container, volumes and related
      items on hosts, once it has been disabled.
      
      The playbook assumes that compute hosts have been emptied of VMs before
      it runs. A future extension could support migration of existing VMs, but
      this is currently out of scope.
      
      Change-Id: I46854ed7eaf1d5b5e3ccd8531c963427848bdc99
      80b311be
  17. Feb 21, 2022
  18. Jan 18, 2022
    • Radosław Piliszek's avatar
      Clean up chrony cleanup · e63bbed1
      Radosław Piliszek authored
      In the Yoga cycle we no longer need kolla chrony container removal
      procedures.
      
      Change-Id: I4dc246cf0fd68838470bf9e9bf749fa9be4d6670
      e63bbed1
  19. Jan 07, 2022
  20. Nov 15, 2021
  21. Oct 27, 2021
  22. Sep 28, 2021
    • Niklas Hagman's avatar
      Transition Keystone admin user to system scope · 2e933dce
      Niklas Hagman authored
      A system-scoped token implies the user has authorization to act on the
      deployment system. These tokens are useful for interacting with
      resources that affect the deployment as a whole, or exposes resources
      that may otherwise violate project or domain isolation.
      
      Since Queens, the keystone-manage bootstrap command assigns the admin
      role to the admin user with system scope, as well as in the admin
      project. This patch transitions the Keystone admin user from
      authenticating using project scoped tokens to system scoped tokens.
      This is a necessary step towards being able to enable the updated oslo
      policies in services that allow finer grained access to system-level
      resources and APIs.
      
      An etherpad with discussion about the transition to the new oslo
      service policies is:
      
      https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
      
      
      
      Change-Id: Ib631e2211682862296cce9ea179f2661c90fa585
      Signed-off-by: default avatarNiklas Hagman <ubuntu@post.blinkiz.com>
      2e933dce
  23. Sep 23, 2021
  24. Sep 21, 2021
    • Michal Arbet's avatar
      Add check and diff options to kolla-ansible · 0e720b38
      Michal Arbet authored
      This patch is adding --check and --diff options
      to kolla-ansible, which cause that kolla-ansible
      run will be more verbose and able to run in
      semi dry-run mode.
      
      The --diff option for kolla-ansible can be used alone or
      with --check. When you run in diff mode, any module that
      supports diff mode reports the changes made or, if used
      with --check, the changes that would have been made.
      Diff mode is most common in modules that manipulate files
      (for example, the template module) but other modules might
      also show ‘before and after’ information
      (for example, the user module).
      
      For more information check [1].
      
      [1] https://docs.ansible.com/ansible/latest/user_guide/playbooks_checkmode.html#using-diff-mode
      
      Change-Id: Ifb82ea99e5af82540e938eab9e2a442b2820d7df
      0e720b38
  25. Aug 25, 2021
    • Mark Goddard's avatar
      Add kolla-ansible gather-facts command · d9a37589
      Mark Goddard authored
      In some situations it may be helpful to populate the fact cache on
      demand. The 'kolla-ansible gather-facts' command may be used to do this.
      
      One specific case where this may be helpful is when running kolla-ansible
      with a --limit argument, since in that case hosts that match the limit
      will gather facts for hosts that fall outside the limit. In the extreme
      case of a limit that matches only one host, it will serially gather
      facts for all other hosts. To avoid this issue, run 'kolla-ansible
      gather-facts' without a limit to populate the fact cache in parallel
      before running the required command with a limit.
      
      Change-Id: I79db9bca23aa1bd45bafa7e7500a90de5a684593
      d9a37589
  26. Aug 17, 2021
  27. Jul 29, 2021
    • Will Szumski's avatar
      Support multiple inventories · 6c72fa81
      Will Szumski authored
      Multiple inventories can now be passed to `kolla-ansible`.  This can be
      useful to construct a common inventory that is shared between multiple
      environments.
      
      Change-Id: I2ac5d7851b310bea2ba362b353f18c592a0a6a2e
      6c72fa81
  28. Jun 30, 2021
  29. Jun 05, 2021
  30. Jun 02, 2021
    • Mark Goddard's avatar
      chrony: allow to remove the container · 84ac7b30
      Mark Goddard authored
      The chrony container is deprecated in Wallaby, and disabled by default.
      This change allows to remove the container if chrony is disabled.
      
      Change-Id: I1c4436072c2d47a95625e64b731edb473384b395
      84ac7b30
  31. May 25, 2021
    • Mark Goddard's avatar
      Fix exit code with bogus command name · 86ddc94e
      Mark Goddard authored
      Running this:
      
      $ kolla-ansible bogus-command
      
      Should show usage & give a non-zero exit code. Previously it gave a zero
      exit code. This change fixes the issue.
      
      Closes-Bug: #1929397
      
      Change-Id: I580c208d61d5efe115f936dfb8f3f6508acd91b2
      86ddc94e
  32. May 24, 2021
  33. Apr 08, 2021
    • Michal Arbet's avatar
      Support editable installation in all cases · 22a6765f
      Michal Arbet authored
      An editable installation allows changes to be made to the source code
      directly, and have those changes applied immediately without having to
      reinstall.
      
          pip install -e /path/to/kolla-ansible
      
      Above is currently working only in virtualenv, but there is no reason to
      not allow in all cases. This is usefull for example when user is
      building his own docker container with editable kolla-ansible installed
      from git without virtualenv.
      
      Change-Id: I185f7c09c3f026fd6926a26001393f066ff1860d
      22a6765f
  34. Mar 08, 2021
  35. Mar 03, 2021
    • Doug Szumski's avatar
      Remove Monasca Log Transformer · 0743a9bf
      Doug Szumski authored
      Historically Monasca Log Transformer has been for log
      standardisation and processing. For example, logs from different
      sources may use slightly different error levels such as WARN, 5,
      or WARNING. Monasca Log Transformer is a place where these could
      be 'squashed' into a single error level to simplify log searches
      based on labels such as these.
      
      However, in Kolla Ansible, we do this processing in Fluentd so
      that the simpler Fluentd -> Elastic -> Kibana pipeline also
      benefits. This helps to avoid spreading out log parsing
      configuration over many services, with the Fluentd Monasca output
      plugin being yet another potential place for processing (which
      should be avoided). It therefore makes sense to remove this
      service entirely, and squash any existing configuration which
      can't be moved to Fluentd into the Log Perister service. I.e.
      by removing this pipeline, we don't loose any functionality,
      we encourage log processing to take place in Fluentd, or at least
      outside of Monasca, and we make significant gains in efficiency
      by removing a topic from Kafka which contains a copy of all logs
      in transit.
      
      Finally, users forwarding logs from outside the control plane,
      eg. from tenant instances, should be encouraged to process the
      logs at the point of sending using whichever framework they are
      forwarding them with. This makes sense, because all Logstash
      configuration in Monasca is only accessible by control plane
      admins. A user can't typically do any processing inside Monasca,
      with or without this change.
      
      Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c
      0743a9bf
  36. Feb 12, 2021
    • Mark Goddard's avatar
      Fix installation with pip install --user · 519ca1c0
      Mark Goddard authored
      If kolla-ansible is installed via pip install --user, currently the
      kolla-ansible script is unable to locate the installed playbooks.
      This leads to a failure when running commands.
      
      This change fixes the issue by checking for the user's .local directory
      as a possible installation path.
      
      This fixes some of the scenario tests which were failing after switching
      to a user installation in Ifaf1948ed5d42eebaa62d7bad375bbfc12b134d5.
      Most tests did not fail since the kolla-ansible script in the source
      checkout was used.
      
      Closes-Bug: #1915527
      
      Change-Id: I5b47a146627d06bb3fe4a747c5f20290c726b0f9
      519ca1c0
  37. Nov 20, 2020
  38. Nov 18, 2020
    • zengchen228's avatar
      Fix kolla-ansible to work with pyenv-virtualenv · aaab1d1b
      zengchen228 authored
      
      One of the pyenv-virtualenv-set-up aliases depends on a symlink.
      It seems pyenv runs the bash script from such a path and it fails
      because of a failing comparison (VIRTUAL_ENV not detected).
      
      The VIRTUAL_ENV is ensured to be fully resolved as well for safety.
      
      This requires readlink from GNU coreutils but all supported platforms
      have it by default.
      
      Extra comments included, as well as simplification of directory
      detection - readlink handles this (not that `bin` itself was
      ever a symlink...).
      
      Closes-Bug: #1903887
      Co-Authored-By: default avatarRadosław Piliszek <radoslaw.piliszek@gmail.com>
      Change-Id: I2fe6eb13ce7be68d346b1b3b7036859f34c896c4
      aaab1d1b
  39. Nov 13, 2020
  40. Oct 08, 2020
Loading