Bug 1392921 - [RFE] Automatically set SwiftMountCheck to true where it makes sense
Summary: [RFE] Automatically set SwiftMountCheck to true where it makes sense
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
Target Milestone: Upstream M3
: 11.0 (Ocata)
Assignee: Christian Schwede (cschwede)
QA Contact: Mike Abrams
Don Domingo
Depends On:
TreeView+ depends on / blocked
Reported: 2016-11-08 13:41 UTC by David Juran
Modified: 2017-05-17 19:38 UTC (History)
10 users (show)

Fixed In Version: openstack-tripleo-heat-templates-6.0.0-0.20170130212245.el7ost
Doc Type: Enhancement
Doc Text:
Feature: The mount_check option is now automatically enabled in Swift storage servers if the director setting SwiftRawDisks is used. SwiftRawDisks allows using additional disks on storage servers for Swift, and the mount_check option ensures improved failure handling. Reason: Result:
Clone Of:
Last Closed: 2017-05-17 19:38:03 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 413601 0 None None None 2016-12-21 12:41:54 UTC
Red Hat Product Errata RHEA-2017:1245 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 11.0 Bug Fix and Enhancement Advisory 2017-05-17 23:01:50 UTC

Description David Juran 2016-11-08 13:41:35 UTC
Description of problem:
If Swift is backed by a raw disk, as opposed to a directory, the mount_check option in the DEFAULT section of /etc/swift/{account,container,object}-server.conf should be set to true, or bad things will happen[*]

The mount_check swift option is set using the SwiftMountCheck parameter in the heat templates. I suggest we, based on the value of the SwiftRawDisks (see bug 1368218 for details), set a reasonable default for the SwiftMountCheck parameter

Additional info:
If one is using a raw disk for backing swift, and the SwiftMountCheck is set to false, if there is a disk failure on one of the nodes, creating containers will occasionally return an error code (503) to the end user. To further complicate things, even though 503 is returned, the container will still be created, even though the error was returned.

Comment 7 Thierry Vignaud 2017-02-14 17:16:15 UTC
Change is present in openstack-tripleo-heat-templates-6.0.0-0.20170130212245.el7ost (but it was already in tripleo-heat-templates-

Comment 12 errata-xmlrpc 2017-05-17 19:38:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.