Merge "Map Neutron services to isolated networks"

Merge "Map Keystone services to isolated networks"

Merge "Map Glance services to isolated networks"

Merge "Reuse the various service passwords as db passwords."

Merge "Map Cinder services to isolated networks"

Merge "Map Ceilometer services to isolated networks"

Merge "Add Keystone as Pacemaker resource"

Map Neutron services to isolated networks

This change adds parameters to specify which network the Neutron API should
use. If the internal_api network exists, Neutron will bind to the IP on that
network, otherwise the Undercloud 'ctlplane' network will be used. The
network that the Neutron API is bound to can be overridden in an environment
file.

Change-Id: I11bcebba3a22e8850095250a2ddfaf972339476b

Map Keystone services to isolated networks

This change adds parameters to specify which networks the Keystone API
services will use. If the external network exists, Keystone will bind to
the IP on that network for the public API, otherwise it will default to
the IP on the Undercloud 'ctlplane' network. If the internal_api network
exists it will be used for the Keystone Admin API, otherwise it will
default to the 'ctlplane' IP. The networks these APIs are bound to can
be overridden in an environment file.

Change-Id: I6694ef6ca3b9b7afbde5d4f9d173723b9ce71b20

Map Glance services to isolated networks

This change adds parameters to specify which networks the Glance services
will use. If the internal_api network exists, Glance Registry will bind
to the IP on that network, otherwise it will default to the Undercloud
'ctlplane' network. If the storage network exists, Glance API will bind
to the IP on that network, otherwise it will default to 'ctlplane'. The
networks that these services use can be overridden with an environment
file.

Change-Id: I6114b2d898c5a0ba4cdb26a3da2dbf669666ba99

Merge "Define Glance Pacemaker resources on $pacemaker_master node only"

Merge "os-net-config templates to configure vlans on bond"

Map Cinder services to isolated networks

This change adds parameters to specify which networks the Cinder API and
Cinder iSCSI services will listen on. If the internal_api network exists,
Cinder API will be bound to the IP on that network, otherwise it will
default to the Undercloud 'ctlplane' network. The Cinder iSCSI service will
bind to the storage network if it exists, otherwise will also default to
using the Undercloud 'ctlplane' network.

Change-Id: I98149f108baf28d46eb199b69a72d0f6914486fd

Merge "Ensures mongodb configuration only happens if mongodb is needed"

Merge "We don't need to create the clustercheck user anymore"

Merge "overcloud stepped deployment environment"

Map Ceilometer services to isolated networks

This change adds the parameters to specify which networks the Ceilometer
and MongoDB servers listen on. It is set to the internal_api network if
present, and reverts to the default Undercloud 'ctlplane' network if not.

Change-Id: Ib646e4a34496966f9b1d454f04d07bf95543517f

os-net-config templates to configure vlans on bond

This patch adds 5 new role templates to help configure
an OVS bond with vlans on top for each of the overcloud
roles.

These are meant to represent a more production network
which might use isolated nets, and should help facilitate
create a CI job which configures a bond w/ vlans on it.

The patch also includes an environment file to
enable configuration of bonded vlans by simply
sourcing this file.

Change-Id: Ibe4c9d933445014ce3bec5fb3d7e3139fc40cb32

An environment file to enable network isolation

This commit adds an environment file which adds all
the relevant resource registry entries to enable isolated
overcloud networks.

Change-Id: I8c5e0ca300b86a38925f59c9df7831d69da9f787

Switch net-config templates to use OS::stack_id

This patch removes the custom config_id outputs and replaces
it with OS::stack_id which allows us to just call get_resource
in the parent stack.

The motivation for this change is we'll be adding more os-net-config
templates and it would be nice to take advantage of this newer
template feature.

Change-Id: I6fcb26024b94420779b86766e16d8a24210c4f8e

Update neutron local_ip to use the tenant network

This patch uses the new NetIpMap and ServiceMap abstractions
to assign the Neutron tenant tunneling network addresses.
By default this is associated with the tenant network. If no
tenant network is activated this will still default to
the control plane IP address.

Change-Id: I9db7dd0c282af4e5f24947f31da2b89f231e6ae4

