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