Optuna suggestion service silently ignores NORMAL and LOG_NORMAL distributions

[saivedant169]

What happened?

The Optuna suggestion service maps only UNIFORM and LOG_UNIFORM distributions for int and double parameters. In pkg/suggestion/v1beta1/optuna/base_service.py, _get_optuna_search_space() has branches for UNIFORM/None and LOG_UNIFORM, but no branch and no error for NORMAL or LOG_NORMAL:

if param.type == INTEGER:
    if param.distribution in [api_pb2.UNIFORM, None]:
        ...
    elif param.distribution == api_pb2.LOG_UNIFORM:
        ...
    # NORMAL / LOG_NORMAL: no branch, param is never added
elif param.type == DOUBLE:
    if param.distribution in [api_pb2.UNIFORM, None]:
        ...
    elif param.distribution == api_pb2.LOG_UNIFORM:
        ...
    # NORMAL / LOG_NORMAL: no branch, param is never added

When a parameter declares distribution: normal or distribution: lognormal, it falls through every branch and is left out of the returned search_space dict. Optuna then never samples that parameter, so the hyperparameter is silently dropped from tuning. No error is raised and no warning is logged, so the experiment runs to completion with results that quietly ignore that parameter.

The Distribution enum in api.proto defines all four (UNIFORM, LOG_UNIFORM, NORMAL, LOG_NORMAL), and the hyperopt suggestion service already handles NORMAL and LOG_NORMAL (pkg/suggestion/v1beta1/hyperopt/base_service.py). So the distributions are valid input that one backend honors and the other silently discards.

What did you expect to happen?

Optuna has no native normal or log-normal distribution (it offers uniform, log-uniform via the log flag, and categorical), so the Optuna backend cannot honor NORMAL/LOG_NORMAL. Given that, it should fail loudly with a clear error naming the parameter and the unsupported distribution, rather than silently dropping the parameter and producing misleading results.

Environment

Katib version (master, pkg/suggestion/v1beta1/optuna/base_service.py)

Impact

A misconfigured experiment (Optuna algorithm + a normal/lognormal parameter) appears to run normally but silently tunes a smaller search space than the user defined. The omission is invisible without reading the suggestion-service internals.

Suggested fix

Add an explicit else in the INTEGER and DOUBLE branches of _get_optuna_search_space() that raises a ValueError naming the parameter and distribution. A follow-up could implement actual NORMAL/LOG_NORMAL support if a faithful Optuna mapping is agreed on.

[github-actions]

🎉 Welcome to the Kubeflow Katib repo! 🎉

Thanks for opening your first issue! We're happy to have you as part of our community 🚀

Next steps:

• Our team will review your issue soon! cc @kubeflow/wg-automl-leads
• Check out the Contributing Guide and the Kubeflow Contributor Guide
• Join the Kubeflow Slack channels: https://www.kubeflow.org/docs/about/community/#kubeflow-slack-channels
• Join the AutoML & Training WG meetings: https://bit.ly/2PWVCkV

Feel free to ask questions in the comments. Thanks again for contributing! 🙏