Add a network ports IP mapping resource

This patch adds a resource which constructs a Json output
parameter called net_ip_map which will allow us to easily
extract arbitrary IP addresses for each network using the
get_attr function in heat.

The goal is to use this data construct in each role
template to obtain the correct IP address on each
network.

Change-Id: I1a8c382651f8096f606ad38f78bbd76314fbae5f

Add isolated network ports to block storage roles

This patch updates the cinder block storage roles so that
they can optionally make use of isolated network
ports on the storage, storage management, and internal_api
networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: I4e18cd4763455f815a8f8b82c93a598c99cc3842

Add isolated network ports to swift roles

This patch updates the swift roles so that
they can optionally make use of isolated network
ports on the storage, storage management, and internal API
networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: I9984404331705f6ce569fb54a38b2838a8142faa

Add isolated network ports to ceph roles

This patch updates the ceph roles so that
they can optionally make use of isolated network
ports on the storage and storage management networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: I35cb8e7812202f8a7bc0379067bf33d483cd2aec

Add isolated network ports to compute roles

This patch updates the compute roles so that
they can optionally make use of isolated network
ports on the tenant, storage, and internal_api networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: Ib07b4b7256ede7fb47ecc4eb5abe64b9144b9aa1

Add isolated network ports to controller roles

This patch updates the controller roles so that
they can optionally make use of isolated network
ports on each of 5 available overcloud networks.

 -Multiple networks are created based upon settings in the heat
  resource registry. These nets will either use the noop network (the
  control plane pass-thru default) or create a custom Neutron port on
  each of the configured networks.

 -The ipaddress/subnet of each network is passed passed into the
  NetworkConfig resource which drives os-net-config. This allows the
  deployer to define a custom network template for static IPs, etc
  on each of the networks.

 -The ipaddress is exposed as an output parameter. By exposing
  the individual addresses as outputs we allow Heat to construct
  collections of ports for various services.

Change-Id: I9bbd6c8f5b9697ab605bcdb5f84280bed74a8d66

Add isolated net parameters to net-config stacks

This patch adds parameters so that we can pass in the
ipaddress/subnet for each of the isolated overcloud
traffic nets to os-net-config templates. This
interface change will allow deployers to plug
in a custom version of an os-net-config template
that drives isolated network configuration.

Change-Id: I35bbe9a0bd81e79f9bfd531fe89c700af8b354c4

Add a ports (ip address) abstraction layer

This patch adds a set of templates to create ports on isolated
networks via Heat. There are 5 port templates in total
which are split out according to the available overcloud
networks.

Change-Id: I5175ef48c1960ea0d13fc8518328db53921c70cd

Merge "Wire in optional network creation for overcloud"

overcloud stepped deployment environment

When combined with --with-steps added to devtest_overcloud:
https://review.openstack.org/#/c/162109/ this enables stepped
deployments using heat hooks.

This environment file will break on all *StepN resources in every
*NodesPostDeployment resource, on both create and update.

Change-Id: Ibab567f0a37b832ea2b5966288ad55b5682c31ab

Wire in optional network creation for overcloud

This patch enables uses to selectively enable the creation
of split out networks for the overcloud traffic. These
networks will be created on the undercloud's neutron
instance.

By default a noop network is used so that no extra networks
are created. This allows our default to continue being
all traffic on the control plane.

Change-Id: Ied49d9458c2d94e9d8e7d760d5b2d971c7c7ed2d

Merge "Firstboot rsync for development purposes"

Define Glance Pacemaker resources on $pacemaker_master node only

Previously the Glance Pacemaker resources were mistakenly defined
on all nodes causing intermittent duplication errors.

Change-Id: I839ee49b153aa96ec08ebdb7e44aaeac28785963

Add Keystone as Pacemaker resource

Change-Id: I4631f962415164975143e94ec0b251ee5972c552

Merge "Add Glance as Pacemaker resource"

Merge "Add Cinder services as Pacemaker resources"

Align puppet Controller post-deploy Deployment names

Align all Deployment resource so we can use a glob convention for
stepped deployments via heat hooks/breakpoints.

