-
Notifications
You must be signed in to change notification settings - Fork 1k
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
support running Fabric8IstioIT with colima #1602
Comments
From what I remember, this test gave me a lot of headache too a few years back when we were moving to test containers. Let's try to go each at a time, cause there are more then one questions here.
The test failure for you locally: this is what bothers me the most, cause it works for me just fine. Let me give you my steps, which are as easy as it can get.
then build the image for Mac M cpus (I'm on Mac M1):
and I am simply running the test from intellij. P.S. That error The process here is among these lines: create the image locally; archive it via Because this test passes for me, it has to do with colima, I assume. |
good point that k3s isn't as far behind as the others. nevermind that. my machine is in process doing the dashaun thing, and hopefully we can stop this problem forever via #1603 I keep forgetting this, but it really isn't something people should have to memorize. will report back if things progress now. |
ps if only java 17 is supported, I would suggest adding maven-enforcer-plugin config, for a similar reason as adding a maven profile to fix the image. Basically, people shouldn't have to remember a lot of special rules. If we decide things don't work past 17, we ought to prevent it by default. Power users can always use a property to skip enforcer. |
ok so downgrading to JRE 17 and also rebuilding with dashaun, same error
My guess indeed is this about colima as it is running in a VM, and the test may be assuming the image it is pulling outside docker is actually on the same host. It is may be possible to redo this so that it can pull the image from k3s node to avoid this problem. I won't run docker desktop as it is a licensed product and also colima is generally useful for other things. I'll just rename this to an enhancement request. |
If I find some time, I'll take a closer look at this one, but for me, personally, it's not going to be a priority (sorry about that). Mainly because this is how it runs on the pipeline, both here in github actions and on jenkins on the spring team... Still, it was an interesting thing to look at this one again, after so much time. |
fyi here's how I use colima $ colima start --cpu 4 --memory 8 --network-address Most of the time I also add |
The problem here is that the current code assumes the host running the testcontainers code is the same as the docker host. This is not true in colima (nor would be for a cloud host). Here's a working version of image copying, but I ran into other problems so the whole IT isn't working, yet. /**
* Temporary folder where to load images.
*/
public static final Path HOST_IMAGE_PATH = Path.of(System.getProperty("java.io.tmpdir"));
/**
* Container path corresponding to {@link #HOST_IMAGE_PATH}.
*/
public static final Path CONTAINER_IMAGE_PATH = Path.of("/images");
private static final K3sContainer CONTAINER =
new FixedPortsK3sContainer(DockerImageName.parse(Commons.RANCHER))
.configureFixedPorts(EXPOSED_PORTS)
// here don't assume the path is the same, this helps keep things more sane later
.withFileSystemBind(HOST_IMAGE_PATH.toFile().getAbsolutePath(),
CONTAINER_IMAGE_PATH.toString(), BindMode.READ_WRITE)
.withCommand(Commons.RANCHER_COMMAND);
--snip--
// different version of loadImage that doesn't assume the JVM's host is the same as the docker host
public static void loadImage(String image, String tag, K3sContainer k3s)
throws Exception {
DockerClient client = k3s.getDockerClient();
image = image + ":" + tag;
String id = client.inspectImageCmd(image)
.exec()
.getId()
.replace("sha256:", "");
Path hostPath = HOST_IMAGE_PATH.resolve(id);
if (!hostPath.toFile().exists()) {
LOG.info("saving image " + image + " to " + hostPath);
try (SaveImageCmd saveCmd = client.saveImageCmd(image);
InputStream in = saveCmd.exec();
OutputStream out = Files.newOutputStream(hostPath)) {
in.transferTo(out);
} catch (Exception ex) {
hostPath.toFile().delete();
throw ex;
}
}
Path containerPath = CONTAINER_IMAGE_PATH.resolve(id);
LOG.info("copying " + hostPath + " to " + containerPath);
k3s.copyFileToContainer(MountableFile.forHostPath(hostPath), containerPath.toString());
LOG.info("importing image " + image + " from " + containerPath);
Container.ExecResult exec =
k3s.execInContainer("ctr", "images", "import", containerPath.toString());
if (exec.getExitCode() != 0) {
throw new RuntimeException("Failed to load image " + image + ": " + exec);
}
}
|
Describe the bug
I can see that
Fabric8IstioIT
runs in the workflow, but I'm having trouble executing it locally. First, I have to disable ryuk, then it still doesn't work on account of some resources. Are there some instructions I may be missing? I run install first. Note: I am running an M2 macbook (aarch64) and using colima.Sample
ryuk enabled (default)
ryuk disabled
cc @wind57 as seems you have been able to get this working. ps I have already tried upgrading the docker and testcontainers drivers. PS the istio, k3s, alpine, etc versions in this test are very out of date.
The text was updated successfully, but these errors were encountered: