Make CephStorageDeployment depend on NetworkDeployment

Change-Id: I5b6454d0e09eba79fc0376e963fd0e4c64105081

Remove NO_SIGNAL from puppet role templates

Currently we use NO_SIGNAL on both the NetworkConfig and subsequent config
deploying the data associated with the role.  This means there is a risk that
should the NetworkConfig do anything interruptive (os-net-config can do
interface renaming based on discovery data for example) the role configuration
config could fail, and we'd never know until some later error occurs.

Additionally, we need to be sure that the heiradata deployed by each of the role
specicific configs is actually in-place before proceeding with any of the cluster
configuration - atm this works due to the inherent delays involved deploying to
bare-metal, but there's still a theoretical race if very fast deployment backends
(I'm thinking containers, e.g lxc backend to nova or something) were used instead.

Essentially, we should never be using NO_SIGNAL unless we want to ignore failure,
which AFAICT is not the case in this instance.

Change-Id: I0dbbcc87fb8df8e6bc4775c39fa616b0d0713464

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

Merge "post-deploy hook for rhel registration"

Merge "Neutron: Remove hiera lookup to controller_host"

Merge "Add Heat as a Pacemaker resource"

Merge "Add Ceilometer as a Pacemaker resource"

Neutron: Remove hiera lookup to controller_host

With current effort of creating isolated networks, the controller_host
hiera variable does not exist anymore. Hence we remove it else the
lookup will fail.

The hiera binding neutron::agents::ml2::ovs::local_ip has been written
in another review[1]

[1] I1dc11987b4ea3c37775b14fbdddb75588499e9bb

Change-Id: I12777c512d379210e5cddb5e683be4d79808fa2c

Merge "Map Mysql to isolated networks"

Merge "Use heat inputs for network port settings"

Add Heat as a Pacemaker resource

Change-Id: I1c8fc6beacc8352ad2aabe44ff20614ac52c1795

Add Ceilometer as a Pacemaker resource

Change-Id: I1243b68506f37d6b78807c03948874ae100fef65

Add Nova as Pacemaker resource

Constraints based on vncproxy are commented due to it not starting
with websockify < 0.6, see [1]

1. http://lists.openstack.org/pipermail/openstack-dev/2014-October/048535.html

Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Change-Id: Ie51014bf563920d2e75c5e38942bc42ddc2a3939

Adds neutron-server and agents as pacemaker resources

Adds neutron-server, neutron-l3-agent, neutron-dhcp-agent,
neutron-openvswitch-agent and neutron-metadata-agent  as
pacemaker resources.

Change-Id: I4dcc6f56db4c27a2a4f627fa8303cbeb2bd563d4

Map Mysql to isolated networks

This change adds parameters to specify which networks the MySQL
service will use. If the internal_api network exists the MySQL
service will bind to the IP address on that network, otherwise
the services will default to the IP on the Undercloud 'ctlplane'
network.

This patch also drop the old 'controller_host' variable from
the puppet controller template since it is no longer in use.

Change-Id: I4fba2c957f7db47e916bc269fb4bd32ccc99bd4c

Use heat inputs for network port settings

This patch updates the controller and compute roles
so that we use get_input in the software configuration
instead of calling get_attr/get_param there.

Change-Id: I1dc11987b4ea3c37775b14fbdddb75588499e9bb

Merge "Fix colocation order to match ref-arch"

Merge "Add Memcache as a Pacemaker resource"

Merge "Add a keystone-cinder-api constraint"

Merge "Add keystone-glance-registry constraint"

Merge "Use the proper parameter to set --master"

Merge "Map Horizon, Redis, Rabbit, memcached to isolated nets"

Merge "Map Swift services to isolated networks"

Merge "Map Nova services to isolated networks"

Merge "Map Heat services to isolated networks"

Merge "Map Neutron services to isolated networks"

Merge "Map Keystone services to isolated networks"

Merge "Map Glance services to isolated networks"

Fix colocation order to match ref-arch

Fixes the colocation order between glance-api and glance-registry to
match the ref-arch[1]

[1]
https://github.com/beekhof/osp-ha-deploy/blob/master/pcmk/glance.scenario#L108

Change-Id: I40f35afedb3333d97c8b689538bb80a90a66afe8

Add keystone-glance-registry constraint

Make sure the keystone service starts before the glance-registry one.

Change-Id: Ia81df13682bf556a39cc36520def48105ee3e27d

Add a keystone-cinder-api constraint

Make sure the keystone service starts before the cinder-api one.

Change-Id: I21549c066afcf051e52fc4bba4fae2f34ad2ba4b

Use the proper parameter to set --master

The interface for pcmk_resource offers the parameter master_params to set
--master during the resource creation.

Change-Id: I6fa769f14a6248b371810af3ba6819a1f9ed9442

Add Memcache as a Pacemaker resource

Depends-On: I7b992450176595a89dba9fe2eccf619af2645d6b
Change-Id: I30cebb6d3a8670f49587bedaf51af18a87a8d24c

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

Merge "Map Cinder services to isolated networks"

Map Horizon, Redis, Rabbit, memcached to isolated nets

This change adds parameters to select the networks for Horizon,
Redis, Rabbit MQ, and memcached services. Horizon is often used for
administration from outside the cloud, so if the external network
exists, Horizon will bind to that IP, otherwise it will default to
the Undercloud 'ctlplane' network. Redis, Rabbit MQ, and memcached
will bind to IPs on the internal_api network if it exists, else
they will default to the 'ctlplane' network as well. Any of these
network assignments can be overridden with an environment file.

Change-Id: Ie0aa46b4a3c00d3826866796b4ec3b14f71f987c

Merge "Map Ceilometer services to isolated networks"

Map Swift services to isolated networks

This change adds paramters to specify which networks the Swift API
services will use. If the storage network exists, it will be used
for the Swift API, otherwise the Undercloud 'ctlplane' network will
be used. If the storage_mgmt network exists, it will be used for
the back-end storage services, otherwise the 'ctlplane' will be
used by default.

Change-Id: I1d5e966a16416c52935c22efe2d4783cd2192c32

Map Nova services to isolated networks

This change adds parameters to specify which networks the Nova API and
metadata services will use. If the internal_api network exists, it will be
used for the bind IP for Nova API and metadata servers, otherwise the
Undercloud 'ctlplane' IP will be used by default.

Change-Id: Ie420274c7fba80abf9cf2b599431acc47e28fc7a

Map Heat services to isolated networks

This change adds parameters to specify which networks the Heat services
will use. If the internal_api network exists, the Heat API, Heat Cloud
Formations, and Heat Cloudwatch services will bind to the IP address on
that network, otherwise the services will default to the IP on the
Undercloud 'ctlplane' network.

Change-Id: I5febe1b9071600b43fa76c6cf415db83cad472ab

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