Ververica Platform 2.4.3¶

Release Date: 2021-08-18

Changelog¶

Apache Flink®¶

This release adds support for Apache Flink® 1.11.4 and Apache Flink® 1.12.5.

Apache Flink® 1.11.4¶

Please check out the Flink 1.11.4 release announcement for details about this Apache Flink® release.

For Stream Edition the following Apache Flink® Docker images are available:
- 1.11.4-stream1-scala_2.11
- 1.11.4-stream1-scala_2.12
For Spring Edition the following archives are available:
- flink-1.11.4-spring1-scala_2.11.tgz
- flink-1.11.4-spring1-scala_2.12.tgz

Please check Ververica Platform Docker Images for all available Apache Flink® images and additional tags.

Bug Fixes¶

In case of an unstable network connection, the call for persisting the checkpoint metadata into the ConfigMap might fail with the data being actually persisted. This leads to an inconsistent state where the checkpoint data is deleted but the metadata is still stored in the ConfigMap. This fix handles errors that might be related to network outages more conservatively, i.e. the checkpoint data is not deleted anymore. The user needs to take care of cleanup in such cases (see related FLINK-22494).

Apache Flink® 1.12.5¶

Please check out the Flink 1.12.5 release announcement for details about this Apache Flink® release.

For Stream Edition the following Apache Flink® Docker images are available:
- 1.12.5-stream1-scala_2.11
- 1.12.5-stream1-scala_2.12
For Spring Edition the following archives are available:
- flink-1.12.5-spring1-scala_2.11.tgz
- flink-1.12.5-spring1-scala_2.12.tgz

Please check Ververica Platform Docker Images for all available Apache Flink® images and additional tags.

Improvements¶

Updated AWS dependencies to support IAM Roles for Service Accounts (IRSA) on EKS clusters.

Improvements¶

Rest API¶

The event service stores events which are generated by the Ververica Platform during its operation. For long running deployments it can make sense to limit the number of stored events. By default, the Ververica Platform stores an unlimited amount of events.

To control the cleanup of the event log, you can set the maximum number of stored events via maxNumberEvents. Additionally, you can configure the periodic cleanup interval via eventsCleanupInterval.
```
vvp:
  event-service:
    maxNumberEvents: 1000
    eventsCleanupInterval: 15m
```

Bug Fixes¶

The following bugs have been fixed in non-Flink components.

Deployment¶

The deployment API now immediately fails jar deployments on a session cluster if the additionalDependencies field was used without attempting to deploy it.
Forking a deployment via the Ververica Platform UI now causes a random suffix to be added to the name of the newly created deployment. This fix prevents name conflicts when the same deployment is forked multiple times.
In rare cases (i.e., during shutdown/failover) it was possible that a previously running job was not found anymore within the registered jobs when querying the Apache Flink® REST endpoint. Ververica Platform treated this error as fatal and tried to resubmit the job leading to duplicated submission after a potential failover.
Fixed placeholders in the Apache Flink® configuration setting high-availability.storageDir not working.

Rest API¶

When you create a Deployment via POST /deployment, or upsert a non-existent Deployment via PUT /deployments/{deploymentName} or PUT /deployments/{deploymentId}, the fields from the request are merged with the server-side defaults. This could lead to conflicts between deploymentTargetName, deploymentTargetId and sessionClusterName, which are mutually exclusive: if the request specified one of them and the defaults another one, both would be set in the final resource, which is invalid. Now, this does not happen anymore: the field specified in the request has precedence and conflicting fields are unset automatically.
When you update a Deployment via PATCH /deployments/{deploymentId} or PATCH /deployments/{deploymentName} the resource in the request is merged with the existing resource. This could lead to conflicts between deploymentTargetName, deploymentTargetId and sessionClusterName, which are mutually exclusive: if the request specified one of them and the existing resource another one, both would be set in the updated resource, which is invalid. Now, this does not happen anymore: the field in the PATCH request has precedence and conflicting fields are unset automatically.
When you create a Deployment via PUT /deployments/{deploymentName} with invalid metadata.name and no metadata.displayName, the request will no longer fail with message route name and resource name must be equal. The provided invalid name will be copied to metadata.displayName and will be replaced by a valid name.

Upgrade¶

We recommend upgrading via Helm using the following commands:

$ helm repo add ververica https://charts.ververica.com
$ helm upgrade [RELEASE] ververica/ververica-platform --version 5.0.3 --values custom-values.yaml