Upgrading to 1.3.0

• Seldon Core v1.8.0 changed the default storage initializer to be seldonio/rclone-storage-initializer. The secret format that holds credentials have changed and requires update.

  • If you do not wish to update them now, please, set following value in core-values.yaml used when installing Seldon Core with Helm

  storageInitializer:
    image: gcr.io/kfserving/storage-initializer:v0.4.0
  

  This is documented in kfserving storage initializer documentation.

  • Following resources are available to help you upgrade to the rclone-compatible secret format:

    • Seldon Core 1.8 upgrading documentation

    • Handling Credentials documentation for pre-packaged model servers with rclone-based storage initializer

    • Tutorial on how to test new secret format without setting rclone-based storage initializer globally

    • An example upgrade path that illustrates steps required to smoothly upgrade AWS S3 / MinIO configured clusters from kfserving-based Secret and Service Account credentials to the new format.

• SD 1.3.0 introduces improvement to the Batch Processing of requests - generated Argo workflows now use storage initializer mechanism for pulling in input file and uploading output file. The default storage initializer is seldonio/rclone-storage-initializer which requires adjustment of credential secret.

  • If you do want to keep using current format of secret without updating it now, set following value in deploy-values.yaml used when installing Seldon Deploy with Helm

  batchjobs:
    storageInitializer:
      image: gcr.io/kfserving/storage-initializer:v0.4.0
  

  • To upgrade to the new format see links provided in the previous point. Also consult our documentation that contains example for MinIO-compatible secret.

• SD 1.3.0 updates the request logger component’s image in the Helm chart default values file to seldonio/seldon-request-logger:1.9.1. This version of request logger looks up model level metadata from Seldon Deploy metadata service before creating predictions logging Elasticsearch indexes. This feature is leveraged by new advanced monitoring features like distributions monitoring introduced in this Deploy version. It is not a mandatory configuration and it is possible disable the metadata lookup from the request logger. New features like distributions monitoring will still work, you just won’t be able to enrich logged predictions with the model level predictions schema (e.g. feature category names).

  • As mentioned earlier, metadata lookup is not mandatory for the request logger. If you wish to disable this feature and would prefer the request logger to create the Elasticsearch indexes without the model level metadata as in previous releases, follow the steps below.

    • If you have already enabled model level metadata feature from version v1.2.0 and want to continue using this feature without the request logger connection to Seldon Deploy, then use the default Helm chart values in the request logger section

    • Alternatively, if you have disabled model level metadata feature by setting the metadata.pg.enabled to false also disables the request logger connection to Seldon Deploy as the model level metadata is not being stored.

  • To enable this metadata lookup feature, the request logger requires authentication configuration to connect with a Seldon Deploy instance. For configuring this feature, see the request logger page for details of the authentication setup needed to connect to Seldon Deploy. If you are using model metadata then adding auth from the request logger to Deploy enables the prediction schema for a model to be found and used to enrich prediction data and enrich monitoring. This will be enabled for all new Elasticsearch logging indexes once setup. Existing indexes will work as before but will need to be reindexed to store additional enriched info. Enabling auth from request logger to Deploy currently requires a client credentials auth flow but can also be configured to work with the password grant flow if needed.