Since most resources already use a FooDeployment_StepN convention,
align those which deviate from this as a precursor to supporting
stepped deployment, e.g stepping through "*Deployment_Step*".

Change-Id: I6bfee04649aa36116d1141ebe06d08b310ec8939

Merge "Overcloud: bump HOT version to 2015-04-30"

Add Glance as Pacemaker resource

Change-Id: If87cc4d55e8524246d2cd41a62805f84780006b2

Add Cinder services as Pacemaker resources

Add Pacemaker resources for Cinder services, also add relevant ordering
and colocation constraints.

Change-Id: Idc2e1b5ec96d882543f7a1a4ec723a010020ab02

Merge "Start non-pacemakerized services in step 4"

We don't need to create the clustercheck user anymore

With change I4b6b77e878017bf92d7c59c868d393e74405a355 we started
using the root user for clustercheck script so we don't need to
create the clustercheck user anymore.

Change-Id: Ic92bd12baeeeaf3f674e766fbc0a8badfb44822f

Merge "Use clustercheck script to control galera-ready"

Start non-pacemakerized services in step 4

Previously we've been starting non-pacemakerized services in step 3 on
bootstrap node and in step 4 on others. Now that $sync_db in OpenStack
Puppet modules is decoupled from $enabled and $manage_service [1] we can
start the services in step 4 on all nodes.

[1] https://bugs.launchpad.net/puppet-glance/+bug/1452278

Change-Id: I6351d972ab00f4661d98338d95310d33f271de2f

Merge "Prepare for adding OpenStack services to Pacemaker"

Overcloud: bump HOT version to 2015-04-30

This patch bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.

Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4

Merge "Move sysctl settings into hieradata"

Merge "Set up corosync using hostnames rather than IPs"

Move sysctl settings into hieradata

This will configure the sysctl settings via puppet instead of
sysctl image element.

Change-Id: Ieb129d4cbe4b6d4184172631499ecd638073564f

Merge "Clone params for pacemaker rabbitmq resource"

Merge "Provide RabbitMQ clients with a list of servers instead of VIP"

Use clustercheck script to control galera-ready

The exec timeout/attempts is configured so that it is
left running for up to 30mins if the command runs but is
unsuccessfull and up to 2h if the command times out.

Change-Id: I4b6b77e878017bf92d7c59c868d393e74405a355

Ensures mongodb configuration only happens if mongodb is needed

Change-Id: I7e9eb665275bd48d9c079934cc01ba62b5f59e16

Prepare for adding OpenStack services to Pacemaker

We need to write config for OpenStack services on all nodes in step 3 so
that we can then create pacemaker resources in step 4. (If we wrote
config on non-bootstrap nodes in step 4 as it is currently, services on
those nodes might be started unconfigured. This is an inter-node
ordering issue that cannot be easily solved from within Puppet
manifests, hence the use of steps to enforce this ordering.)

Change-Id: Ia78ec38520bd1295872ea2690e8d3f8d6b01c46c

Merge "Consolidate use of $pacemaker_master in step 2"

Merge "Enable VIPs via Pacemaker from step 2 instead of step 1"

Merge "Move NTP and Memacache respectively into step 1 and step 2"

Merge "Ensure sync_db is consumed by Keystone and Cinder classes"

Merge "Remove unused enable_pacemaker setting from templates"

Merge "Configure HAProxy, Galera and MongoDB before start"

Merge "Update to reflect puppet-pacemaker changes"

Merge "Fix RabbitMQ startup race"

Clone params for pacemaker rabbitmq resource

Set clone params according to [1].

[1] https://github.com/beekhof/osp-ha-deploy/blob/f8a65ab4c34f94737edde7db60337b830bfe6311/pcmk/rabbitmq.scenario

Change-Id: I5644de2d6253ab762a1420560ecb5bee2fd83092
Co-Authored-By: Giulio Fidente <gfidente@redhat.com>

Provide RabbitMQ clients with a list of servers instead of VIP

This will change the way how RabbitMQ clients get to the servers,
they will not go through HAProxy anymore.

Change-Id: I522d7520b383a280505e0e7c8fecba9ac02d2c9b

Consolidate use of $pacemaker_master in step 2

Aims at having the Pacemaker resources configuration happening
in a single if condition.

