Ververica Platform 2.4.3

Release Date: 2021-08-18

Changelog

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