Support experiments with generate_name feature

[fensterwetter]

/kind feature

Describe the solution you'd like
The Python katib client (again) supports experiments with the generate_name feature.

Anything else you would like to add:
After upgrading from kubeflow-katib 0.14.0 to 0.16.0, I noticed that the create_experiment function in katib_client.py now implicitly makes the assumption that the experiment object contains an attribute called .metadata.name. However, generally name can be missing in favour of generate_name which is then treated as a prefix which gets an additional suffix from the server. In version 0.14.0, the server return was used to access the resulting final name. At least from kubeflow-katib version 0.15.0 onwards, the server return is no longer captured and the original experiment object is used to access the name attribute.

I was wondering if the change was a conscious decision or rather a side effect that could be reverted. I am also happy to collaborate in case this is something that makes sense for katib to support.

Thanks
Thomas

---

Love this feature? Give it a 👍 We prioritize the features with the most 👍

[tenzen-y]

That makes sense. We should get the generated name if the name is empty here:

katib/sdk/python/v1beta1/kubeflow/katib/api/katib_client.py

Lines 104 to 114 in fc6beec

	except multiprocessing.TimeoutError:
	raise TimeoutError(
	f"Timeout to create Katib Experiment: {namespace}/{experiment.metadata.name}"
	)
	except Exception:
	raise RuntimeError(
	f"Failed to create Katib Experiment: {namespace}/{experiment.metadata.name}"
	)
	# TODO (andreyvelich): Use proper logger.
	print(f"Experiment {namespace}/{experiment.metadata.name} has been created")

cc: @andreyvelich

[bharathk005]

@tenzen-y I can work on this if this feature is still needed.

[tenzen-y]

@tenzen-y I can work on this if this feature is still needed.

Yes, I believe that this is still needed. Feel free to open the PR.

[bharathk005]

@tenzen-y
Do we need to handle this scenario in the backend as well?

katib/pkg/ui/v1beta1/backend.go

Line 130 in fc6beec

err = k.katibClient.CreateRuntimeObject(&job)

[tenzen-y]

@tenzen-y Do we need to handle this scenario in the backend as well?

katib/pkg/ui/v1beta1/backend.go

Line 130 in fc6beec

err = k.katibClient.CreateRuntimeObject(&job)

@bharathk005 That backend is only for Katib UI. So, we can improve only SDK.

[tenzen-y]

@bharathk005 Could you say /assign if you are already working on this?

[bharathk005]

/assign

[andreyvelich]

This should be fixed with: #2272