aboutsummaryrefslogtreecommitdiffstats
path: root/environments
AgeCommit message (Collapse)AuthorFilesLines
2016-02-26Merge "Nova RPC unpinning"Jenkins1-0/+2
2016-02-26Merge "Add a sample network-environment.yaml file to environments"Jenkins1-0/+50
2016-02-25Merge "Add UpgradeLevelNovaCompute parameter"Jenkins1-0/+3
2016-02-25Merge "Introduce update/upgrade workflow"Jenkins1-2/+7
2016-02-25Merge "Add resources for major upgrade in Pacemaker scenario"Jenkins1-0/+3
2016-02-24Add a sample network-environment.yaml file to environmentsDan Sneddon1-0/+50
This change adds a sample network-environment.yaml file to the environments. This sample includes pointers to NIC config files, as well as default network subnets and allocation pools. This is meant to be a demonstration of the default settings for a virtual deployment. In a real deployment, the operator would customize the settings here and point to custom NIC config templates. Change-Id: I0288c0680effea06b5f805a0d955e8bbf6152ba6
2016-02-24Nova RPC unpinningJiri Stransky1-0/+2
During upgrades, we only run Puppet on the whole deployment to converge the state, after the upgrade workflow itself has been fully completed. That is an opportunity to utilize Puppet to make sure Nova Compute RPC doesn't remain pinned to the older version. Change-Id: I6ebc813a80dfd9dfbbb213c38724487e044507b8
2016-02-24Merge "Allow vncproxy to work with ssl enabled"Jenkins1-0/+3
2016-02-23Add UpgradeLevelNovaCompute parameterJiri Stransky1-0/+3
This parameter can be used for pinning (and later unpinning) the Nova Compute RPC version. Change-Id: I2f181f3b01f0b8059566d01db0152a12bbbd1c3e
2016-02-23Introduce update/upgrade workflowJiri Stransky1-2/+7
Change-Id: I7226070aa87416e79f25625647f8e3076c9e2c9a
2016-02-23Add resources for major upgrade in Pacemaker scenarioDerek Higgins1-0/+3
Add Heat software deployments to be used to upgrade major versions of OpenStack on the controller nodes. All controller services are taken down while the upgrade is in progress. The new updated yum repositories should be configured by another process e.g. the deployment artifacts transfer via Swift. Change-Id: Ia0a04e4a11d67e7a5acc53c1f8a8f01ed5ca8675 Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Co-Authored-By: Jiri Stransky <jistr@redhat.com>
2016-02-22Add extra config yaml files for big switch agents.xinwu1-0/+4
This change adds extra config yaml files for big switch agent and big switch lldp. This change is mainly for compute nodes. The changes related to controller nodes are landed at e78e1c8d9b5a7ebf327987b22091bff3ed42d1c1 This change also removes the neutron_enable_bigswitch_ml2 flag. Instead, User needs to specify NeutronMechanismDrivers: bsn_ml2 in environment file. Previous discussion about this change can be found at an abandoned review request https://review.openstack.org/#/c/271940/ Depends-On: Iefcfe698691234490504b6747ced7bb9147118de Change-Id: I81341a4b123dc4a8312a9a00f4b663c7cca63d7c
2016-02-12Minor fixes to allow local docker registry usageJeff Peeler1-1/+1
Changed the heat-docker-agents namespace to use the namespacing specified in the environment file, which reduces modifications required on the user when using a local registry. Changed the start agents script to handle using a local registry both with a namespace and without. Change-Id: I16cc96b7ecddeeda07de45f50ffc6a880dabbba6
2016-02-09Merge "Create linux bridge vlans environments"Jenkins1-0/+23
2016-01-21Merge "Add update yaml backward compatibe with PublicVirtualIP on ctlplane"Jenkins2-0/+5
2016-01-20Create linux bridge vlans environmentsJaume Devesa1-0/+23
Define environments to create VLANs attached to a single physical nic as 'single-nic-vlans' does, but using linux_bridge instead of ovs_bridge Change-Id: I8c6fe9ec7028178f783e7d9c0a1cc67a1517eb3d
2016-01-15Allow vncproxy to work with ssl enabledBen Nemec1-0/+3
Right now our vncproxy settings are hard-coded to http and the non-ssl port. This change adds a vncproxy entry to the endpoint map and uses those values to configure the proxy correctly on compute nodes. This is sufficient to get it working in my environment with ssl enabled. Change-Id: I9d69b088eef4700959b33c7e0eb44932949d7b71
2016-01-07Merge "updating enable_ceph conditions for controller"Jenkins1-2/+3
2016-01-06Enable Dell Storage Center iscsi Backends in Cinderrajinir1-0/+17
Enables support for configuring Cinder with a Dell Storage Center iscsi storage backend. This change adds all relevant parameters for: - Dell Storage Center SC Series (iSCSI) Change-Id: I3b1a4346f494139ab123c7dc1a62f81d03c9e728
2016-01-06Merge "Enable Equallogic Backends in Cinder"Jenkins1-0/+17
2016-01-06updating enable_ceph conditions for controllerDan Radez1-2/+3
- keeping enabled based on ceph node count being greater than 0 - adding enabled if ControllerEnableCephStorage is true Intention here is to be able to run ceph without having dedicated nodes for. Enabling Ceph alternativly from the ControllerEnableCeph parameter allows ceph to be colocated on the controllers without having to run any dedicated ceph nodes. Change-Id: I71062d37226c679156380c0f4e194b51cb586bcf Signed-off-by: Dan Radez <dradez@redhat.com>
2016-01-04Network Isolation support for containerized computeRyan Hallisey3-1/+6
The template will all neutron-agents to be configured so that it can run the network isolation templates on the containerized compute node. Co-Authored-By: Dan Prince <dpince@redhat.com> Change-Id: I7837ed7ed3e807ec5c1276904893695918bef293
2015-12-29Merge "Enable TLS in loadbalancer if cert path is detected"Jenkins1-0/+32
2015-12-23Merge "Add all isolated networks to all nodes."Jenkins1-0/+11
2015-12-23Merge "Add Management Network For System Administration."Jenkins2-0/+34
2015-12-22Merge "Add sample environment file to document usage of predictable IPs"Jenkins1-0/+20
2015-12-22Merge "MidoNet heat templates"Jenkins1-0/+20
2015-12-21MidoNet heat templatesJaume Devesa1-0/+20
Deploy a TripleO overcloud with networking midonet. MidoNet is a monolithic plugin and quite changes on the puppet manifest must be done. Depends-On: I72f21036fda795b54312a7d39f04c30bbf16c41b Depends-On: I6f1ac659297b8cf6671e11ad23284f8f543568b0 Depends-On: Icea9bd96e4c80a26b9e813d383f84099c736d7bf Change-Id: I9692e2ef566ea37e0235a6059b1ae1ceeb9725ba
2015-12-18Add all isolated networks to all nodes.Dan Sneddon1-0/+11
This change allows every overcloud node to optionally participate in any of the isolated networks. The optional networks are not enabled by default, but allow additional flexibility. Since the new networks are not enabled by default, the standared deployment is unchanged. This change was originally requested for OpenDaylight support. There are several use cases for using non-standard networks. For instance, one example might be adding the Internal API network to the Ceph nodes, in order to use that network for administrative functions. Another example would be adding the Storage Management network to the compute nodes, in order to use it for backup. Without this change, any deviation from the standard set of roles that use a network is a custom change to the Heat templates, which makes upgrades much more difficult. Change-Id: Ia386c964aa0ef79e457821d8d96ebb8ac2847231
2015-12-18Add Management Network For System Administration.Dan Sneddon2-0/+34
This change adds a system management network to all overcloud nodes. The purpose of this network is for system administration, for access to infrastructure services like DNS or NTP, or for monitoring. This allows the management network to be placed on a bond for redundancy, or for the system management network to be an out-of-band network with no routing in or out. The management network might also be configured as a default route instead of the provisioning 'ctlplane' network. This change does not enable the management network by default. An environment file named network-management.yaml may be included to enable the network and ports for each role. The included NIC config templates have been updated with a block that may be uncommented when the management network is enabled. This change also contains some minor cleanup to the NIC templates, particularly the multiple nic templates. Change-Id: I0813a13f60a4f797be04b34258a2cffa9ea7e84f
2015-12-18Merge "Allow for usage of pre-allocated IPs for the controller nodes"Jenkins2-9/+36
2015-12-15Merge "Pacemaker maintenance mode for the duration of Puppet run on update"Jenkins1-0/+2
2015-12-15Add update yaml backward compatibe with PublicVirtualIP on ctlplaneGiulio Fidente2-0/+5
In previous releases, when not using network isolation, we used to create two different VIPs for the ControlVirtualIP and the PublicVirtualIP both on the ctlplane network. Later we moved into a configuration with a single VIP instead so we need a compatibility yaml for those updating from old versions which preserves both the IPs; one of the two is deleted otherwise. Also updates README.md with a short description of the use case. Change-Id: Iae08b938a255bf563d3df2fdc0748944a9868f8e
2015-12-15Add sample environment file to document usage of predictable IPsGiulio Fidente1-0/+20
This change adds a sample environment file which documents how to assign to controllers a predictable IP on each network. Change-Id: I5be21428c66c82488af8e0240c1614ac3b9b55f0
2015-12-15Allow for usage of pre-allocated IPs for the controller nodesGiulio Fidente2-9/+36
This change adds a new *_from_pool.yaml meant to return an IP from a list instead of allocating a Neutron port, useful to pick an IP from a pre-defined list and making it possible to configure, for example an external balancer in advance (or dns), with the future IPs of the controller nodes. The list of IPs is provided via parameter_defaults (in the ControllerIPs struct) using ControllerIPs param. Also some additional VipPort types are created for the *VirtualIP resources. The VIPs were previously created using the same port resource used by the nodes, but when deploying with an external balancer we want the VIP resource to be nooped instead. Change-Id: Id3d4f12235501ae77200430a2dc022f378dce336
2015-12-14Pacemaker maintenance mode for the duration of Puppet run on updateSteven Hardy1-0/+2
This enables pacemaker maintenantce mode when running Puppet on stack update. Puppet can try to restart some overcloud services, which pacemaker tries to prevent, and this can result in a failed Puppet run. At the end of the puppet run, certain pacemaker resources are restarted in an additional SoftwareDeployment to make sure that any config changes have been fully applied. This is only done on stack updates (when UpdateIdentifier is set to something), because the assumption is that on stack create services already come up with the correct config. (Change I9556085424fa3008d7f596578b58e7c33a336f75 has been squashed into this one.) Change-Id: I4d40358c511fc1f95b78a859e943082aaea17899 Co-Authored-By: Jiri Stransky <jistr@redhat.com> Co-Authored-By: James Slagle <jslagle@redhat.com>
2015-12-08Enable TLS in loadbalancer if cert path is detectedJuan Antonio Osorio Robles1-0/+32
If there is a value for the certificate path (which should only happen if the environment for enabling TLS is used) then the loadbalancer will detect it and configure it's front ends correctly. On the other hand a proper override for the example environment was given, since this will be needed because we want to pass the hosts and protocols correctly so the tripleoclient will catch it and pass it to os-cloud-config Change-Id: Ifba51495f0c99398291cfd29d10c04ec33b8fc34 Depends-On: Ie2428093b270ab8bc19fcb2130bb16a41ca0ce09
2015-12-07Change for configuring use_forwarded_for value for NuageLokesh Jain1-0/+1
Added a parameter to Nuage ExtraConfig template for setting use_forwarded_for value required by Nuage metadata agent Change-Id: I02c15311272126c5e530f118fbfb4a8f6e11a620
2015-11-30Changes for configuring NuageLokesh Jain2-0/+22
Added ExtraConfig templates and environment files for Nuage specific parameters. Modified overcloud_compute.pp and overcloud_controller.pp to conditionally include Nuage plugin and agents. Change-Id: I95510c753b0a262c73566481f9e94279970f4a4f
2015-11-26Merge "Make load balancer deployment optional via template param"Jenkins1-0/+1
2015-11-26Merge "Add net_vip_map_external to be used for an external balancer"Jenkins1-0/+13
2015-11-25Merge "Enable trust anchor injection"Jenkins1-0/+6
2015-11-25Merge "Inject TLS certificate and keys for the Overcloud"Jenkins1-0/+9
2015-11-25Enable trust anchor injectionJuan Antonio Osorio Robles1-0/+6
This commit enables the injection of a trust anchor or root certificate into every node in the overcloud. This is in case that the TLS certificates for the controllers are signed with a self-signed CA or if the deployer would like to inject a relevant root certificate for other purposes. In this case the other nodes might need to have the root certificate in their trust chain in order to do proper validation Change-Id: Ia45180fe0bb979cf12d19f039dbfd22e26fb4856
2015-11-24Merge "Point registry at tripleoupstream"Jenkins1-10/+9
2015-11-24Make load balancer deployment optional via template paramGiulio Fidente1-0/+1
Adds control over the load balancer deployment via template param. Change-Id: I5625083ff323a87712a5fd3f9a64dd66d2838468
2015-11-24Add net_vip_map_external to be used for an external balancerDan Prince1-0/+13
Changes VipMap into a new NetVipMap resource which defaults to being the same as the 'old' VipMap. An environment file can be used to map NetVipMap instead to the net_vip_map_external.yaml which allows for passing in explicit Virtual IP addresses. It also ensures that references to the Virtual IPs are gathered from the VipMap resource and allows for an empty ControlPlaneIP parameter in the neutron port templates where it can be. Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: Ifad32e18f12b9997e3f89e4afe3ebc4c30e14a86
2015-11-23Merge "Sample environment with old ServiceNetMap value"Jenkins2-0/+42
2015-11-23Merge "Implement Advanced Firewalling support"Jenkins1-0/+2
2015-11-23Sample environment with old ServiceNetMap valueJames Slagle2-0/+42
The original value for the ServiceNetMap parameter had the Keystone Admin API service on the Internal API network. Later, it was moved to the ctlplane network by default. Users updating from clouds already deployed may not want to have the service moved, and we've occassionly seen it cause issues with services not getting restarted properly. This sample environment file documents the old value so that users can just optionally include it via -e to keep the services the same as they were when they originally deployed. Change-Id: I0b68542337a2f40e26df15fe7ac2da5aafe651d5