The variables zun_developer_mode and zun_venv_download
no longer carry any meaning. This review changes zun to
do the equivalent of what developer_mode was all the time,
meaning that it always builds the venv and never requires
the repo server, but it will use a repo server when available.
As part of this, we move the installation out of its own file
because it's now a single task to include the venv build role.
This is just to make it easier to follow the code.
We also change include_tasks to import_tasks and include_role
to import_role so that the tags in the python_venv_build role
will work.
As part of commit xenial testing was removed. Instead centos 7
and opensuse 15 functional tests were added.
Change-Id: Ic8fc09372cf7397df6757c115b2c05dbb5db68f1
In order to enable the service setup host python interpreter to
be changed easily, we make it a variable. This will be useful
when someone sets the service setup host to be the utility
container, because we'll be able to set this var by default.
Change-Id: I7d801847f194d733bb2e5418f64571e68d8b42ad
In order to radically simplify how we prepare the service
venvs, we use a common role to do the wheel builds and the
venv preparation. This makes the process far simpler to
understand, because the role does its own building and
installing. It also reduces the code maintenance burden,
because instead of duplicating the build processes in the
repo_build role and the service role - we only have it all
done in a single place.
We also change the role venv tag var to use the integrated
build's common venv tag so that we can remove the role's
venv tag in group_vars in the integrated build. This reduces
memory consumption and also reduces the duplication.
This is by no means the final stop in the simplification
process, but it is a step forward. The will be work to follow
which:
1. Replaces 'developer mode' with an equivalent mechanism
that uses the common role and is simpler to understand.
We will also simplify the provisioning of pip install
arguments when doing this.
Depends-On: https://review.openstack.org/598957
Change-Id: Ia3646f395a17c90de6ff7b23e31897573691b5d4
Implements: blueprint python-build-install-simplification
Signed-off-by: Jesse Pretorius <jesse.pretorius@rackspace.co.uk>
As of change https://review.openstack.org/#/c/596502/ nova
has deprecated the RamFilter and DiskFilter since they are
not necessary when using the default scheduler driver
(filter_scheduler). This change removes their usage from
this deployment project.
Change-Id: I9c05016817cb03933292f09d06119795f8f451a0
There is no record for why we implement the MQ vhost/user creation
outside of the role in the playbook, when we could do it inside the
role.
Implementing it inside the role allows us to reduce the quantity of
group_vars duplicated from the role, and allows us to better document
the required variables in the role. The delegation can still be done
as it is done in the playbook too.
In this patch we implement two new variables:
- zun_oslomsg_rpc_setup_host
- zun_oslomsg_notify_setup_host
These are used in the role to allow delegation of the MQ vhost/user
setup for each type to any host, but they default to using the first
member of the applicable oslomsg host group.
We also adjust some of the defaults to automatically inherit existing
vars set in group_vars form the integrated build so that we do not
need to do the wiring in the integrated build's group vars. We still
default them in the role too for independent role usage.
Finally, we remove the test mq setup tasks and clean up any unused
or unnecessary variables configured in tests.
Change-Id: I639a3fa3e138b1ae190325b9794969820267ec23
This introduces oslo.messaging variables that define the RPC and
Notify transports for the OpenStack services. These parameters replace
the rabbitmq values and are used to generate the messaging
transport_url for the service.
This patch:
* Add oslo.messaging variables for RPC and Notify to defaults
* Update transport_url generation
* Add oslo.messaging to tests inventory and update tests
* Install extra packages for optional drivers
Change-Id: I0b2138ca9eb49387948f2ca87800cf966a9414a8
In order to reduce the packages required to pip install on to the hosts,
we allow the service setup to be delegated to a specific host, defaulting
to the deploy host. We also switch as many tasks as possible to using the
built-in Ansible modules which make use of the shade library.
The openstack_openrc role is now executed once on the designated host, so
it is no longer necessary to execute it using include_role here.
The zun_requires_pip_packages variable is not used and is therefore removed.
Depends-On: https://review.openstack.org/579233
Depends-On: https://review.openstack.org/579959
Change-Id: I7108b43109136aac46bc87a0c59827a202f87be8
There is no record for why we implement the database creation outside
of the role in the playbook, when we could do it inside the role.
Implementing it inside the role allows us to reduce the quantity of
group_vars duplicated from the role, and allows us to better document
the required variables in the role. The delegation can still be done
as it is done in the playbook too.
In this patch we implement a new variable called 'zun_db_setup_host'
which is used in the role to allow delegation of the database setup
task to any host, but defaults to the first member of the galera_all
host group. We also document the variable 'zun_galera_address' which
has been used for a long time, but never documented. A bunch of unused
variables have also been removed.
Change-Id: Ic1e3c870a220f67cc5220a1dbc644d8bf47b0f16
The following packages are required in-order to run osprofiler.
these packages will provide deployers the ability to profile
a service on demand should they choose to enable the profile
functionality.
Change-Id: I119ab6ab6f57b04fcedba36006d2a04de91cfae3
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