Change-Id: I497538510f80a356e876d476024671b787b77fc9

Enable VIPs via Pacemaker from step 2 instead of step 1

Change-Id: I724c341f148fedf725f3b3da778e491741b754ae

Merge "Environment which configures puppet pacemaker."

Merge "Add a directory for overcloud heat environments"

Move NTP and Memacache respectively into step 1 and step 2

NTP synchronization is moved to to step 1 where initial Pacemaker
configuration is performed.

Memacached is moved to step 2 to make sure it is up before the
OpenStack services are started.

Change-Id: I84121a687ee5ddb522239ecefd4d1d76c2f910b5

Ensure sync_db is consumed by Keystone and Cinder classes

Change-Id: Ia8cb04b214c71afc884647fb20be3cc1a309c194

Remove unused enable_pacemaker setting from templates

Use of Pacemaker is governed by the resource registry since
change Ibefb80d0d8f98404133e4c31cf078d729b64dac3

Change-Id: I2f1fa8d6d28ae009940be2c2c530066197aa543b

Configure HAProxy, Galera and MongoDB before start

As with RabbitMQ previously, we can hit the same race conditions between
config being written on all nodes vs. pacemaker starting the
services. Configuring the services at least one step earlier than
starting them will allow us to get rid of this race condition.

Change-Id: I78f47dfb82ca8609ed40f784d65ba92db3d411f3

Update to reflect puppet-pacemaker changes

Recently puppet-pacemaker has changed in a backward incompatible way, we
need to reflect the changes in TripleO.

This patch also addresses non-deterministic order between corosync
service and VIP creation.

Depends-On: Ia68fee38f99dba18badc07eb0adbc473cfcffdf3
Change-Id: Ia7fe14cfb1401be98b62afeed589bb9f1b8af761
Co-Authored-By: Yanis Guenane <yanis.guenane@enovance.com>

Set up corosync using hostnames rather than IPs

This ensures that the hosts in Corosync and in Pacemaker are the same,
to make our cluster setup compatible with the recommended architecture.

Change-Id: Id81f315768edd24b8978b8de7093e04904591ce2
Closes-Bug: #1447497
Depends-On: Idb9ad017ffb1048f38fedbd55cc974785f6b1c38

Fix RabbitMQ startup race

The Pacemaker resource agent might have attempted to start the
service when the rabbitmq-env.conf file wasn't written yet, making
it attempt to bind on 0.0.0.0

Co-Authored-By: Jason Guiditta <jguiditt@redhat.com>
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Change-Id: I081a0bfc6fc3943b8ade71799357022d29317d79

Environment which configures puppet pacemaker.

Change-Id: I314955708ff99a557da5a6d223b1f56bd51855d9

Add a directory for overcloud heat environments

This patch adds a new directory called environments which contains
custom Heat environment files that can be used to enable custom
overcloud features. As an initial example a puppet-ceph-devel.yaml
environment has been added which can be used to spin up a small Ceph
cluster for dev/testing.

This directory may be useful for collecting other
feature related Heat environment settings in the future as well.
Things like isolated network settings, etc.

Change-Id: Ia6998ae05d2363384d2a616a31d5795c8b2d85d5

Merge "Ensure haproxy is not enabled by puppet-tripleo when EnablePacemaker"

Merge "Makes sure galera can handle the connections"

Makes sure galera can handle the connections

Increases the max_connections since this is currently set to 151.
This causes problems in a baremetal environment with multiple CPUs.
A related change is @ https://review.openstack.org/#/c/183046/2
for haproxy. There is also a bug report at

https://bugzilla.redhat.com/show_bug.cgi?id=1218322

Change-Id: I9b4690191616cc04c4edc7b2402bd9ec54a7d17d

Merge "Use pacemaker::resource::service instead of ::systemd"

Ensure haproxy is not enabled by puppet-tripleo when EnablePacemaker

Change-Id: Icfe70de72eb2cf09fe2d00d9ae49baebc79e1886

Merge "Create split out neutron networks via Heat."

Merge "Add Galera as a Pacemaker resource when EnablePacemaker"

Add Galera as a Pacemaker resource when EnablePacemaker

