Upgrading Spring Cloud Data Flow on Kubernetes to v2.11.3 failed to start skipper

Products

• VMware Tanzu Spring Runtime

Issue/Introduction

Customer using Spring Cloud Data Flow on Kubernetes upgraded from v2.11.2 to v2.11.3 refer to https://github.com/spring-cloud/spring-cloud-dataflow with tag v2.11.3 and the installation follows the doc: https://dataflow.spring.io/docs/installation/kubernetes/kubectl/#kubectl-installation-instructions. With running the SCDF server/Skipper server deployment yaml, skipper fails to start because the initContainers disappeared. 

Reviewing skipper log, found below error message  -

2024-07-26 01:24:31.405  INFO 1 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
2024-07-26 01:24:31.813  WARN 1 --- [           main] o.m.jdbc.message.server.ErrorPacket      : Error: 1049-42000: Unknown database 'skipper'
2024-07-26 01:24:32.819 ERROR 1 --- [           main] com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Exception during pool initialization.

java.sql.SQLSyntaxErrorException: (conn=11) Unknown database 'skipper'
        at org.mariadb.jdbc.export.ExceptionFactory.createException(ExceptionFactory.java:289) ~[mariadb-java-client-3.4.1.jar:na]
        at org.mariadb.jdbc.export.ExceptionFactory.create(ExceptionFactory.java:378) ~[mariadb-java-client-3.4.1.jar:na]
        at org.mariadb.jdbc.client.impl.StandardClient.authenticationHandler(StandardClient.java:306) ~[mariadb-java-client-3.4.1.jar:na]
        at org.mariadb.jdbc.client.impl.StandardClient.<init>(StandardClient.java:226) ~[mariadb-java-client-3.4.1.jar:na]
        at org.mariadb.jdbc.Driver.connect(Driver.java:68) ~[mariadb-java-client-3.4.1.jar:na]

Environment

The initContainer for skipper only provides a wait for database being active before launching the skipper pod. In the absence of this the application may restart if MariaDB isn’t active yet.
In an environment where the database is configured separately this is not required.

Cause

Prior to versions v2.11.3, the Skipper server deployment script would create the skipper database via the initContainers script if the database named skipper doesn't exist. With the change to remove the initContainers from skipper server deployment, the skipper database is no longer created and hence the skipper fails to start.

Resolution

This issue will be fixed in the next upcoming release v2.11.5.

As a workaround, the customer can proceed with re-applying the changes which were removed in the commit in description.

https://github.com/spring-cloud/spring-cloud-dataflow/commit/d6fc1df014e84e5f33e660e2bdafcdcb99574255