To deploy Ceph on IPv6, we need to enable ms_bind_ipv6 in addition
to passing the list of MON IPs in brackets.
Change-Id: I3644b8fc06458e68574afa5573f07442f0a09190
Fixed the heat_template_version of these YAML files to the liberty
release version according to HOT template specs.
Change-Id: Ic5e0d843f7e164c59fb1737e52ef4cf6ad4df77f
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
Currently the permissions for the CA file that is injected (if the
environment is set), doesn't permit users that don't belong to the group
that owns the file to read it. This is too restrictive and isn't
necessary, as the certificate should be public.
This is useful in the case where we want a service that can't read the
certificate chain (or bundle) to be able to read that CA certificate.
This is the case for the MariaDB version that is being used in CentOS
7.1 for example.
Change-Id: I6ff59326a5570670c031b448fb0ffd8dfbd8b025
We were incorrectly wiring the rbd user to the relevant glance
module parameter, making it was impossible to customize the
rbd user when using an external Ceph.
Change-Id: Ibe4eaedf986a9077f869c6530381e69ee0281f5b
Deploy a TripleO overcloud with OpenContrail Vrouter plugin configured
to interact with an existing OpenContrail Server Manager.
OpenContrail is an Apache 2.0-licensed project that is built using
standards-based protocols and provides all the necessary components for
network virtualization–SDN controller, virtual router, analytics engine,
and published northbound APIs. It has an extensive REST API to configure
and gather operational and analytics data from the system.
Co-Authored-By: Jiri Stransky <jistr@redhat.com>
Change-Id: I699a7c4ea09d024fe4d70c6a507c524f0a7aafd5
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
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
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
Added a parameter to Nuage ExtraConfig template for setting
use_forwarded_for value required by Nuage metadata agent
Change-Id: I02c15311272126c5e530f118fbfb4a8f6e11a620
Added ExtraConfig templates and environment files
for Nuage Networks specific parameters.
Modified overcloud_compute.pp to conditionally
include nuage-metadata-agent.
Change-Id: I28106d8e26ad4d0158fe5e3a13f2f7b21e5c0b28
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
* 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
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
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
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
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
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
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
This is useful in those scenarios were we want to use an external
Ceph deployment with multiple overclouds.
Change-Id: I1749d2a6547f6ce25843709e46a1447e8d42cfff
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
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
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
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
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
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
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
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
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
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