This commit aims to support the creation of the galera cluster via
Pacemaker. With this commit in, three use-cases will be supported.

 * Non HA setup / Non Pacemaker setup : The deployment will take place
as it is currently the case in f20puppet-nonha. Nothing changes.

 * Non HA setup / Pacemaker setup : Even though it is a non ha setup,
galera cluster via pacemaker  will be deployed with a cluster nbr of 1.

 * HA setup / Non Pacemaker setup : N/A

 * HA setup / Pacemaker setup : It is assumed that HA setup will
always be with pacemaker.  So in this situation pacemaker will deploy a
cluster of 3 galera master nodes.

Depends-On: I7aed9acec11486e0f4f67e4d522727476c767d83
Change-Id: If0c37a86fa8b5aa6d452129bccf7341a3a3ba667

Use optimized config for RabbitMQ cluster

Use some optimized configuration settings for RabbitMQ when
clustered. Data is ported from Astapor.

Change-Id: If54aff5654dbe75e68197588be12cb3995c77ec7

Use pacemaker::resource::service instead of ::systemd

The puppet-pacemaker module realizes some abstraction for the
different service types in ::service already.

Change-Id: Icd897e18fda01b1bf4722a975c991e26341ac129
Closes-Bug: 1449988

Puppet: Split out controller pacemaker manifest

This patch adds support for using the Heat resource registry
so that end users can enable pacemaker. Using this approach
allows us to isolate all of the pacemaker logic for the
controller in a single template rather than use conditionals
for every service that must support it.

Change-Id: Ibefb80d0d8f98404133e4c31cf078d729b64dac3

Create split out neutron networks via Heat.

This patch adds a new abstraction for network creation
within Heat. This (optional) set of templates may be disabled
if you wish to create Neutron networks for the undercloud
via Heat templates... instead of using os-cloud-config
JSON to do so. Creating networks with Heat has the benefit
of being parameter driven so that users can quickly
enable networks using the resource registry and parameters.

There are 5 networks to start with which are roughly modeled
around networks an Overcloud user might want to use to isolate
their traffic. The intent is to make these opt-in and
configurable for end users.

The networks.yaml template can be used to create all of the
networks using parameters in the resource registry.

Change-Id: I5f2b3356378eb263d90d428cc83c7f5b141957e1

Merge "Add MongoDB as a Pacemaker resource when EnablePacemaker"

Merge "puppet: install Horizon on overcloud-controller"

Merge "Move Ceph OSD data path configuration into static ceph.yaml file"

Add MongoDB as a Pacemaker resource when EnablePacemaker

This commit allows one to configure MongoDB as a pacemaker resource when
EnablePacemaker is set to true

Change-Id: Iedfba3eb851442d0ca3b8c0a7163a63285ab6071

Merge "Add support for Glance RBD backend"

Add support for Glance RBD backend

This patch adds support for a new GlanceBackend setting
which can be set to one of swift, rbd, or file to control
which Glance backend is configured for use by default.

Change-Id: Id6a3fbc3477e85e8e2446e3dc13d424f9535d0ff

Firstboot rsync for development purposes

Could be used to e.g. make changes to the puppet modules on the fly
without the need to rebuild images. Documented in the template
description.

Change-Id: I6a1fef20d4f4afa4bedac5ea520949697793f0ed

Revert "Keystone domain for Heat"

This reverts commit 7313930c22b9f18d67e630de084ffcc6fad5ebe7.

Seeing errors when trying to create the keystone admin
role with packages. (ImportError: No module named os_client_config)

Change-Id: I78796598ccb8d2ffd6bfca85dce7d18dc0fd768e
Related-bug: #1450786

Reuse the various service passwords as db passwords.

We need to stop using "unset" as the password for all databases. Ideally we
would add a "XxxxDSN" parameter (e.g. KeystoneDSN) but this wont work because
we don't know the VirtualIP to pass in.

Until we can come up with a better solution we should at least get rid of
the "unset" passwords.

Change-Id: I31f45912fa9c116ccdee010a2c5d91ea43a25671
Depends-On: I8ffe1eb481f615b0fbe127cd8107f1e70794c839

Merge "Keystone domain for Heat"