Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ctrl_pool
-
Labels:None
-
Story Points:2
-
Epic Link:
-
Sprint:DRP S17-1
-
Team:Data Release Production
Description
Remove pex_logging dependency in ctrl_pool.
Attachments
Issue Links
Activity
Paul Price
Paul: I think that the best solution (consistent with Andy's desires) is to use the environment variables in the properties file. They at least have the advantage that if they don't get set, the variables get set to "" and no particular harm is done.
I can either set JOBNAME variable from the "job" config parameter passed on the cmdline of ctrlPoolDemo.py, or require that the user set it themselves before starting. I'm not that sure how ctrlPool is used, so I'm not sure if making the setting voluntary on the part of the caller is a good thing or not.
Perry Gee
added a comment - Paul Price
Paul: I think that the best solution (consistent with Andy's desires) is to use the environment variables in the properties file. They at least have the advantage that if they don't get set, the variables get set to "" and no particular harm is done.
I can either set JOBNAME variable from the "job" config parameter passed on the cmdline of ctrlPoolDemo.py, or require that the user set it themselves before starting. I'm not that sure how ctrlPool is used, so I'm not sure if making the setting voluntary on the part of the caller is a good thing or not. If you're going to go that route, I think you should set LSST_JOBNAME from the job argument. Please don't make it the user's responsibility to set it.
Paul Price
added a comment - If you're going to go that route, I think you should set LSST_JOBNAME from the job argument. Please don't make it the user's responsibility to set it. Paul Price Are you done reviewing?
For whatever reason, there appear to be two logs set up by the old code – one per machine and pid using pex_logging and one using lsst.log.Log. I wanted to know if I should replicate this.
Perry Gee
added a comment - Paul Price Are you done reviewing?
For whatever reason, there appear to be two logs set up by the old code – one per machine and pid using pex_logging and one using lsst.log.Log. I wanted to know if I should replicate this. Yes, I marked the ticket as "Reviewed".
Don't worry about the one per machine+PID using pex_logging. I believe the new logger prefixes the hostname+PID into the log file, so they can be disentangled with grep.
Paul Price
added a comment - Yes, I marked the ticket as "Reviewed".
Don't worry about the one per machine+PID using pex_logging. I believe the new logger prefixes the hostname+PID into the log file, so they can be disentangled with grep . 
Perry Gee, there is an "API" already and it's rather simple to use (but it's not a Python API)
# define location of config file# define substitutions for variables in config file# run your applicationThe reason why we prefer to do it this way is that (as you said yourself) application code should not need to know how logging is handled - where logging output goes to and how it is formatted. Another reason is that by the time your application decides to change logging configuration other parts of application may be already logging something to default-configured logger.