You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given there could be further changes in the above function, the actual service name would become unpredictable. Especially, in some situations, one needs to know the service's name in order to be able to know where exactly to curl the prediction service even before the service is deployed.
@cliveseldon suggests to add a feature so that the prediction service's service name can be overridden by the user, and then it is the user's responsibility to make sure the services don't clash.
The text was updated successfully, but these errors were encountered:
Currently, the seldon service's name is comprised of several components according to the manifest, see https://github.com/SeldonIO/seldon-operator/blob/89e3b5ee3d78bf7e1dacfffbfcaff2ba873b7d6a/pkg/apis/machinelearning/v1alpha2/seldondeployment_types.go#L117, and the name will be hashed first if the length exceeds 63. The reason for combining the serval components, as @cliveseldon explained, is to make sure there is no clash of service names for complex graphs.
Given there could be further changes in the above function, the actual service name would become unpredictable. Especially, in some situations, one needs to know the service's name in order to be able to know where exactly to curl the prediction service even before the service is deployed.
@cliveseldon suggests to add a feature so that the prediction service's service name can be overridden by the user, and then it is the user's responsibility to make sure the services don't clash.
The text was updated successfully, but these errors were encountered: