Does PTL log match api need day and starttime/endtime arguments both?

Hi Guys,

I’m writing a test which will run for multiple days (30 day continuous load test) to check performance.
So I’m using log match api with start and end time arguments(to check in multiple day log files), but in PTL (@ log_lines method – internally called by log_match to get matching lines from log file) starttime and endtime are not used
And if day argument is not given then test will take current day to get log file.

Using day and starttime/endtime both arguments will cause conflict(if user passes starttime/endtime timestamps of past day).

So my question is: can we remove day argument from log_match api ?
starttime/endtime hold both date and time information so we can achieve what “day” argument is intended for using start and/or end time.

Thanks,

Since we can provide starttime and endtime in all log match funcs, day argument becomes redundant, So I think it will safe to remove day argument.

it is not clear from the log_match documentation what format start time and endtime takes which needs to be fixed.

  • starttime ( int ) – If set ignore matches that occur before specified time
  • endtime ( int ) – If set ignore matches that occur after specified time

If they takes HHMMSSYYYMMDD (or something similar) then I agree we do not need day argument explicitly. PTL can parse day internally.

starttime and endtime will provide current time in seconds(epoch time) which includes day and time information.
As you said using this information PTL can parse day easily.

Guys, let me know if any further comments are there.

Otherwise I will go ahead with the fix implementation.

Thanks @vishwaks. design posted at following looks good to me
https://pbspro.atlassian.net/wiki/spaces/PD/pages/1005682689/Remove+day+argument+from+log+match+api+of+PTL

@vishwaks design looks good. However you created page under PP-506’s design page, you need to move it to parent level.

Thanks @anamika and @hirenvadalia.

I moved page to top level.

:+1:

The proposal makes sense to me, thanks for fixing the interface.

Thanks @agrawalravi90.