Fix autologging silent mode bugs

[dbczumar]

Signed-off-by: dbczumar corey.zumar@databricks.com

What changes are proposed in this pull request?

MLflow 1.15 introduced the following bugs:

• The silent=True/False option introduced to autologging in MLflow 1.15 does not respect disable=True. As a result, when autologging is disabled via mlflow.autolog(disable=True, silent=True), warnings from ML frameworks are suppressed.

• Similarly, warning rerouting intended for the autologging preamble / postamble also does not respect disable=True. As a result, when autologging is disabled via mlflow.autolog(disable=True, silent=False), warnings from ML frameworks are rerouted to the MLflow event logger.

This PR fixes these issues & adds test coverage ensuring that they do not recur.

How is this patch tested?

• Included unit test coverage

Release Notes

Fix errors causing autologging silent mode to be enforced even when autologging is disabled by the user.

Is this a user-facing change?

• No. You can skip the rest of this section.
• Yes. Give a description of this change to be included in the release notes for MLflow users.

What component(s), interfaces, languages, and integrations does this PR affect?

Components

• area/artifacts: Artifact stores and artifact logging
• area/build: Build and test infrastructure for MLflow
• area/docs: MLflow documentation pages
• area/examples: Example code
• area/model-registry: Model Registry service, APIs, and the fluent client calls for Model Registry
• area/models: MLmodel format, model serialization/deserialization, flavors
• area/projects: MLproject format, project running backends
• area/scoring: Local serving, model deployment tools, spark UDFs
• area/server-infra: MLflow server, JavaScript dev server
• area/tracking: Tracking Service, tracking client APIs, autologging

Interface

• area/uiux: Front-end, user experience, JavaScript, plotting
• area/docker: Docker use across MLflow's components, such as MLflow Projects and MLflow Models
• area/sqlalchemy: Use of SQLAlchemy in the Tracking Service or Model Registry
• area/windows: Windows support

Language

• language/r: R APIs and clients
• language/java: Java APIs and clients
• language/new: Proposals for new client languages

Integrations

• integrations/azure: Azure and Azure ML integrations
• integrations/sagemaker: SageMaker integrations
• integrations/databricks: Databricks integrations

How should the PR be classified in the release notes? Choose one:

• rn/breaking-change - The PR will be mentioned in the "Breaking Changes" section
• rn/none - No description will be included. The PR will be mentioned only by the PR number in the "Small Bugfixes and Documentation Updates" section
• rn/feature - A new user-facing feature worth mentioning in the release notes
• rn/bug-fix - A user-facing bug fix worth mentioning in the release notes
• rn/documentation - A user-facing documentation change worth mentioning in the release notes

[dbczumar]

Another option would be to move the context manager entry statements from above down below this logic. However, that leaves a small risk of us leaking logger / warning statements from this section of the code.

[jinzhang21]

LGTM.