[RAPTOR-14627] use gunicorn in sklearn env

[yakov-g]

This repository is public. Do not put here any private DataRobot or customer's data: code, datasets, model artifacts, .etc.

Summary

Rationale

---

Note

Standardizes Gunicorn as the DRUM server across drop-in environments, bumps datarobot-drum to 1.17.10, updates env version IDs/tags, and adjusts tests accordingly.

• Runtime/Environments:
  • Set MLOPS_RUNTIME_PARAM_DRUM_SERVER_TYPE to "gunicorn" in Dockerfiles for java_codegen, python311, python3_keras, python3_onnx, python3_pytorch, python3_sklearn, python3_xgboost, and r_lang.
  • Update env_info.json environmentVersionId and corresponding tags for all affected environments.
• Dependencies:
  • Bump datarobot-drum to 1.17.10 across requirements (including python311_genai_agents); regenerate requirements.txt for Python 3.11 with updated pip-compile metadata and include gunicorn where applicable.
• Tests:
  • Adjust tests/functional/test_drum_server_failures.py parametrization to avoid with_error_server/production for DOCKER_PYTHON_SKLEARN and add notes reflecting Gunicorn usage.

^{Written by Cursor Bugbot for commit 5383bbf. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Commented-out configuration left in Dockerfile

A commented-out ENV MLOPS_RUNTIME_PARAM_DRUM_CLIENT_REQUEST_TIMEOUT line was added to the Dockerfile. This appears to be leftover testing or debugging code that was not removed before committing. Commented-out configuration in production Dockerfiles can confuse maintainers and suggests incomplete cleanup.

 

[cursor]

Bug: Removed ADDRESS default causes KeyError without fallback

The change from os.environ.get("ADDRESS", "0.0.0.0:8080") to os.environ["ADDRESS"] removes the fallback default. While the Dockerfiles set ENV ADDRESS=0.0.0.0:8080, running gunicorn outside of Docker without the --address CLI option and without the ADDRESS environment variable being set will cause a KeyError. The setup_options() function only sets ADDRESS if options.address is truthy, providing no guarantee the variable exists.

 

[cursor]

Bug: setup_options called twice in non-gunicorn execution path

The run_drum_server() function calls setup_options() to determine if gunicorn should be used. When the condition is false (non-gunicorn path), it calls main(), which internally calls setup_options() again. This causes argument parsing, environment variable setup via RuntimeParametersLoader, lazy loading setup, and option verification to all run twice. The argcomplete missing warning would also print twice if the package is not installed. The previous implementation checked sys.argv[1] == "server" directly without requiring a full parse, avoiding this redundancy.

custom_model_runner/datarobot_drum/drum/entry_point.py#L9-L18

datarobot-user-models/custom_model_runner/datarobot_drum/drum/entry_point.py

Lines 9 to 18 in 90b7ce7

	def run_drum_server():
	options = setup_options()
	if (
	options.subparser_name == ArgumentsOptions.SERVER
	and RuntimeParameters.has("DRUM_SERVER_TYPE")
	and str(RuntimeParameters.get("DRUM_SERVER_TYPE")).lower() == "gunicorn"
	):
	main_gunicorn()
	else:
	main()

 

---

[cursor]

Bug: Inconsistent test parameter updates for gunicorn compatibility

The PR updates test parameters for test_e2e_no_model_artifact and test_e2e_model_loading_fails from (True, True, DOCKER_PYTHON_SKLEARN) to (False, False, DOCKER_PYTHON_SKLEARN) with comments explaining that gunicorn doesn't support error server or production mode. However, test_ping_endpoints (line 108) and test_e2e_predict_fails (line 188) still use (True, True, DOCKER_PYTHON_SKLEARN). If gunicorn truly doesn't support these modes, these tests will fail when run against the updated sklearn docker image.

Additional Locations (2)

• tests/functional/test_drum_server_failures.py#L107-L108
• tests/functional/test_drum_server_failures.py#L187-L188