Re: [PATCH v2 6/7] dts: refactor logging configuration

[Jeremy Spewock <jspewock@iol.unh.edu>]

On Wed, Feb 14, 2024 at 2:49 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>
> Hi Jeremy,
>
> Just a reminder, please strip the parts you're not commenting on.
>
<snip>
> > > +    def __init__(self, *args, **kwargs):
> > > +        """Extend the constructor with extra file handlers."""
> > > +        self._extra_file_handlers = []
> > > +        super().__init__(*args, **kwargs)
> > >
> > > -        One handler logs to the console, the other one to a file, with either a regular or verbose
> > > -        format.
> > > +    def makeRecord(self, *args, **kwargs):
> >
> > Is the return type annotation here skipped because of the `:meta private:`?
> >
>
> Basically. We're modifying a method defined elsewhere, but there's no
> harm in adding the return type.
>
<snip>
> > > +    logging.setLoggerClass(DTSLogger)
> > > +    if name:
> > > +        name = f"{dts_root_logger_name}.{name}"
> > > +    else:
> > > +        name = dts_root_logger_name
> > > +    logger = logging.getLogger(name)
> > > +    logging.setLoggerClass(logging.Logger)
> >
> > What's the benefit of setting the logger class back to logging.Logger
> > here? Is the idea basically that if someone wanted to use the logging
> > module we shouldn't implicitly make them use our DTSLogger?
> >
>
> Yes. We should actually set it to whatever was there before (it may
> not be logging.Logger), so I'll change that.+
>
>
<snip>
> > > @@ -137,6 +141,7 @@ def run(self):
> > >
> > >              # for all Execution sections
> > >              for execution in self._configuration.executions:
> > > +                self._logger.set_stage(DtsStage.execution)
> >
> > This ends up getting set twice in short succession which of course
> > doesn't functionally cause a problem, but I don't exactly see the
> > point of setting it twice.
>
> I'm not sure what you're referring to. The stage is only set once at
> the start of each execution (and more generally, at the start of each
> stage). It's also set in each finally block to properly mark the
> cleanup of that stage. There are two finally blocks in the execution
> stage where that could happen, but otherwise it should be set exactly
> once.

You're right, I misread where it was being set the second time in the
code when I was reading this and thought there was a way where it
could get set twice but it cannot. Apologies, it makes sense that you
weren't sure what I was referring to because what I was referring to
doesn't exist.

>
> >  We could either set it here or set it in
> > the _run_execution, but i think it makes more sense to set it in the
> > _run_execution method as that is the method where we are doing the
> > setup, here we are only initializing the nodes which is still in a
> > sense "pre execution."
>
> Init nodes was pre-execution before the patch. I've moved it to
> execution because of two reasons:
> 1. The nodes are actually defined per-execution. It just made more
> sense to move them to execution. Also, if an error happens while
> connecting to a node, we don't want to abort the whole DTS run, just
> the execution, as the next execution could be connecting to a
> different node.
> 2. We're not just doing node init here, we're also discovering which
> test cases to run. This is essential to do as soon as possible (before
> anything else happens in the execution, such as connecting the nodes)
> so that we can mark blocked test cases in case of an error. Test case
> discovery is definitely part of each execution and putting node init
> after that was a natural consequence. There's an argument for
> discovering test cases of all executions before actually running any
> of the executions. It's certainly doable, but the code doesn't look
> that good (when not modifying the original execution config (which we
> shouldn't do) - I've tried) and there's actually not much of a point
> to do it this way, the result is almost the same. Where it makes a
> difference is when there's an error in test suite configuration and
> later executions - the user would have to wait for the previous
> execution to fully run to discover the error).
>

These are very good points. I was still thinking of these
initializations as part of the pre-execution but I agree with you that
the things we are doing are actually part of the execution. Thank you
for elaborating!

> >
> >
<snip>