# Use an existing qserv_run_dir with a new Qserv instance/binary

XMLWordPrintable

#### Details

• Type: Story
• Status: Won't Fix
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
None
• Story Points:
4
• Team:
Data Access and Database

#### Description

Here's what should be added to qserv-configure.py :

• edit \$QSERV_RUN_DIR/admin/qserv.conf and change Qserv instance dir to current one (which qserv-configure.sh),
• check compliance of QSERV_RUN_DIR with new Qserv instance (version check ?) and/or update configuration files,

#### Activity

Hide
Fabrice Jammes added a comment -

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.

Show
Fabrice Jammes added a comment - 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.
Hide
Fabrice Jammes added a comment - - edited

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)
Show
Fabrice Jammes added a comment - - edited 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)
Hide
Tim Jenness added a comment -

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

Show
Tim Jenness added a comment - Fritz Mueller , Fabrice Jammes , what's the status of this ticket? It's in a very old epic.
Hide
Fritz Mueller added a comment -

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.

Show
Fritz Mueller added a comment - 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.

#### People

Assignee:
Fabrice Jammes
Reporter:
Fabrice Jammes
Watchers:
Andy Salnikov, Daniel Wang [X] (Inactive), Fabrice Jammes, Fritz Mueller, Jacek Becla, Kian-Tat Lim, Serge Monkewitz, Tim Jenness