Andy remark :

• once I built/installed qserv (it installs with the version u.fjammes.DM-622-g86a30ec72a) and run qserv-configure.py --help it tells me that default run dir is /usr/local/home/salnikov/qserv-run/2014_05.0. Would it be better to use run directory name that reflects current qserv version (u.fjammes.DM-622-g86a30ec72a) if possible? 2014_05.0 is the production version, there may be confusion if these two share the same directory name. Where does 2014_05.0 come from?

The idea is that several Qserv instances relying on different Qserv versions can use the same execution directory. This will allow not to re-create this execution directory each time the user switches its Qserv instance (of course the Qserv execution directory must only be used by one instance at a time).
What we could do is setting a configuration version number, and record the set of Qserv versions compliant with that version number. The run dir name could be : /usr/local/home/salnikov/qserv-run/configuration-version-number.
For now 2014_05.0 is the version number of the last Qserv release. Indeed I assume that all Qserv development version during a same sprint will be compliant with the same configuration version, this is false but acceptable as a first step. This ticket should propose a better solution.

Discussed during Dev Hangout between A. Salnikov and F. Jammes on Tue July 8, 8:30am-10:30am CEST :

• use eups generated version number (example : u.fjammes.DM-622-g86a30ec72a) as QSERV_RUN_DIR is complicated because this number is eups-generated and would make Qserv configuration tool eups dependant. This requires more reflexion :
  • Do we want to depend on eups or not for development ?
  • How to prevent conflict between qserv and eups version numbers if we set-up our own solution ?
    => wait for use-case and experience

• qserv-configure.py needs a dedicated option for migrating, by default qserv-configure.py will set-up a run-dir from scratch (for developers)

Fritz Mueller, Fabrice Jammes, what's the status of this ticket? It's in a very old epic.

Data directory isolation already exists (`-R` argument to qserv-configure); given this, and the fact that containers provide a more complete solution for execution directory isolation (and the fact that it is relatively low effort/time to recreate a fresh execution directory even if not using containers) this is deemed not worth the effort to fix.