Upgrading to 1.4.0¶

Seldon Core¶

Seldon Deploy 1.4.0 recommends Seldon Core in version 1.11.x. Upgrade should be straightforward following the related documentation for Seldon Core v1 page.
It is possible that model artifacts trained to work with pre-packaged model servers will require update. Model explainers and outlier detectors may be the components most likely at risk here. Reasons for retraining are often related to the Python version change or library upgrades in the related server. Following workarounds are available:
- Delay Seldon Core upgrade until you confirm in development environment that all your model work as expected and retrain them as required
- Modify Helm values (core-values.yaml) to specify previous version of the related server, for example:
```
predictor_servers:
  SKLEARN_SERVER:
      seldon:
        defaultImageVersion: 1.11.2
        image: seldonio/sklearnserver
```
In Seldon Core 1.11.2 the default version of Triton server is 21.08-py3. This uses GZIP compression by default, which causes the payloads to not be logged due to the relevant headers not being propagated. This has been fixed in Seldon Core 1.13.

Authorization/Policy Management¶

Seldon Deploy 1.4.0 introduces a new API for managing OPA based policies. These new endpoints will be enabled by default if OPA authorization is enabled. If you do not want to manage your OPA policies via API you can disable them as described in the configuration guide. See the API documentation for instruction on how to use the new API endpoints.

Alerting Integration¶

In version 1.4.0 we introduce an alerting system. Metrics exposed on Deploy and Models can be used to alert when SLOs are breached. These alerts are configured to be sent to the frontend of Deploy, and can also be configured for external providers like Opsgenie and Pagerduty.
The default installation provides the ConfigMaps and setup required for this to work out of the box, but changes to Prometheus and Alertmanager configuration will be required if not using the default installation. The production installation guide covers the setup required and also documents how to configure external notifications and custom alerts.
See the alerting integration demo to test the alerting flow.

Detector Configuration and Metrics¶

Seldon Deploy 1.4.0 updates the single-detector APIs for deployments to a multi-detector APIs using the SDK. This enables creation of multiple detectors i.e. drift detectors, outlier detectors and metrics servers. This is compatible with the current detector gitops structure and configuration so existing detectors work as-is but the detector APIs have been modified. See new swagger spec for changes.
The new APIs introduced also require a label for detector kservices in the non-gitops namespaces to appear on the UI. No change is needed for gitops enabled namespaces. Functionality of existing detectors remain intact.
To add the required labels, in a non-gitops namespace, this can be done individually to all existing detectors using the following command. Once this label is added, there is no change to the existing user journey in Seldon deploy UI to allow provisioning of per deployment detectors. For KServe Inference services, change SeldonDeployment to InferenceService in the following script.

kservice_name=${namespace}-seldondeployment-${deployment_name}-${detector_type}
kubectl label kservice -n ${namespace} ${kservice_name} seldon.io/deployment-name=${deployment_name}
kubectl label kservice -n ${namespace} ${kservice_name} seldon.io/deployment-kind=SeldonDeployment