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
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: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Change-Id: I2fe6eb13ce7be68d346b1b3b7036859f34c896c4
The kolla-cli is deprecation [1], it should be clean up from
kolla-ansible's cleanup-host script
[1]: https://review.opendev.org/#/c/749045/
Change-Id: I7072de235d9d629b0f538dc98c5258ee5f023376
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
This is confusing as it is not meant to be used by users.
Also, various tools show duplicated matches due to both locations
containing the exact same content.
Change-Id: I2debe121f64954e57788270d3258775f29f1cbb0
Currently seting --configdir on kolla-ansible CLI doesn't set properly the path
for the passwords file.
Change-Id: I38d215b721ec256be6cfdd6313b5ffb90c2a3f4c
Closes-Bug: #1887180
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Tests prometheus, grafana, and centralised logging.
The tests could be improved in future by querying logs in elasticsearch,
and metrics in prometheus.
Change-Id: Iabad035d583d291169f23be3d71931cb260e87ae
The common role was previously added as a dependency to all other roles.
It would set a fact after running on a host to avoid running twice. This
had the nice effect that deploying any service would automatically pull
in the common services for that host. When using tags, any services with
matching tags would also run the common role. This could be both
surprising and sometimes useful.
When using Ansible at large scale, there is a penalty associated with
executing a task against a large number of hosts, even if it is skipped.
The common role introduces some overhead, just in determining that it
has already run.
This change extracts the common role into a separate play, and removes
the dependency on it from all other roles. New groups have been added
for cron, fluentd, and kolla-toolbox, similar to other services. This
changes the behaviour in the following ways:
* The common role is now run for all hosts at the beginning, rather than
prior to their first enabled service
* Hosts must be in the necessary group for each of the common services
in order to have that service deployed. This is mostly to avoid
deploying on localhost or the deployment host
* If tags are specified for another service e.g. nova, the common role
will *not* automatically run for matching hosts. The common tag must
be specified explicitly
The last of these is probably the largest behaviour change. While it
would be possible to determine which hosts should automatically run the
common role, it would be quite complex, and would introduce some
overhead that would probably negate the benefit of splitting out the
common role.
Partially-Implements: blueprint performance-improvements
Change-Id: I6a4676bf6efeebc61383ec7a406db07c7a868b2a
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
Change-Id: I023d96d25edd9d2fafd4415743e298af72a861a1
Recently a feature was merged to support pulling in multiple
configuration files from a globals.d directory. However, if this
directory does not exist, we get the following error when executing
kolla-ansible:
find: '/etc/kolla/globals.d': No such file or directory
This change addresses this by redirecting find command stderr to
/dev/null.
TrivialFix
Change-Id: Ie5aa511a5ebf3355817a7c3bb65b09ac5dcf2b67
Added a spec file for this blueprint.
Changed the kolla-ansible script to accept more than one
globals.yml file. That will still be the main one but operators
will be able to create more, under the /etc/kolla/globals.d
directory.
Also added some paragraphs in the quickstart documentation
about this.
Finally, Adding a release note
Change-Id: I34eb91d0e2ed80694594b8fc6801cf8ad77da754
Implements: blueprint multiple-globals-files
This is to avoid waiting for the user to input data to continue
creating sample resources.
Change-Id: I46ff7a4779dae4c9cbe157e1712afa4e53be269e
Signed-off-by: Luke Short <ekultails@gmail.com>
Fix-feature following up on the original check [1] to make it
test the correct interpreter.
Additionally, this change removes last, unneeded call to
random python - getting script directory is perfectly
doable in bash.
All checks are done from Python, not Ansible, due to its
performance. Python version feels snappy (0.2 s to check),
compared to sluggish Ansible (2.0 s to check).
What is more, relying on Ansible would require hacky solutions
to e.g. prevent custom config from interfering with it.
We might be willing to steer Ansible from Python in the future
anyhow.
[1] Icf0399d21b3fde8d530d73e6e7ee4a57665da276
Change-Id: Ib8f2e6b6672e7c06aa94bc226c4d72640d25d8c2
Closes-Bug: #1856346
Bashate warned on init-swift.sh because of E043 -- arithmetic
compound has inconsistent return semantics: (( next_port++ ))
New Zuul reported that on every change as a warning.
This is fixed here.
This change makes Bashate always produce errors so that we do not
introduce such warnings again.
Change-Id: I40166b377ec2580e17901375b636183bca492d3a
Drops support for creating Python 2 virtualenvs in bootstrap-servers,
and looking for a python2 interpreter in the kolla-ansible script.
Also forces the use of Python 3 as the remote interpreter in CI on
Debian and Ubuntu hosts, since they typically symlink the unversioned
interpreter to python2.7.
Change-Id: Id0e977de381e7faafed738674a140ba36184727e
Partially-Implements: blueprint drop-py2-support
CentOS 8 support is now fairly complete - time to drop CentOS 7.
Partially-Implements: blueprint centos-rhel-8
Change-Id: I940b1d3eceb98e16fa366c243672f588b1412d70
The repo is Python 3 now, so update hacking to version 3.0 which
supports Python 3.
Fix problems found by updated hacking version.
Remove hacking and friends from lower-constraints, they are not needed
during installation.
Change-Id: I7ef5ac8a89e94f5da97780198619b6facc86ecfe
We don't need tox nor tell our users to use it when doing kolla
builds.
Tox is going away from base infra images.
It's already gone from aarch64 (arm64) ones.
Change-Id: I2eb5203ad93c011b8806f4b6fb56db081c14a2cb
Not everyone wants Kafka data stored on a Docker volume. This
change allows a user to flexibly control where the data is stored.
Change-Id: I2ba8c7a85c7bf2564f954a43c6e6dbb3257fe902
The affected command was meant to create a tenant network, so let
us really test it this way.
Not marking CI, because someone may be using this script.
Change-Id: I5abe46948992121a11a36f941d4f8fac1caa92b1
Since fluentd is disabled in MariaDB jobs - haproxy logs are not getting
populated.
Change-Id: I56b3fc1be6940d97905cdb2c4452b846f106c071
Depends-on: https://review.opendev.org/713704
While supporting both CentOS 7 and 8, we used the tag 'master-centos8'
for CentOS 8 images. We are now ready to drop CentOS 7 support, and
Kolla is switching to publish CentOS 8 images using the master tag on
the master branch, so we should use this.
Depends-On: https://review.opendev.org/713265
Partially-Implements: blueprint centos-rhel-8
Change-Id: I07d2c285e3214a6dc827a8e8eacf263048ee099b
