PP-261: micro-second time stamp for daemon logging


#12

@suresht

One minor comment… please also specify that
qmgr -c "set server highres_time_log_enable=0"
also disables high-res logging. The same as unsetting the value (default is off).

I assume this is what the implementation would have done anyway.


#13

@mkaro
Thanks for your comments. I have updated the EDD accordingly.


#14

I’m not sure why we are setting this in qmgr for all daemons. Shouldn’t this be set on the local node level for mom and comms (in pbs.conf until we have a better place to handle this for the daemons) since they can be run on different machines and should not have to contact the server to determine which level of time stamp they should be using? This seems fine to me for the server and scheduler since the scheduler can run if it can talk to the server. However, the comm and mom can run without being able to contact the server.


#15

From an end-user point of view, it seems much better to present a single interface for choosing which timestamp to log. It would be inconvenient to set multiple interfaces to change what ought to be uniform across the product.


#16

Fully agree. However, until we move all of the daemon configurations to qmgr then I don’t want to do piece mail.


#17

I disagree that we should wait until we move everything to qmgr to start moving in the right direction. If we continue on the path we are going now, we’ll just have that many more options to worry about being backwards compatible with.

Bhroam


#18

I think this statement by Subhasis applies here as well. Until we decide to start/staff “all configurations via qmgr project” we should continue to use the pbs.conf file for configuring daemons that do not currently get their configurations from qmgr.


#19

If the idea is to enable microsecond logging on a per-node basis, then I agree that pbs.conf is the right place for this configuration data. If it is a global option, then I believe that qmgr is the right place. The design document does not specify whether it is per-node or global. Please update the design document.


#20

@mkaro
I have updated the design document in order to say that it is node level option and hence we are going with pbs.conf. Please look into it and provide your sign off.


#21

Why did you remove the line regarding syslog? You should state that this feature applies only to local PBS logs and not to syslog.


#22

I find the phrase “this is a node level option” confusing. From what I can tell, it’s not just for moms. The server and scheduler will start using high res logging as well if this is turned on. You could even turn this on/off per-daemon if you use environmental variables while starting the individual daemons. It’s just easier to set it on a per-daemon basis for each mom because they use separate pbs.conf files. I’d use the term “per-daemon” instead of “node level”

Bhroam


#23

I agree with @bhroam. I made a similar comment with regard to PP-288 (asynchronous logging) earlier today. I would suggest that both features provide similar capabilities in terms of turning them on/off per daemon.


#24

@mkaro Thanks for catching this. I have added back the note about syslog. Please look into it and provide your sign off / further comments.


#25

@bhroam Thanks for your suggestion. we now call it as per-daemon option.


#26

Thank you for adding the line regarding syslog. How is it that this feature may be enabled/disabled per-daemon while the configuration setting is stored in pbs.conf? Are you expecting admins to set environment variables to override the value in pbs.conf when they start each service? That would make it difficult to use /etc/init.d/pbs to start/stop/restart the PBS Pro services. If it truly is per-daemon, then I think you need to store the setting in qmgr (for the server and scheduler) and mom_priv/config (for each mom).


#27

@mkaro, If you dislike the term per-daemon, how about it gets dropped altogether. The use of pbs.conf is well documented. There’s no real reason to explain it further in this design.

Bhroam


#28

@bhroam, It’s not that I dislike the term, but we may be using different definitions of the term per-daemon. If the intent is to enable microsecond timestamps for the server and disable them for the scheduler, then I don’t think pbs.conf is the right place to define the setting. I would ask that this be clarified in the design document.


#29

@mkaro/@bhroam,
As per the discussion we had, I have updated the EDD. Can you please look into it and give your comments/sign off.


#30

Thanks for clearing that up. I like it now.

Bhroam


#31

@suresht: That works for me. You have my sign off.