0fbac20fd6
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
(cherry picked from commit
|
||
---|---|---|
.. | ||
database | ||
logging | ||
monitoring | ||
network | ||
pacemaker | ||
time | ||
aodh-api.yaml | ||
aodh-base.yaml | ||
aodh-evaluator.yaml | ||
aodh-listener.yaml | ||
aodh-notifier.yaml | ||
apache.yaml | ||
ca-certs.yaml | ||
ceilometer-agent-central.yaml | ||
ceilometer-agent-compute.yaml | ||
ceilometer-agent-notification.yaml | ||
ceilometer-api.yaml | ||
ceilometer-base.yaml | ||
ceilometer-collector.yaml | ||
ceilometer-expirer.yaml | ||
ceph-base.yaml | ||
ceph-client.yaml | ||
ceph-external.yaml | ||
ceph-mon.yaml | ||
ceph-osd.yaml | ||
ceph-rgw.yaml | ||
cinder-api.yaml | ||
cinder-backup.yaml | ||
cinder-base.yaml | ||
cinder-scheduler.yaml | ||
cinder-volume.yaml | ||
glance-api.yaml | ||
glance-base.yaml | ||
glance-registry.yaml | ||
gnocchi-api.yaml | ||
gnocchi-base.yaml | ||
gnocchi-metricd.yaml | ||
gnocchi-statsd.yaml | ||
haproxy.yaml | ||
heat-api-cfn.yaml | ||
heat-api-cloudwatch.yaml | ||
heat-api.yaml | ||
heat-base.yaml | ||
heat-engine.yaml | ||
horizon.yaml | ||
ironic-api.yaml | ||
ironic-base.yaml | ||
ironic-conductor.yaml | ||
keepalived.yaml | ||
kernel.yaml | ||
keystone.yaml | ||
manila-api.yaml | ||
manila-backend-cephfs.yaml | ||
manila-backend-generic.yaml | ||
manila-backend-netapp.yaml | ||
manila-base.yaml | ||
manila-scheduler.yaml | ||
manila-share.yaml | ||
memcached.yaml | ||
neutron-api.yaml | ||
neutron-base.yaml | ||
neutron-compute-plugin-midonet.yaml | ||
neutron-compute-plugin-nuage.yaml | ||
neutron-compute-plugin-opencontrail.yaml | ||
neutron-compute-plugin-ovn.yaml | ||
neutron-compute-plugin-plumgrid.yaml | ||
neutron-dhcp.yaml | ||
neutron-l3-compute-dvr.yaml | ||
neutron-l3.yaml | ||
neutron-metadata.yaml | ||
neutron-midonet.yaml | ||
neutron-ovs-agent.yaml | ||
neutron-ovs-dpdk-agent.yaml | ||
neutron-plugin-ml2-ovn.yaml | ||
neutron-plugin-ml2.yaml | ||
neutron-plugin-nuage.yaml | ||
neutron-plugin-opencontrail.yaml | ||
neutron-plugin-plumgrid.yaml | ||
neutron-sriov-agent.yaml | ||
nova-api.yaml | ||
nova-base.yaml | ||
nova-compute.yaml | ||
nova-conductor.yaml | ||
nova-consoleauth.yaml | ||
nova-ironic.yaml | ||
nova-libvirt.yaml | ||
nova-metadata.yaml | ||
nova-scheduler.yaml | ||
nova-vnc-proxy.yaml | ||
opendaylight-api.yaml | ||
opendaylight-ovs.yaml | ||
pacemaker.yaml | ||
rabbitmq.yaml | ||
README.rst | ||
sahara-api.yaml | ||
sahara-base.yaml | ||
sahara-engine.yaml | ||
services.yaml | ||
snmp.yaml | ||
swift-base.yaml | ||
swift-proxy.yaml | ||
swift-ringbuilder.yaml | ||
swift-storage.yaml | ||
tripleo-firewall.yaml | ||
tripleo-packages.yaml | ||
vip-hosts.yaml |
services
A TripleO nested stack Heat template that encapsulates generic configuration data to configure a specific service. This generally includes everything needed to configure the service excluding the local bind ports which are still managed in the per-node role templates directly (controller.yaml, compute.yaml, etc.). All other (global) service settings go into the puppet/service templates.
Input Parameters
Each service may define its own input parameters and defaults. Operators will use the parameter_defaults section of any Heat environment to set per service parameters.
Config Settings
Each service may define a config_settings output variable which returns Hiera settings to be configured.
Steps
Each service may define an output variable which returns a puppet manifest snippet that will run at each of the following steps. Earlier manifests are re-asserted when applying latter ones.
config_settings: Custom hiera settings for this service.
global_config_settings: Additional hiera settings distributed to all roles.
step_config: A puppet manifest that is used to step through the deployment sequence. Each sequence is given a "step" (via hiera('step') that provides information for when puppet classes should activate themselves.
Steps correlate to the following:
- Load Balancer configuration
- Core Services (Database/Rabbit/NTP/etc.)
- Early Openstack Service setup (Ringbuilder, etc.)
- General OpenStack Services
- Service activation (Pacemaker)
- Fencing (Pacemaker)
Note: Not all roles currently support all steps:
- ObjectStorage role only supports steps 2, 3 and 4