Age | Commit message (Collapse) | Author | Files | Lines |
|
Makes it possible to resolve network subnets within a service
template; the data is transported into a new property ServiceData
wired into every service which hopefully is generic enough to
be extended in the future and transport more data.
Data can be consumed in service templates to set config values
which need to know what is the subnet where a deamon operates (for
example the Ceph Public vs Cluster network).
Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2
|
|
This patch does 2 things:
* Configure messagingv2 as default driver for Oslo Notifications sent on
RPC.
* Allow users to choose between messagingv2 (default) and noop when we
want to disable notifications (for example, when Telemetry is disabled).
* Deprecate KeystoneNotificationDriver in favor of NotificationDriver.
Change-Id: Ia547d7f4bfb51e7c45246b097b48fd86da231bd3
Related-Bug: #1701357
|
|
Add ServiceDebug parameters for each services that will allow operators
to enable/disable Debug for specific services.
We keep the Debug parameters for backward compatibility.
Operators want to enable Debug everywhere:
Debug: true
Operators want to disable Debug everywhere:
Debug: false
Operators want to disable Debug everywhere except Glance:
GlanceDebug: true
Operators want to enable Debug everywhere except Glance:
Debug: true
GlanceDebug: false
New parameters: AodhDebug, BarbicanDebug, CeilometerDebug, CinderDebug,
CongressDebug, GlanceDebug, GnocchiDebug, HeatDebug, HorizonDebug,
IronicDebug, KeystoneDebug, ManilaDebug, MistralDebug, NeutronDebug,
NovaDebug, OctaviaDebug, PankoDebug, SaharaDebug, TackerDebug,
ZaqarDebug.
Note: for backward compatibility in Horizon, HorizonDebug is set to
false, so we maintain previous behavior.
Change-Id: Icbf4a38afcdbd8471d1afc11743df9705451db52
Implement-blueprint: composable-debug
Closes-Bug: #1634567
|
|
When a service is enabled on multiple roles, the parameters for the
service will be global. This change enables an option to provide
role specific parameter to services and other templates.
Two new parameters - RoleName and RoleParameters, are added to the
service template. RoleName provides the role name of on which the
current instance of the service is being applied on. RoleParameters
provides the list of parameters which are configured specific to the
role in the environment file, like below:
parameters_default:
# Default value for applied to all roles
NovaReservedHostMemory: 2048
ComputeDpdkParameters:
# Applied only to ComputeDpdk role
NovaReservedHostMemory: 4096
In above sample, the cluster contains 2 roles - Compute, ComputeDpdk.
The values of ComputeDpdkParameters will be passed on to the templates
as RoleParameters while creating the stack for ComputeDpdk role. The
parameter which supports role specific configuration, should find the
parameter first in in the RoleParameters list, if not found, then the
default (for all roles) should be used.
Implements: blueprint tripleo-derive-parameters
Change-Id: I72376a803ec6b2ed93903cc0c95a6ffce718b6dc
|
|
Change-Id: I2b23d92c85d5ecc889a7ee597b90e930bde9028e
Depends-On: I72f84e737b042ecfaabf5639c6164d46a072b423
|
|
Configure keystone_authtoken for Sahara service.
Change-Id: I045b7d1d52851ab0d532a8524fcea95705e3db78
Partial-implement: blueprint keystone-v3
|
|
When fixing LP#1643487 we added ?bind_address to all DB URIs.
Since this clashes with Cellsv2 due to the URIs becoming host
dependent, we need a new approach to pass bind_address to pymysql
that leaves the DB URIs host-independent.
In change Iff8bd2d9ee85f7bb1445aa2e1b3cfbff1f397b18 we first create a
/etc/my.cnf.d/tripleo.cnf file with a [tripleo] section with the correct
bind-address option.
In this change we make sure that the DB URIs will point to the added
file and to the specific section containing the necessary bind-address
option. We do introduce a new MySQLClient profile which will hold all
this more client-specific configuration so that this change can fit
better in the composable roles work. Also, in the future it might
contain the necessary configuration for SSL for example.
Note that in case the /etc/my.cnf.d/tripleo.cnf file does not exist
(because it is created via the mysqlclient profile), things keep on
working as usual and the bind-address option simply won't be set, which
has no impact on hosts where there are no VIPs.
Co-Authored-By: Damien Ciabrini <dciabrin@redhat.com>
Change-Id: Ieac33efe38f32e949fd89545eb1cd8e0fe114a12
Related-Bug: #1643487
Closes-Bug: #1663181
Closes-Bug: #1664524
Depends-On: Iff8bd2d9ee85f7bb1445aa2e1b3cfbff1f397b18
|
|
The admin endpoint is listening on the ctlplane network by default;
services should ideally be using the internal api network for this kind
of traffic, as the ctlplane network is mostly for provisioning. On the
other hand, the admin endpoint shouldn't be as relevant with services
switching to keystone v3.
Change-Id: I1213a83ef8693c1cca1d20de974f7949a801d9f1
|
|
|
|
When a service connects to the database VIP from the node hosting this
VIP, the resulting TCP socket has a src address which is by default
bound to the VIP as well. If the VIP is failed over to another node
while the socket's Send-Q is not empty, TCP keepalive won't engage and
the service will become unavailable for a very long time (by default
more than 10m).
To prevent failover issues, DB connections should have the src address
of their TCP socket bound to the IP of the network interface used for
MySQL traffic. This is achieved by passing a new option to the
database connection URIs. This option is available starting from
PyMySQL 0.7.9-2.
We use a new intermediate variable in hiera to hold the IP to be used
as a source address for all DB connections. All services adapt their
database URI accordingly.
Moreover, a new YAML validation check is added to guarantee that new
services will construct their database URI appropriately.
Change-Id: Ic69de63acbfb992314ea30a3a9b17c0b5341c035
Closes-Bug: #1643487
|
|
Heat now supports release name aliases, so we can replace
the inconsistent mix of date related versions with one consistent
version that aligns with the supported version of heat for this
t-h-t branch.
This should also help new users who sometimes copy/paste old templates
and discover intrinsic functions in the t-h-t docs don't work because
their template version is too old.
Change-Id: Ib415e7290fea27447460baa280291492df197e54
|
|
The hardcoded list should be configurable, and defaulted
to their current value.
Change-Id: I517aa61f21c6f4d0975b10a7aa85177c543487e0
Closes-bug: 1560098
|
|
This patch movs the various db::mysql hiera settings into a
'mysql' specific service_config_settings section for each
service so that these will only get applied on the MySQL service
node. This follows a similar puppet-tripleo change where we
create the actual databases for all services locally on
the MySQL service node to avoid permission issues.
Change-Id: Ic0692b1f7aa8409699630ef3924c4be98ca6ffb2
Closes-bug: #1620595
Depends-On: I05cc0afa9373429a3197c194c3e8f784ae96de5f
Depends-On: I5e1ef2dc6de6f67d7c509e299855baec371f614d
|
|
This patch moves the keystone::auth settings for all
services into the new service_config_settings section. This
is important because we execute the keystone commands via
puppet only on the role containing the keystone service
and without these settings it will fail.
Note that yaql merging/filtering is used here to ensure that
service_config_settings is optional in service templates,
and also that we'll only deploy hieradata for a given
service on a node running the service (the key in
the service_config_settings map must match the service_name
in the service template for this to work).
e.g the following will result in only deploying keystone: 123
in hiera on the role running the "keystone" service,
regardless of which service template defines it.
service_config_settings:
keystone:
keystone: 123
Co-Authored-By: Steven Hardy <shardy@redhat.com>
Change-Id: I0c2fce037a1a38772f998d582a816b4b703f8265
Closes-bug: 1620829
|
|
This patch adds a new DefaultPasswords parameter to
composable services. This is needed to help provide
access to top level password resources that overcloud.yaml
currently manages (passwords for Rabbit, Mysql, etc.).
Moving the RandomString resources into composable services
would cause them to regenerate within the stack. With this
approach we can leave them where they are while we deprecate
the top level mechanism and move the code that uses the
passwords into the composable services.
Change-Id: I4f21603c58a169a093962594e860933306879e3f
|
|
This will be needed to pick the network where the service has
to bind to from within the service template.
Change-Id: I52652e1ad8c7b360efd2c7af199e35932aaaea8c
|
|
|
|
Currently we have a hard-coded set of per-service parameters, which
will cause problems for custom roles and full composability.
As a first step towards making this more configurable, remove the
hard-coded per-service parameters from overcloud.yaml, and adjust
the EndpointMap generation to instead accept two mappings, the
ServiceNetMap and a mapping of networks to IPs (effectively this
just moves the map lookup inside the endpoint map instead of
inside overcloud.yaml)
Change-Id: Ib522e89c36eed2115a6586dd5a6770907d9b33db
Partially-Implements: blueprint custom-roles
|
|
HDP plugin was deprecated in newton and not supported in sahara
replace it with supported ambari plugin
Change-Id: I6998e3e1e1fe9a81c7941aec90c876ee133a601d
Closes-bug: 1611107
|
|
https://review.openstack.org/#/c/318840/ decomposed the Sahara services
but they weren't added to the ControllerServices list, thus are now disabled.
Since we shipped mitaka with sahara enabled by default, we should probably add
them so the behavior is consistent when folks upgrade.
This also fixes a couple of issues we missed when landing the initial service
templates (partly because CI didn't test them).
In order for each service to operate independently when used with Pacemaker,
the roles needed to be separated. This commit also does this.
Depends-On: Id61eb15b1e2366f5b73c6e7d47941651e40651b1
Change-Id: I0846b328e9d938275e373d58f0b99219b19b326c
Closes-Bug: #1592284
Co-Authored-By: Brad P. Crochet <brad@redhat.com>
|
|
This is the THT part that brings us the next generation architecture
as described in the following spec:
https://review.openstack.org/#/c/299628/
Blueprint:
https://blueprints.launchpad.net/tripleo/+spec/ha-lightweight-architecture
So far we tested deployment + tripleo.sh --overcloud-pingtest and
failover + tripleo.sh --overcloud-pingtest
Note that many of the Pacemaker template files become redundant with
this change, but to simplify the process of getting this change landed,
those templates will not be removed until a future commit.
Depends-On: I5e7585c08675d8a4bd071523b94210d325d79b59
Change-Id: I00bccb2563c006f80baed623b64f1e17af20dd4e
Implements: blueprint ha-lightweight-architecture
Co-Author: cmsj@tenshu.net
|
|
|
|
Currently we use hyphens, e.g cinder-api, but in overcloud.yaml
we have a lot of references to services (e.g for AllNodesConfig)
by underscore, e.g cinder_api. To enable dynamic generation of
this data, we need the service name in underscore format.
Change-Id: Ief13dfe5d8d7691dfe2534ad5c39d7eacbcb6f70
|
|
Migrate puppet/hieradata/*.yaml parameters to puppet/services/*.yaml
except for some services that are not composable yet.
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Change-Id: I7e5f8b18ee9aa63a1dffc6facaf88315b07d5fd7
|
|
This patch adds a new service_name section to each composable
service. We now have an explicit unit test check to ensure that
service_name exists in tools/yaml-validate.py.
This patch also wires service_names into hieradata on each
of the roles so that tools can access the deployed services locally
during deployment and upgrades.
Change-Id: I60861c5aa760534db3e314bba16a13b90ea72f0c
|
|
Adds new puppet and puppet pacemaker specific services for Sahara API
and Sahara Engine.
The Pacemaker templates extend the default Sahara services and swap
in the pacemaker specific puppet-tripleo profile instead.
Change-Id: I1adda514e9592d149a3d45743a9a00b59c28ca38
Depends-On: I0c8bd68f9a98626e9d67ef713c72c9dd05b7cc12
Implements: blueprint composable-services-within-roles
|