Fix Optuna Validation for CMA-ES

[andreyvelich]

Since Optuna recently moved cmaes to optional dependencies, our CI is failing: optuna/optuna#4901.
I bumped Optuna to 3.3.0 version to unblock it, we can keep specific version of Optuna for now to avoid such errors.
If we need to relax the version, we can discuss the long-term plan on how to identify such errors in advance.

Also, I noticed that we have incorrect validation for cmaes in Optuna service.
We need to check that Search Space has more than 2 dimensional continues parameters instead of checking Algorithm Settings, similar to Goptuna: https://github.com/kubeflow/katib/blob/master/pkg/suggestion/v1beta1/goptuna/service.go#L188-L196

/assign @tenzen-y @johnugeorge @c-bata @shipengcheng1230

[google-oss-prow]

@andreyvelich: GitHub didn't allow me to assign the following users: shipengcheng1230.

Note that only kubeflow members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

Since Optuna recently moved cmaes to optional dependencies, our CI is failing: optuna/optuna#4901.
I bumped Optuna to 3.3.0 version to unblock it, we can keep specific version of Optuna for now to avoid such errors.
If we need to relax the version, we can discuss the long-term plan on how to identify such errors in advance.

Also, I noticed that we have incorrect validation for cmaes in Optuna service.
We need to check that Search Space has more than 2 dimensional continues parameters instead of checking Algorithm Settings, similar to Goptuna: https://github.com/kubeflow/katib/blob/master/pkg/suggestion/v1beta1/goptuna/service.go#L188-L196

/assign @tenzen-y @johnugeorge @c-bata @shipengcheng1230

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [andreyvelich]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tenzen-y]

Thank you! Can we do cherry-pick this commit into the latest release branch?

/lgtm

[andreyvelich]

Thank you! Can we do cherry-pick this commit into the latest release branch?

/lgtm

Actually, I am not sure if we need to do another Release to fix this. multivariate-tpe is still working for Optuna service, and we use Goptuna for cmaes by default: https://github.com/kubeflow/katib/blob/master/manifests/v1beta1/installs/katib-standalone/katib-config.yaml#L39
So, the issue will present only for users who want to use cmaes from Optuna suggestion.

WDYT @tenzen-y ?

[tenzen-y]

Thank you! Can we do cherry-pick this commit into the latest release branch?
/lgtm

Actually, I am not sure if we need to do another Release to fix this. multivariate-tpe is still working for Optuna service, and we use Goptuna for cmaes by default: https://github.com/kubeflow/katib/blob/master/manifests/v1beta1/installs/katib-standalone/katib-config.yaml#L39 So, the issue will present only for users who want to use cmaes from Optuna suggestion.

WDYT @tenzen-y ?

I don't think it is valuable to cut a new patch release v0.16.1. However, I think we should make Dockerfiles buildable and the image should work fine on the latest release branch (release-0.16).

@andreyvelich WDYT?

[tenzen-y]

/lgtm

[andreyvelich]

Great, tests were succeeded.

[andreyvelich]

I don't think it is valuable to cut a new patch release v0.16.1. However, I think we should make Dockerfiles buildable and the image should work fine on the latest release branch (release-0.16).

@tenzen-y But how user can find out about this fix if we are not going to update the Changelog and cut the new release ?

[tenzen-y]

I don't think it is valuable to cut a new patch release v0.16.1. However, I think we should make Dockerfiles buildable and the image should work fine on the latest release branch (release-0.16).

@tenzen-y But how user can find out about this fix if we are not going to update the Changelog and cut the new release ?

@andreyvelich My suggestions aim to keep the latest branch runnable without the costs of a new patch release.
Even if without cherry-pick, v0.16.0 would work fine as you said.

So, I wanted to just say that we should keep the latest release branch proper regardless of whether we cut a new patch release.