Closed dmarrazzo closed 1 year ago
/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. I've noticed that with the latest version of the container and kogito libraries, it has a weird behavior:
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 Testcontainers.exposeHostPorts(...)
method call? I noticed that causes problems using a current podman version, but I haven't found out the reason yet. It seems that method causes Testcontainers to start a SSHD container to expose the given port to the container using reverse port forwarding.
@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 Is there any known workaround?
potentially related and fixed by https://github.com/testcontainers/testcontainers-java/issues/2088 and https://github.com/testcontainers/testcontainers-java/issues/5482
The second issue provides a hint regarding the used SSH client lib (https://github.com/testcontainers/testcontainers-java/issues/5482#issuecomment-1153241155).
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 chroot("/var/empty"): Operation not permitted [preauth]
.
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? Here are some options:
When running a container manually that needs this capability, you can add the option --cap-add SYS_CHROOT
to the podman run command line.
Add the capability to the default_capabilities config in /etc/containers/containers.conf (this is what I did) to have it on all containers:
default_capabilities = [
"CHOWN",
"DAC_OVERRIDE",
"FOWNER",
"FSETID",
"KILL",
"NET_BIND_SERVICE",
"SETFCAP",
"SETGID",
"SETPCAP",
"SETUID",
"SYS_CHROOT",
]
There might be other solutions, like using a patched version of testcontainers-core that adds the capability manually (using withCreateContainerCmdModifier(cmd -> cmd.getHostConfig().withCapAdd(Capability.SYS_CHROOT)))
in the enum PortForwardingContainer.
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. I can confirm that the sanity is restored with podman 4.4.3!!! Let's hope that nobody decide to drop it again at next iteration of podman!!! Do you think there is a way to make podman team aware that we rely on that feature?
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 Closing issue...
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