aboutsummaryrefslogtreecommitdiffstats
path: root/swift-storage.yaml
AgeCommit message (Collapse)AuthorFilesLines
2015-06-17Allow control of hostname formattingSteven Hardy1-0/+4
Currently, we use the heat default server names, which results in some fairly unreadable hostnames due to the level of nesting in the templates. e.g ov-sszdbj5rdne-0-bhseh65edxv6-Controller-zoqc6tlypbdp Instead, we allow the user to specify a format string per role, defaulted to a string which formats the name e.g <stackname>-controller-<index> e.g overcloud-controller-0 Optionally additional hostname components (not replaced by heat) could be added, such that deployment time customization of hostnames via firstboot scripts (e.g cloud-init) may be possible. Should anyone wish to maintain the old heat-generated names, they can pass an empty string via these parameters, which heat will treat as if no "name" property was provided to OS::Nova::Server. Change-Id: I1730caa0c2256f970da22ab21fa3aa1549b3f90b
2015-06-08Config & deployments to update overcloud packagesSteve Baker1-0/+6
This change adds config and deployment resources to trigger package updates on nodes. The deployments are triggered by doing a stack-update and setting one of the parameters to a unique value. The intent is that rolling update will be controlled by setting breakpoints on all of the UpdateDeployment resources inside the role resource groups. Change-Id: I56bbf944ecd6cbdbf116021b8a53f9f9111c134f
2015-05-26Switch net-config templates to use OS::stack_idDan Prince1-1/+1
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
2015-05-26Add isolated network ports to swift rolesDan Prince1-0/+28
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
2015-05-20Overcloud: bump HOT version to 2015-04-30Dan Prince1-1/+1
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
2015-04-28Remove hardcoded references to .novalocal in hostnamesGiulio Fidente1-1/+1
Remove references to the .novalocal domain part in the hosts file. Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
2015-04-24Separate the network configuration per flavor.Dan Sneddon1-0/+9
This change allows a different network config for each family of hosts. For instance, the controller may have a different network configuration than a block storage node. This change adds a declaration for each family in the overcloud-resource-registry.yaml & overcloud-resource-registry-puppet.yaml. Change-Id: I083df7ebbb535f97d8ddec2ac0e06281c55986cd
2015-04-24Enable passing optional first-boot user-dataSteven Hardy1-1/+6
Currently all the OS::Nova::Server resource created don't pass any user-data. It's possible to pass user-data as well as using heat SoftwareConfig/SoftwareDeployment resources, and this can be useful when you have simple "first boot" tasks which are possible either via cloud-init, or via simple run-once scripts. This enables passing such data by implementing a new provider resource OS::TripleO::NodeUserData, which defaults to passing an empty mime archive (thus it's a no-op). An example of non no-op usage is also provided. Change-Id: Id0caba69768630e3a10439ba1fc2547a609c0cfe
2015-01-27Swift: set default replicas to 3Dan Prince1-1/+1
Our existing default (replicas == 1) means that no data (or copies) is being replicated in a multi-node Swift environment. This seems like a bad production default setting and could easily slip by if not set. Setting it to 3 shouldn't hurt anything and seems to follow suit with what several production installers (based around Puppet) actually use. If using an installation with less than 3 swift nodes I believe swift will do its best, and still work fine. FWIW I noticed this when testing a multi-node Puppet swift installation and was surprised when I didn't see any *data files getting replicated across the storage cluster. Change-Id: I44bdfff7aae6bdf845b79ca1f8f450c22113caed
2015-01-27Remove unused swift params from -without-mergepyDan Prince1-33/+0
In doing the Puppet version of the Swift role I noticed 4 parameters which we apply to storage nodes which should not be required. This patch drops the following parameters from the swift-storage and swift-storage-puppet nested stacks which should not be required. 1) ControllerIP: There is no reason a storage node should need the IP address of the controller. The swift proxy would need this information in order to be able to contact keystone. This swift-proxy is not installed on storage nodes so we can drop the parameter here. 2) NeutronEnableTunnelling: There is no reason for Neutron to be installed on Swift storage nodes. No need to create an OVS bridge either. 3) NeutronNetworkType: Similar to above. No neutron requirements exist here so this parameter is not required. 4) Password: This only applies to the the swift-proxy which is currently part of our controller role. Storage nodes shouldn't need the keystone service-password for any reason. Change-Id: Icbf05363475c388fc722277da3d3d00a7355b19a
2015-01-09Add SwiftMountCheck to overcloud-without-mergepyDan Prince1-0/+1
This was added in I36fece56bafa9fe9c4883b572687b3fc819eeae1 and is missing from overcloud-without-mergepy. Change-Id: I5c2566cc77247574f8d687eaab8094de481a8c67
2015-01-09Add SwiftMinPartHours to overcloud-without-mergepyDan Prince1-0/+6
This was added in Icc5e431a7e2884b3ca3a255b6fd901619bc98460 and is missing from overcloud-without-mergepy. Change-Id: I1273b646c04783712fd3f8baccafead11817689c
2014-11-27Remove default flavor from every templateSteve Kowalik1-1/+2
With the push to using the new setup-flavors provided by os-cloud-config, the default flavor will no longer be called 'baremetal', and Heat will always validate the default even if it is overridden. To that end, remove the default flavor from every flavor definition. Just to be certain, also add a custom_constraint to every flavor definition that was missing it. Change-Id: I24251e73be4e86738857f73b89499f592c4908de
2014-11-12Add swift.mount-check metadataEamonn O'Toole1-0/+5
We've submitted a patch (https://review.openstack.org/#/c/130172/) to set the value of mount_check to swift.mount-check if it exists, and otherwise to set mount_check to false. By default TripleO deployments set mount_check to false since they do not use mounted disks to store data. However we (HP) and others are now using TripleO to deploy Swift servers with mounted drives for data, in which case mount_check should be set to True. This change adds swift.mount-check data and sets it to the value of the SwiftMountCheck parameter, which has a default value of False. Change-Id: I36fece56bafa9fe9c4883b572687b3fc819eeae1
2014-10-21Add converted version of block and object storagePeter Belanyi1-0/+168
This patch extends the previous 'Don't use merge.py for overcloud' commit with the cinder-storage.yaml and swift-storage.yaml templates. Requirements for this to deploy: 1. Block and object storage images have to be built (overcloud-cinder-volume and overcloud-swift-storage) 2. The images have to be loaded by devtest_overcloud.sh OVERCLOUD_CINDER_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-cinder-volume.qcow2) OVERCLOUD_SWIFT_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-swift-storage.qcow2) Change-Id: I45f9d9f051970a83e26c0fd924d7c98276958113