ca8a591f74
The default method for updating Swift rings - such as adding new nodes to existing rings - is to do the update manually and then distribute the new rings to all Swift nodes. At the moment Heat builds rings by default when a Swift node is brought up. We do not want this to happen when Heat is being used to bring up new Swift nodes for inclusion in an existing overcloud Swift cluster. This patch checks for a piece of meta-data swift.ring-build, which defaults to True. If instead the metadata is set to False or F then Swift rings will not be built. The metadata can be set to False or F by an operator at the heat command-line, in particular at heat update to an existing overcloud stack. Change-Id: Ia2544d560b20d895b3b0b19bc7c91542ad58509d |
||
---|---|---|
.. | ||
environment.d | ||
install.d | ||
os-apply-config/etc/swift | ||
os-refresh-config/configure.d | ||
README.md | ||
element-deps | ||
source-repository-swift |
README.md
Common element for swift elements
Configuration
swift: devices: r1z-192.0.2.6:%PORT%/d1 - A comma separated list of swift storage devices to place in the ring file. - This MUST be present in order for o-r-c to successfully complete. zones: - Servers are divided amongst separate zones if the swift.zones metadata is greater than the default of 1. Servers are placed in zones depending on their rank in the scaled-out list of Swift servers in the yaml template used to build the overcloud stack. The scaleout rank N is: SwiftStorage|controller. The appropriate zone is calculated as: zone = N % swift.zones + 1. - To enable this calculation, the devices data takes the form of: r1z%%-192.0.2.6:%PORT%/d1 hash: randomstring - A hash used to salt paths on storage hosts