Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cli-Client writes unwanted error messages inside read-only docker image #3665

Closed
sseide opened this issue May 2, 2023 · 3 comments
Closed

Comments

@sseide
Copy link

sseide commented May 2, 2023

Which version and edition of Flyway are you using?

9.17.0 community

If this is not the latest version, can you reproduce the issue with the latest one as well? (Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)

command-line

Which database are you using? (Type & version)

Mariadb

Which operating system are you using?

Alpine Linux 3.17 with Java11 inside docker image

What did you do? (Please include the content causing the issue, any relevant configuration settings, the SQL statement(s) that failed (if any), and the command you ran)

I used the cli client to do check a database for migrations needed.
The cli client runs inside a docker image in kubernetes. The kubernetes pod is defined as having a read-only file system.
Now the cli client starts and prints some error messages not being able to write reports to disc.
The migrations done n-the-less because latest version catch these errors and do not exit the entire app anymore.
But having this useless/unwanted/expected error messages is cluttering the logs and raises monitoring alarms not needed.

What did you expect to see?

There should be no ERROR messages on cli startup. The reports (JSON + HTML) should not be written by default as with all versions before 9.16.
If it is not possible to change the default behavior there should be at least a env variable and/or configuration parameter to disable writing reports to disc.

What did you see instead?

The docker logs show ERROR messages not being really errors in this case as reports are not needed / wanted.

Flyway Community Edition 9.17.0 by Redgate
Database: jdbc:mariadb://....:3306/dashboard (MySQL 10.4)
Successfully validated 9 migrations (execution time 00:00.075s)
Current version of schema `dashboard`: 009
Schema `dashboard` is up to date. No migration necessary.
ERROR: Unable to create JSON report
org.flywaydb.core.api.FlywayException: Unable to write JSON to file: report.json (Permission denied)
at org.flywaydb.core.internal.util.JsonUtils.jsonToFile(JsonUtils.java:46)
at org.flywaydb.commandline.utils.OperationsReportUtils.createJsonReport(OperationsReportUtils.java:58)
at org.flywaydb.commandline.Main.main(Main.java:178)
ERROR: Unable to create HTML report
org.flywaydb.core.api.FlywayException: Unable to write HTML to file: report.html (Permission denied)
at org.flywaydb.core.internal.util.HtmlUtils.toHtmlFile(HtmlUtils.java:36)
at org.flywaydb.commandline.utils.OperationsReportUtils.createHtmlReport(OperationsReportUtils.java:49)
at org.flywaydb.commandline.Main.main(Main.java:179)

Thanks in advance,
Stefan Seide

--

@Barry-RG
Copy link
Contributor

Barry-RG commented May 2, 2023

Thank you for your feedback. We are currently looking into better ways of managing this type of issue.

@Barry-RG Barry-RG closed this as completed May 2, 2023
@Barry-RG Barry-RG reopened this May 2, 2023
@sseide
Copy link
Author

sseide commented May 2, 2023

In this case its our own build but it does not matter - same happens with image from https://hub.docker.com/r/flyway/flyway

This problem happens in two different ways:

  1. Due to applying a restricted security context in kubernetes, e.g (shortened descriptor).
kind: Deployment
spec:
  template:
    spec:
      containers:
        - name: flyway
          ...
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true

This was working fine with older versions.

  1. or automatically by using OpenShift to run the image. Openshift assigns a random user at image runtime that does not have write access to the flyway directories

@dginzbourg
Copy link

We got this error as well, though it looks like random. pod failed to start with this error, but then passed it without any exceptions. There were no migrations required on the 1st run when it failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants