aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/extraconfig
AgeCommit message (Collapse)AuthorFilesLines
2016-01-18Merge "Set the name property for all deployment resources"Jenkins9-0/+16
2016-01-06Enable Dell Storage Center iscsi Backends in Cinderrajinir1-0/+87
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/+86
2015-12-21MidoNet heat templatesJaume Devesa1-0/+119
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-10Set the name property for all deployment resourcesSteve Baker9-0/+16
There are two reasons the name property should always be set for deployment resources: - The name often shows up in logs, files and API calls, the default derived name is long and unhelpful - Sorting by name determines the merge order of os-apply-config, and the execution order of puppet/shell scripts (note this is different to resource dependency order) so leaving the default name results in an undetermined order which could lead to unpredictable deployment of configs This change simply sets the name to the resource name, but a future change should prepend each name with a run-parts style 2 digit prefix so that the order is explicitly stated. Documentation for extraconfig needs to clearly state what prefix is needed to override which merge/execution order. For existing overcloud stacks, heat currently replaces deployment resources when the name changes, so this change Depends-On: I95037191915ccd32b2efb72203b146897a4edbc9 Change-Id: Ic4bcd56aa65b981275c3d4214588bfc4de63b3b0
2015-12-07Change for configuring use_forwarded_for value for NuageLokesh Jain1-0/+7
Added a parameter to Nuage ExtraConfig template for setting use_forwarded_for value required by Nuage metadata agent Change-Id: I02c15311272126c5e530f118fbfb4a8f6e11a620
2015-12-03Merge "Minor fixes to TLS related resources"Jenkins2-5/+3
2015-11-30Changes for configuring NuageRohit Pagedar1-0/+50
Added ExtraConfig templates and environment files for Nuage Networks specific parameters. Modified overcloud_compute.pp to conditionally include nuage-metadata-agent. Change-Id: I28106d8e26ad4d0158fe5e3a13f2f7b21e5c0b28
2015-11-30Changes for configuring NuageLokesh Jain2-0/+125
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-26Minor fixes to TLS related resourcesJuan Antonio Osorio Robles2-5/+3
* Fixed a comment to avoid ambiguity with concepts in Heat * Removed default values from necessary parameters in the TLS environment * Simplified setting of the cert/key into a file. Change-Id: I351778150a6fbf7affe1a0fddb1abb9869324dfc
2015-11-25Output the SSL Certificate and Key modulusMark Chappell2-0/+20
Provides a simple mechanism to verify the correct certificates landed. A quick and simple way to verify SSL certificates were generated for a given key is by comparing the modulus of the two. By outputing the key modulus and certificate modulus we offer a way to verify that the right cert and key have been deployed without compromising any of the secrets. Change-Id: I882c9840719a09795ba8057a19b0b3985e036c3c
2015-11-25Enable trust anchor injectionJuan Antonio Osorio Robles2-0/+83
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-23Inject TLS certificate and keys for the OvercloudJuan Antonio Osorio Robles2-0/+109
This is a first implementation of adding TLS termination to the load balancer in the controllers. The implementation was made so that the appropriate certificate/private key in PEM format is copied to the appropriate controller(s) via a software deployment resource. And the path is then referenced on the HAProxy configuration, but this part was left commented out because we need to be able to configure the keystone endpoints in order for this to work properly. Change-Id: I0ba8e38d75a0c628d8132a66dc25a30fc5183c79
2015-11-12Enable Equallogic Backends in Cinderrajinir1-0/+86
Enables support for configuring Cinder with a Dell Equallogic storage backend. This change adds all relevant parameters for: - Equallogic PS-Series (iSCSI) Change-Id: Ia0f71863cfb12f2cdda43dcf707a9a7145963001
2015-11-11Merge "Allow customization of Ceph client user"Jenkins1-1/+13
2015-11-10Merge "Allow customization of the Ceph pool names"Jenkins1-2/+20
2015-11-05Add support to tag patch port for Cisco Nexus1000v VSM bringupShiva Prasad Rao1-0/+5
In some deployments we will need to tag the patch port connecting to vsm-br in order for traffic to go out. This patch takes passes the vlan parameter to the puppet. Change-Id: I18734ae39007985769db9371abe1740e0f2872f7
2015-11-05Allow customization of Ceph client userGiulio Fidente1-1/+13
Previously we enforced the Ceph user used by the OpenStack clients to be named 'openstack', this change allows for customization of such a name. Change-Id: Idef3e1ed4e8e21b645081869b8d6fad2329bdc60
2015-11-05Allow customization of the Ceph pool namesGiulio Fidente1-2/+20
This is useful in those scenarios were we want to use an external Ceph deployment with multiple overclouds. Change-Id: I1749d2a6547f6ce25843709e46a1447e8d42cfff
2015-11-04Merge "Cisco Nexus ML2 MD: Need unique key for server level keys in hieradata"Jenkins1-3/+7
2015-10-15Cisco Nexus ML2 MD: Need unique key for server level keys in hieradatatiswanso1-3/+7
Due to a limitation in the puppet version used in RHEL7 there is no simple way to scope a 2nd level hiera hash key with the create_resources + defined types pattern. Lack of the .each method support prior to puppet 4.0 is the problem here. This template change works around the problem by explicitly adding the hostname to the hieradata for a server under a nexus switch. The duplicate server names under different switches is needed for vPC config scenarios. Closes-bug: #1506546 Change-Id: I03b866fb440e968c9f86ae93942b687e7165a065
2015-10-12Set shared secrets, keys and passwords as hiddenJuan Antonio Osorio Robles1-0/+2
Change-Id: Ieb27729c6b33ffc849d07200ec0d42508214956e Closes-Bug: #1399793
2015-09-30Enable Cisco N1KV driverShiva Prasad Rao1-0/+174
This enables support for the Cisco N1kv driver for the ML2 plugin. It also configures the Nexus 1000v switch. Co-Authored-By: Steven Hillman <sthillma@cisco.com> Depends-On: I02dda0685c7df9013693db5eeacb2f47745d05b5 Depends-On: I3f14cdce9b9bf278aa9b107b2d313e1e82a20709 Change-Id: Idf23ed11a53509c00aa5fea4c87a515f42ad744f
2015-09-25Example of passing per-node config data in pre_deploy configSteven Hardy1-0/+56
Shows one method of passing a map of data in to the pre_deploy extraconfig interface, such that it could be used in combination with https://review.openstack.org/#/c/215013/ to create a node uuid specific hieradata file, or to perform some other non-puppet per-node configuration. This would be used by specifying an environment file like: resource_registry: OS::TripleO::ControllerExtraConfigPre: puppet/extraconfig/pre_deploy/per_node.yaml parameter_defaults: NodeDataLookup: | {"AB4114B1-9C9D-409A-BEFB-D88C151BF2C3": {"foo": "bar"}, "8CF1A7EA-7B4B-4433-AC83-17675514B1B8": {"foo2": "bar2"}} Change-Id: I62e344669e0ca781dd93d3f7d2190b70299877c2
2015-09-22Remove nameserver lookup dependency from Cisco ML2 CollectMacConfig.tiswanso1-2/+11
The collection of hostname to MAC mappings done in AllNodesPostDeploy uses 'hostname -f' to get the FQDN for each node. This form of the command causes a nameserver lookup for the domain name. A timing issue has been seen where the hostname lookup fails due to the nameserver not having the mapping yet. The solution is to hardcode the domain to 'localdomain' as is done in a few other patches--ie. see controller-puppet.yaml. Change-Id: Ibea50fcc6b9f22ca163ff063e0dc9ca69dff5f34
2015-09-17Support new form of servers config for ML2 cisco nexus allnodes config.tiswanso1-2/+1
The puppet-neutron changes to remove the usage of ERB templates require changing the format of the 'servers' hash/dictionary to include a key for use with puppet's create_resources directly from hiera data. Depends-On: I401371c9e5176de7ce19d4d4e878e9f2e69aab80 Change-Id: I950b7fb019dd8dd072592618b968a19df5c9c884
2015-09-17Port Cisco Nexus/UCSM ExtraConfig to AllNodesSteven Hardy2-141/+326
Switch the implemention from a pre_deploy ExtraConfig to an AllNodesExtraConfig, so we can collect the mac->hostname mapping for all nodes, then calculate a NexusConfig based on that and a provided mapping of switch ports to mac address. The same conversion is also done to the NetworkUCSMHostList: The port mappings are provided via parameter_defaults like: parameter_defaults: NetworkNexusConfig: { "bxb-tor-1": { "username": "admin", "ssh_port": 22, "password": "lab", "ip_address": "10.86.7.204", "nve_src_intf": 0, "physnet": "datacentre", "servers": { "fa:16:3e:fa:be:ef": "1/11", "fa:16:3e:fa:5e:cf": "1/23", "fa:16:3e:fa:12:34": "2/34" } } } NetworkUCSMHostList: 'fa:16:3e:fa:be:ef:profile1' This results in an entry like this appended to /etc/puppet/hieradata/neutron_cisco_data.yaml: neutron::plugins::ml2::cisco::nexus::nexus_config:\ {"bxb-tor-1": {"username": "admin", "nve_src_intf": 0, "ssh_port": 22, "servers": {"overcloud-compute02": "2/34", "overcloud-compute01": "1/23", "overcloud-control01": "1/11"}, "password": "lab", "ip_address": "10.86.7.204", "physnet": "datacentre"}} neutron::plugins::ml2::cisco::ucsm::ucsm_host_list: overcloud-control01:profile1 Co-Authored-By: Rob Pothier <rpothier@cisco.com> Co-Authored-By: Tim Swanson <tiswanso@cisco.com> Change-Id: I372c3ffb6bd85b7239fcb9f3fc4fa51cd4a39332
2015-09-16Big Switch Neutron ML2 plugin integrationJiri Stransky1-0/+73
Add support for Big Switch Neutron ML2 plugin. Makes sure that the package is present and sets up the [restproxy] section in ml2_conf.ini. This also adds support for setting the ovs_use_veth option in l3_agent.ini. There is no support for this in puppet-neutron l3 class and it probably doesn't make sense adding it there, because this setting isn't relevant for all l3 agent drivers, it's specific to OVSInterfaceDriver. The ovs_use_veth option is also added to dhcp_agent.ini. Change-Id: I99635e25b2099dacce68154fe14693d6f06ac19f
2015-09-16Merge "Enable Cisco Nexus and UCSM plugins"Jenkins1-0/+141
2015-09-15Enable Cisco Nexus and UCSM pluginsRobert Pothier1-0/+141
This enables support for the Cisco UCS Manager and Cisco Nexus plugins Change-Id: I1bc28a4768d5d6857a0504ca1f77dd71259570b8
2015-08-13Support for using external Ceph clustersDan Prince1-0/+65
This patch adds support for using an externally managed Ceph cluster with the TripleO Heat templates. For an externally managed Ceph cluster we initially only deploy the Ceph client tools, install the 'openstack' user keyring, and generate the ceph.conf. This matches what we do for managed Ceph installations and is a good first start. No other Ceph related services are installed or managed. To enable use of a Ceph external cluster simply add the custom Heat environment file environments/puppet-ceph-external.yaml to your heat stack create/update command and make sure to set the required CephClientKey, CephExternalMonHost, and CephClusterFSID variables. Change-Id: I0a8b213ce9dfa2fc4e62ae1e7631466e5179fc2b
2015-07-20Fix Puppet Configuring NetApp Cinder BackendRyan Hefner1-3/+3
It was incorrectly assumed that Puppet variables assigned to a defined class (as seen in cinder-netapp.yaml) would be applied to any resources created with that type. This is not how Puppet works. The full range of configuration parameters to cinder::backend::netapp have been added back in. They are still pulling from Hiera like they were intended before, but it needs to be a little more explicit for Puppet to be happy. Change-Id: I2e00eae829713b2dbb1e4a5f296b6d08d0c21100
2015-07-06Wire in Controller pre-deployment extraconfigSteven Hardy4-0/+183
The recently added cinder-netapp extraconfig contains some additional hieradata which needs to be applied during the initial pre-deployment phase, e.g in controller-puppet.yaml (before the manifests are applied) so wire in a new OS::TripleO::ControllerExtraConfigPre provider resource which allows passing in a nested stack (empty by default) which contains any required "pre deployment" extraconfig, such as applying this hieradata. Some changes were required to the cinder-netapp extraconfig and environment such that now the hieradata is actually applied, and the parameter_defaults specified will be correctly mapped into the StructuredDeployment. Change-Id: I8838a71db9447466cc84283b0b257bdb70353ffd