tree 0ada2d454ba62d8fa35b106b80b512e0154e13ee
parent 9d7e74e57c73d25e214e0269dbd9d342e8cd960c
author Clay Gerrard <clay.gerrard@gmail.com> 1503954198 -0700
committer Clay Gerrard <clay.gerrard@gmail.com> 1503954198 -0700

Create correct directory layout for swift on purpose.

The pre-existing configuration for swift on devstack set's the
*-server's devices option (the root of the servers list of devices) to:

    devices = /opt/stack/data/swift/1

where "1" is the node_number, and will be 2, 3, ... N if the devstack
machine is built with more than one swift node/device (pretty sure no
one does that on devstack ever).

The device(s) in the rings are named (perhaps confusingly similar to the
swift loopback image) just "sdb1", so all storage servers expect to have
a $STACK_USER writeable file system at:

    os.path.join(<devices_root>, "sdb1")

That directory does not exist when you start up a devstack [1].

Currently Swift's object-server's require that directory exist before
they write data into it (even with mount_check = false!).

Unfortunately however, with mount_check=false the account/container
servers are able to create the device directory when it does not exist
[2].  Which can lead to some unfortunate results with permissions on
some deployments using mount_check = false (e.g. testing or
containerized environments).  Fixing this issue [3] uncovered the
previously benign [4] mis-configuration in devstack.

Attempting

1. It was lost a long while ago I7c65303791689523f02e5ae44483a6c50b2eed1e
2. Essentially they want to:

    mkdir -p /opt/stack/data/swift/1/sdb1/containers/<part#>

... but end up creating the "sdb1" dir too!
3. I3362a6ebff423016bb367b4b6b322bb41ae08764
4. Benign because the object-server share their device with the
account-container devices and they would create the dirs before trying
to write an object.  It was incorrect, but worked by happenstance, which
is nearly as good as worked on purpose.

Change-Id: I52c4ecb70b1ae47e613ba243da5a4d94e5adedf2