v0.58.0-rc2

Changes

Automatic Pod-Replacement

This release of the SDK introduces automatic-pod replacement. It is suggested to use an automatic pod-replacement failure policy with external-storage as rebuilding data associated with a pod isn't expected to be as expensive as compared to equivalent ROOT or MOUNT volumes.

Note: When enabled, automatic pod replacement applies across the service and not just a single pod type.

Replacement Failure Policy

Services implementing automatic pod replacement must specify the Replacement Failure Policy for tasks declared as permanently failing. The Replacement Failure Policy is constructed and passed to a Service Spec in a programmatic way as part of the scheduler's implementation.

Cassandra example:

• Constructing Replacement Failure Policy
• Attaching to Service-Spec

Replacement Failure Policy cannot be defined in a YAML service specification.

Default External Volume Name

The release of the SDK makes updates the naming scheme for external volumes, this applies for cases where the operator has not explicitly specified external volume name to use.

The SDK will now use the following scheme for external-volume names where none is specified by the operator:
<svc-name>-<pod-type>-<pod-index>
-<svc-name> : Sanitized service path with slashes / replaced to double underscore __
-<pod-type> : Pod-type
-<pod-index> : Pod-index

As an example, instances of pod type foo in service /path/to/service will be created with the following external volumes:

path__to__service-foo-1
path__to__service-foo-2

If the operator explicitly specifies an external volume name of ServiceVolume, the following external volumes will be created:

ServiceVolume-1
ServiceVolume-2