 |
 |
Hi Daniel and KT, In my mind, installation/configuration/execution have to be tree distinct steps. I think this will ease Qserv maintenance and modularity. I'll try to provide a first implement of this modularity in https://jira.lsstcorp.org/browse/DM-622. It will respect next rules : - eups install directory will only contain immutable data - a qserv_run_dir directory will be created outside of eups stack, it will contains configuration data, but also data related to execution like datadir or pid files. - In DM-622, there will be a 1 to 1 relationship between a qserv_run_dir and a running Qserv instance. Here we will have to be carefull that a given qserv_run_dir is compliant with the Qserv instance which use it. I hope that my DM-622 proposal will be optimized in later tickets. About Daniel proposal, I think that generating configuration files from templates in init.d files can be a mix between configuration and execution ? But this feature is worth being discussed : indeed the real configuration data is in qserv.conf and templates files, and not in configuration files which are only build products. On my side, I think sysadmins would enjoy being able to update directly configuration files and then restart services with theses updated versions. Furthermore, a classical sysadmin may not have to understand Qserv template procedure. He may run it only one time after install step in order to generate configuration files, and then edit them by hand (This doesn't prevent all worker configuration files to be on a shared system which distribute them to all nodes.) That's why I propose to implement soon DM-622, using you previous remarks, and then to iterate from this first configuration procedure prototype ? Have a nice day, Fabrice On 05/30/2014 09:19 PM, Kian-Tat Lim wrote: > Daniel, > >> I would like to push for not generating any config files for qserv >> services during setup or installation. Instead, we create a template >> qserv.conf.in, that is human-editable. When trying to start any >> service (czar, worker, proxy, mysql?, etc.), the startup script >> reads that qserv.conf.in and generates the configuration for that >> particular service, logs it in the appropriate file, and starts it. >> If we do this, the services should almost always be consistently >> configured (or will be, after a process kill/restart). > I like this, except perhaps for the human-editable part. For > consistency across the cluster of machines, the meta-configuration needs > to either be in a single shared repository or distributed in read-only > form (the original source can be read/write). > > The other issue that comes to mind is this: if the > meta-configuration is updated, is there a way to determine which > underlying Qserv services need to be kicked/restarted, or do they all > need to be? One possible mechanism is to regenerate the config file, > check it against the current version, and leave the process alone if > nothing has changed. > ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the QSERV-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=QSERV-L&A=1