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

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

"Smoke tests" for barbican, cinder, glance and keystone have been removed as discussed in PTG April 2022.

Signed-off-by: Tim Beermann <beermann@osism.tech>
Change-Id: I613287a31e0ea6aede070e7e9c519ab2f5f182bd

Closes-Bug: #1931042
Change-Id: If4bc1fe1dcd61622c8ea48b00771d5115a63c9e0

We have only one value for install_type now and it gets removed from
image names.

Change-Id: I8bf95fd7aa9dd26b80d618ca0fcb097003b4cb0a

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

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

This change adds an Ansible Galaxy requirements file including the
openstack.kolla collection. A new 'kolla-ansible install-deps' command
is provided to install the requirements.

With the new collection in place, this change also switches to using the
baremetal role from the openstack.kolla collection, and removes the
baremetal role from this repository.

Depends-On: https://review.opendev.org/c/openstack/ansible-collection-kolla/+/820168

Change-Id: I9708f57b4bb9d64eb4903c253684fe0d9147bd4a

In the Yoga cycle we no longer need kolla chrony container removal
procedures.

Change-Id: I4dc246cf0fd68838470bf9e9bf749fa9be4d6670

Also bumps the minimum to 4.

Change-Id: Ia373f9cc3bb69eba0288bbb3e497e8cadb7cc4d3

Closes-Bug: #1878280
Change-Id: I0d39a015639adf3d75780edc765bebcb85c2b42e
Signed-off-by: Adrian Andreias <adrian@fleio.com>

Change-Id: Iefa8f78142c502ac9e8ebdbb95c94b2b05f99e5b
Closes-Bug: #1948979

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: Niklas Hagman <ubuntu@post.blinkiz.com>

This change bumps up max supported Ansible version
to 4.x (ansible-core 2.11.x) and minimum to 2.10.

Change-Id: I8b9212934dfab3831986e8db55671baee32f4bbd

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

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

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Change-Id: I374f7427a4318d00ca474367818117e11789ec13

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

This commit adds two new cli commands to allow an operator
to read and write passwords into a configured Hashicorp Vault
KV.

Change-Id: Icf0eaf7544fcbdf7b83f697cc711446f47118a4d

Change-Id: Ic45f618204875684f52133ec0f69fe7512ec9e2c

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

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

The linters job started failing, due to a dependency change.

Change-Id: Ibab350ecf6d9551da8e9c8b704693122cec11559

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

Min version stays as 2.9

Change-Id: I7ec8c5eb36757248c9aa016dc7d4e495ec5bb635

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

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

This file is for kolla images.

Change-Id: I2c1a21790b65cf6537380d576c0abb4d16bd369b

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

Change-Id: Ibd06726ac6edcb63a1d5d4f4148851876316dc5b

implemented as a separate command (kolla-ansible octavia-certificates)

Implements: blueprint implement-automatic-deploy-of-octavia

Co-Authored-By: wu.chunyang <wuchunyang@yovole.com>
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Change-Id: I2c5b26ce9e363f35c523865904a582f7960aa682

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

Change-Id: I5befc72a4894d625ca352b27df9d3aa84a2f5b2c

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

Change-Id: Iff699b6dd9417e2e72618263641cbfa6ccb6e585
Related-Bug: #1892341

remove cluster_interface from project.
update storage_interface docs.and remove
storage_interface_address variable

Change-Id: I3f811db988234f94b5ed0cc9d24233f70784f58d

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