[
https://issues.apache.org/jira/browse/FLINK-40733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn Visser updated FLINK-40733:
-----------------------------------
Description:
{{TrinoDialectTest}}, {{TrinoDynamicTableSourceITCase}} and
{{TrinoDynamicTableSinkITCase}} all carry {{@Disabled("Not working on jenkins
as container not start.")}}, added with the Trino dialect in FLINK-15462 and
carried over to the separate Trino module in FLINK-35366. Nothing has exercised
{{TrinoDialect}} against a running Trino since. Only
{{TrinoPreparedStatementTest}} runs, and it never opens a connection.
Removing the three annotations was tried on the FLINK-40729 branch. The tests
pass locally but the container does not start on a GitHub Actions runner:
{code}
ContainerLaunchException: Container startup failed for image trinodb/trino:483
Caused by: IllegalStateException: Wait strategy failed. Container exited with
code 100
Caused by: IllegalStateException: Container is started, but cannot be accessed
by
(JDBC URL: jdbc:trino://localhost:32845/postgres/public)
{code}
https://github.com/apache/flink-connector-jdbc/actions/runs/35604935995/job/106349603601
The cause is the catalog file {{TrinoDatabase}} builds:
{{Files.createTempFile}} creates it {{0600}} owned by the build user, and it is
bind mounted to {{/etc/trino/catalog/postgres.properties}}, where the image
reads it as {{uid 1000 (trino)}}. Trino then fails with
{{FileNotFoundException: etc/catalog/postgres.properties (Permission denied)}}
and exits with code 100. Docker Desktop on macOS hides host ownership, which is
why it passes there and fails on Linux. Copying the file into the container
instead of bind mounting it avoids this.
The four method level exclusions in {{TrinoDynamicTableSinkITCase}} can go as
well. Trino cannot create a table with a primary key, but these tests already
create their tables directly in the Postgres database behind Trino and only
write and read through Trino. They need the Postgres driver on the test
classpath and {{dropTable()}} instead of {{deleteTable()}} for cleanup.
was:
{{TrinoDialectTest}}, {{TrinoDynamicTableSourceITCase}} and
{{TrinoDynamicTableSinkITCase}} all carry {{@Disabled("Not working on jenkins
as container not start.")}}, added in FLINK-35366 in May 2024. Nothing has
exercised {{TrinoDialect}} against a running Trino since. Only
{{TrinoPreparedStatementTest}} runs, and it never opens a connection.
Removing the three annotations was tried on the FLINK-40729 branch. The tests
pass locally but the container does not start on a GitHub Actions runner:
{code}
ContainerLaunchException: Container startup failed for image trinodb/trino:483
Caused by: IllegalStateException: Wait strategy failed. Container exited with
code 100
Caused by: IllegalStateException: Container is started, but cannot be accessed
by
(JDBC URL: jdbc:trino://localhost:32845/postgres/public)
{code}
https://github.com/apache/flink-connector-jdbc/actions/runs/35604935995/job/106349603601
Exit code 100 is how Trino reports that it could not load a catalog. A likely
cause is the catalog file {{TrinoDatabase}} builds: {{Files.createTempFile}}
creates it {{0600}} owned by the build user, and it is bind mounted to
{{/etc/trino/catalog/postgres.properties}}, where the image reads it as {{uid
1000 (trino)}}. Docker Desktop on macOS hides host ownership, which is why it
passes there and fails on Linux. Worth trying a {{chmod}} to {{0644}} on that
temp file first, though that is a hypothesis and the container log on the
runner should confirm it before anything is changed.
The two method level exclusions in {{TrinoDynamicTableSinkITCase}} are
unrelated and should stay; Trino cannot create a table with a primary key.
> Trino tests are disabled, so the Trino dialect has no test coverage
> -------------------------------------------------------------------
>
> Key: FLINK-40733
> URL: https://issues.apache.org/jira/browse/FLINK-40733
> Project: Flink
> Issue Type: Technical Debt
> Components: Connectors / JDBC
> Reporter: Martijn Visser
> Assignee: Purushottam Sinha
> Priority: Major
> Labels: pull-request-available
> Fix For: jdbc-5.0.0
>
>
> {{TrinoDialectTest}}, {{TrinoDynamicTableSourceITCase}} and
> {{TrinoDynamicTableSinkITCase}} all carry {{@Disabled("Not working on jenkins
> as container not start.")}}, added with the Trino dialect in FLINK-15462 and
> carried over to the separate Trino module in FLINK-35366. Nothing has
> exercised {{TrinoDialect}} against a running Trino since. Only
> {{TrinoPreparedStatementTest}} runs, and it never opens a connection.
> Removing the three annotations was tried on the FLINK-40729 branch. The tests
> pass locally but the container does not start on a GitHub Actions runner:
> {code}
> ContainerLaunchException: Container startup failed for image trinodb/trino:483
> Caused by: IllegalStateException: Wait strategy failed. Container exited with
> code 100
> Caused by: IllegalStateException: Container is started, but cannot be
> accessed by
> (JDBC URL: jdbc:trino://localhost:32845/postgres/public)
> {code}
> https://github.com/apache/flink-connector-jdbc/actions/runs/35604935995/job/106349603601
> The cause is the catalog file {{TrinoDatabase}} builds:
> {{Files.createTempFile}} creates it {{0600}} owned by the build user, and it
> is bind mounted to {{/etc/trino/catalog/postgres.properties}}, where the
> image reads it as {{uid 1000 (trino)}}. Trino then fails with
> {{FileNotFoundException: etc/catalog/postgres.properties (Permission
> denied)}} and exits with code 100. Docker Desktop on macOS hides host
> ownership, which is why it passes there and fails on Linux. Copying the file
> into the container instead of bind mounting it avoids this.
> The four method level exclusions in {{TrinoDynamicTableSinkITCase}} can go as
> well. Trino cannot create a table with a primary key, but these tests already
> create their tables directly in the Postgres database behind Trino and only
> write and read through Trino. They need the Postgres driver on the test
> classpath and {{dropTable()}} instead of {{deleteTable()}} for cleanup.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
