Running from arbitrary locations is something that we should be able to do, reusing configuration locations and not depending on the current working directory holding a ceph.conf file.


Interested Parties

Current Status

Issue #6398 already describes what the expectation is to not depend on the current working directory and prevent users to be forced to go to a determined location.

Detailed Description

Backwards compatibility is the primary concern. The tool can continue to support the "feature" of running where a ceph.conf file exists, but not without a big warning. The new default would be to use a directory specific to ceph-deploy that has several directories to point to what config file should be used.
For example, you could have a directory structure that resembles this (for a default config):


If the configuration is not specified, it will use default unless it is running from where a ceph.conf file is located. This directory structure would allow to contain several different configurations to be used without clobbering other files used for other environments (a test cluster for example) and those can be used by specifying them on the command line. For a test cluster named "test1", installing would look like:
ceph-deploy --conf test1 install node1
CEPH_DEPLOY_CONF=test1 ceph-deploy install node1

So both flags and environment variables can be used.
If a user does not want to follow what ceph-deploy considers a normal directory location, it can/will use a custom location if an absolute path is passed in. If the configuration for the `test1` cluster exists somewhere else, like in `/opt/ceph_configs/test1` this could look like this:
ceph-deploy --conf /opt/ceph_configs/test1 install node1
CEPH_DEPLOY_CONF=/opt/ceph_configs/test1 ceph-deploy install node1

Work items

Coding tasks

  1. Be able to run independently from the location of ceph.con
  2. Interpret absolute paths or names as part of the directory structure
  3. Have clear warnings when a user is running from a ceph.conf path

Documentation tasks

  1. Explain the new behavior (that should retain backwards compatibility) for running in any path