-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Kogito Dev Services raise exception with podman 4.4.2 #31652
Comments
/cc @evacchi (kogito), @geoand (devservices,openshift), @iocanel (openshift), @mariofusco (kogito), @stuartwdouglas (devservices) |
Is it a problem only for the Kogito Dev Services or something more generic with Dev Services? You don't have anything else in the log about why the container didn't start? Either in Quarkus or in Podman? |
At the moment, I've spotted this behavior only for Kogito dev services, whereas Kafka and Postgres works pretty well.
Can you provide instructions to gather more information? E.g. Increasing the log level on quarkus side and or on podman side? Thank you |
As the stacktrace shows a problem at "org.testcontainers.shaded.com.trilead.ssh2.*", could it be that you are using the |
@TheHaf correct, exposeHostPorts is used as the container needs to send requests to the running Quarkus application. See https://github.com/kiegroup/kogito-runtimes/blob/main/quarkus/extensions/kogito-quarkus-workflow-extension-common/kogito-quarkus-workflow-common-deployment/src/main/java/org/kie/kogito/quarkus/workflow/deployment/AbstractDevServicesProcessor.java#L90 |
potentially related and fixed by testcontainers/testcontainers-java#2088 and testcontainers/testcontainers-java#5482 |
The second issue provides a hint regarding the used SSH client lib (testcontainers/testcontainers-java#5482 (comment)). I did a bit more digging myself and I suspect that the SSH2 library that Testcontainers shades and uses internally (com.trilead ssh2) causes the issue ultimately. That library has not been updated for the past six years apparently. The Jenkins CI project also makes use of the library, but they have their own fork that they maintain. My guess is that the outdated SSH2 library is incompatible in some way to the current podman version. I haven't had the time yet to investigate further unfortunately. Ultimately if my guess is correct, the way forward would probably be to replace the outdated ssh library in Testcontainers. One alternative that I saw being mentioned somewhere is apparently being maintaned by the Apache folks. |
I took another look into this problem today. Turns out, this has nothing to do with the SSH implementation in testcontainers. First i tried to manually run the sshd container with podman and with debugging enabled. I encountered a suspisious log message After some more research, this brought me to this blog post, explaining that, among others, the capability SYS_CHROOT has been dropped as a default in podman release 4.4.0. According to the release notes for version 4.4.3, this capability has been added back to the defaults already. So updating to that version of podman or a newer one should make things work again. I do not have the option to update podman manually on my workstation and am stuck with a version that doesn't contain the necessary default until the distribution maintainers update their repository. The question is, what are the options in such a case?
There might be other solutions, like using a patched version of testcontainers-core that adds the capability manually (using Hope that helps. Note: Apparently it should also be possible to add the capability when building a container using podman build, but for some reason that didn't change a thing for me. Maybe that functionality is currently broken. |
Hi @TheHaf thank you very much for the detailed investigation. |
Sorry for not reacting sooner @dmarrazzo. Well, the podman version 4.5.0 release notes also state that this capability has been re-added, so I would assume that they are going to keep it at least for the forseeable future. I don't know what the best way to contact the podman maintainers directly would be, but there is an overview of official community channels on the project website: https://podman.io/community You should be able to reach them through one of the listed channels. Hope that helps. |
thank you @TheHaf |
Describe the bug
OpenShift Serverless Logic has it's own dev services:
Quarkus project: https://github.com/dmarrazzo/order-swf
Full tutorial: https://redhat-scholars.github.io/serverless-workflow
Starting quarkus in dev mode trigger the kogito dev services:
podman 4.3.1
podman 4.4.2
Expected behavior
dev services should be started without issues.
Actual behavior
Exceptions are thrown, e.g.:
How to Reproduce?
Output of
uname -a
orver
Linux mas-p1 6.1.14-200.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Feb 26 00:13:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Output of
java -version
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment (Red_Hat-11.0.18.0.10-1.fc37) (build 11.0.18+10)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.18.0.10-1.fc37) (build 11.0.18+10, mixed mode, sharing)
GraalVM version (if different from Java)
No response
Quarkus version or git rev
2.7.6.Final-redhat-00011
Build tool (ie. output of
mvnw --version
orgradlew --version
)Maven home: /usr/share/maven
Java version: 17.0.6, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-17-openjdk-17.0.6.0.10-1.fc37.x86_64
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.1.14-200.fc37.x86_64", arch: "amd64", family: "unix"
Additional information
No response
The text was updated successfully, but these errors were encountered: