aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2015-06-04Merge "Add PortName to ports stacks"Jenkins6-0/+29
2015-06-04Merge "Combine Heat API networks into single net"Jenkins2-6/+2
2015-06-04Merge "Make all-nodes Ip networks configurable"Jenkins9-18/+260
2015-06-04Merge "Wire ServiceNetMap as a top level parameter"Jenkins4-26/+39
2015-06-04Merge "Pass NeutronEnableTunnelling to controllers"Jenkins1-0/+1
2015-06-04Merge "Set VXLAN tunnels range to match GRE range"Jenkins3-4/+5
2015-06-04Merge "Wire Neutron allow_automatic_l3agent_failover param to module"Jenkins1-2/+2
2015-06-03Pass NeutronEnableTunnelling to controllersGiulio Fidente1-0/+1
We forgot to pass NeutronEnableTunnelling param to controllers (passed only to computes), making it unusable. Change-Id: I74756732deabd1c7ba9039832ea169fd322a569f
2015-06-03Set VXLAN tunnels range to match GRE rangeGiulio Fidente3-4/+5
Change-Id: I16d259055fe4cd22541cd7abd7a26c71bbbaf292
2015-06-03Merge "os-net-config templates to configure vlans"Jenkins7-0/+396
2015-06-03Remove DefaultSignalTransport from top-level templateSteven Hardy1-6/+0
This hasn't been properly wired in for a while AFAICT, so it makes sense to remove it, and introduce a value via parameter_defaults which enables easier global selection of a particular transport without passing the value down through all the nested stacks. Change-Id: Icd830aea00768e65adc1df1287440fdab98058f9
2015-06-03Remove NO_SIGNAL from ControllerClusterConfigSteven Hardy1-1/+1
We want to ensure this actually worked, or subsequent configuration steps may fail. Change-Id: Ia9ae12e70dd32dd3ae6c26cbfd3e3e2dba5d272f
2015-06-03Remove NO_SIGNAL from Controller|ObjectSwiftDeploymentSteven Hardy1-2/+0
We want to know this deployment succeeded, again the ControllerAllNodesPostDeployment depends_on this, which implies it should actually be done before doing the PostDeployment stuff, which is impossible to determine with NO_SIGNAL. Change-Id: I46d23bce8762ac414e4de82cf42193694aebb763
2015-06-03Remove NO_SIGNAL from ControllerBootstrapNodeDeploymentSteven Hardy3-1/+2
We need to be sure the boostrap node data has been propagated to the cluster before proceeding with configuration, because ControllerNodesPostDeployment consumes the data put in place by this and depends_on for serialization, which is essentially meaningless when combined with NO_SIGNAL. Change-Id: I73a1e5a2cda4c79f457bfbd9ce2836dc5c1902cc
2015-06-03Make CephStorageDeployment depend on NetworkDeploymentGiulio Fidente1-0/+1
Change-Id: I5b6454d0e09eba79fc0376e963fd0e4c64105081
2015-06-03Remove NO_SIGNAL from puppet role templatesSteven Hardy4-6/+4
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
2015-06-03Merge "Reuse the undercloud service passwords as db passwords."Jenkins4-11/+11
2015-06-03horizon/keystone api should use internal_api NWDan Prince1-2/+2
As most of the OpenStack services are automatically bound to the public virtual IP already we don't need to set the default network for Horizon and Keystone to the 'external' network. These should probably default to the internal_api network like the rest of the OpenStack services... Change-Id: I04cf64568c2fc7bb8a821b0de5ba56aa90158e2d
2015-06-03Add virtual IPs for split out networksDan Prince5-6/+124
This patch adds VIPs for the internal_api, storage, and storage management networks. For puppet these are persisted into a local vip-config hieradata file which is then used by puppet-tripleo's loadbalancer module to apply per-service VIP settings. Change-Id: I909c3bdc9d17a8e15351f4797287769e3f76c849
2015-06-03Add PortName to ports stacksDan Prince6-0/+29
For VIP ports we set an explicit name on the ports. This patch adds an optional PortName parameter to the ports objects which can be used to specify a name. Change-Id: Iad0f5e4cfc31a931dbb574d9e589570125e9465c
2015-06-03Combine Heat API networks into single netDan Prince2-6/+2
We probably don't need to split out separate networks for Heat CFN and Cloudwatch. Just having a single network for Heat API in the overcloud is probably fine. Change-Id: I917b314e01227af72129645c9b72ad8e54f07865
2015-06-03Make all-nodes Ip networks configurableDan Prince9-18/+260
This patch adds a new NetIpListMap abstraction which we can use to make the all-nodes-config IP list network assignments configurable. Ip address lists for all overcloud services which require IPs were added to all-nodes-config so that puppet manifests can be directly supplied the correct network list for each service. Change-Id: I209f2b4f97a4bb78648c54813dad8615770bcf1a
2015-06-03Wire ServiceNetMap as a top level parameterDan Prince4-26/+39
This patch makes ServiceNetMap a top level parameter. This is helpful to tools like Tuskar which don't support Heat environments that contain both a resource_registry and default_parameters. ServiceNetMap will in fact be utilized at the top level in some of the VIP related patches that follow. Change-Id: I375063dacf5f3fc68e6df93e11c3e88f48aa3c3a
2015-06-02Wire Neutron allow_automatic_l3agent_failover param to moduleGiulio Fidente1-2/+2
Change-Id: Ibd1581ebb87ed02f3840000e90025a2a371019aa
2015-06-01os-net-config templates to configure vlansDan Prince7-0/+396
This patch adds 5 new role templates to help configure a vlans on top for each of the overcloud roles. This patch adds vlans on top of a single NIC attached to the control plane network (already used for provisioning). The patch also includes an environment file to enable configuration of vlans by simply sourcing this file. Change-Id: Ibc40e452dec9b372ff10442aab2bddaf382b0a2f
2015-06-01Merge "post-deploy hook for rhel registration"Jenkins5-0/+276
2015-06-01Merge "Neutron: Remove hiera lookup to controller_host"Jenkins1-1/+0
2015-06-01Merge "Add Heat as a Pacemaker resource"Jenkins1-8/+79
2015-06-01Merge "Add Ceilometer as a Pacemaker resource"Jenkins1-12/+149
2015-05-31Neutron: Remove hiera lookup to controller_hostYanis Guenane1-1/+0
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
2015-05-29Merge "Map Mysql to isolated networks"Jenkins4-6/+7
2015-05-29Merge "Use heat inputs for network port settings"Jenkins2-23/+44
2015-05-29Add Heat as a Pacemaker resourceYanis Guenane1-8/+79
Change-Id: I1c8fc6beacc8352ad2aabe44ff20614ac52c1795
2015-05-29Add Ceilometer as a Pacemaker resourceYanis Guenane1-12/+149
Change-Id: I1243b68506f37d6b78807c03948874ae100fef65
2015-05-29Add Nova as Pacemaker resourceGiulio Fidente1-12/+112
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
2015-05-29Adds neutron-server and agents as pacemaker resourcesmarios2-33/+171
Adds neutron-server, neutron-l3-agent, neutron-dhcp-agent, neutron-openvswitch-agent and neutron-metadata-agent as pacemaker resources. Change-Id: I4dcc6f56db4c27a2a4f627fa8303cbeb2bd563d4
2015-05-28Map Mysql to isolated networksDan Prince4-6/+7
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
2015-05-28Use heat inputs for network port settingsDan Prince2-23/+44
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
2015-05-28Merge "Fix colocation order to match ref-arch"Jenkins1-3/+3
2015-05-28Merge "Add Memcache as a Pacemaker resource"Jenkins1-2/+9
2015-05-28Merge "Add a keystone-cinder-api constraint"Jenkins1-0/+10
2015-05-28Merge "Add keystone-glance-registry constraint"Jenkins1-0/+10
2015-05-28Merge "Use the proper parameter to set --master"Jenkins1-1/+2
2015-05-27Merge "Map Horizon, Redis, Rabbit, memcached to isolated nets"Jenkins2-4/+8
2015-05-27Merge "Map Swift services to isolated networks"Jenkins2-2/+4
2015-05-27Merge "Map Nova services to isolated networks"Jenkins2-2/+4
2015-05-27Merge "Map Heat services to isolated networks"Jenkins2-3/+6
2015-05-27Merge "Map Neutron services to isolated networks"Jenkins2-1/+2
2015-05-27Merge "Map Keystone services to isolated networks"Jenkins2-2/+4
2015-05-27Merge "Map Glance services to isolated networks"Jenkins2-3/+5