Keycloak container is started twice and fails the second time

[wmeints]

I am running into an issue where the Quarks dev mode starts the keycloak container a second time while the first one is still running. This happens when I resume testing after running Quarks in dev mode.

I saw no errors the first time it started, and I could access the admin panel just fine. However, the test cases for my application won't run now because the Keycloak container didn't start successfully the second time.

Anybody else running into this issue?

[quarkus-bot[bot]]

/cc @pedroigor (keycloak), @sberyozkin (keycloak)

[wmeints]

I just noticed that all test containers are started a second time when you resume tests in dev mode. I didn't expect this to happen to be honest.

Since I have keycloak on a fixed port, it fails to start, because it can't allocate the port a second time. Removing the fixed port resolves the issues with the tests. But it's kinda weird behavior if you ask me. I may be missing something important.

[sberyozkin]

@wmeints
When Keycloak Dev Service was designed, the decision was made to have a container that supports a Dev UI work be different from a container that supports the integration test work.

With OIDC Dev UI, you can test interactively, independently of the actual integration tests that can be long running and rather advanced. With Dev UI, users can go to OIDC Dev UI, login to Keycloak, and use Swagger or call directly specific Quarkus endpoints, and it all can go in parallel with the integration tests running in the background...

I wonder though if we could indeed support having a single container shared between Dev UI and test mode, doing it by default though can cause a lot of side-effects, so I'd rather us having a property for it, @michalvavrik, what do you think ?

[michalvavrik]

@michalvavrik, what do you think ?

frankly I was wondering why the new instance is started for tests, but I don't remember implementation details. I'll come back to this discussion when I have more time, think about it and dig in, until then I don't know...

[sberyozkin]

@michalvavrik Sure, I suggested the rationale for that in my initial response here, I don' t remember 100% how we talked with Stuart about it, but I'd say it is quite close...

Having two containers is not a big overhead and can support dev ui testing and integration test runs in parallel.
But, when a fixed port is chosen, I guess we don't have any options but to share the container, as otherwise it simply does not work as reported here.

May be a better idea is, if the test container detects that the devmode container is using the fixed port then the test container allocates a random port, and vice versa, similarly to how @geoand did it for the debug port.

[wmeints]

@sberyozkin Yes, that's correct. Now that I understand things a little better, I think it's trying to run the second instance on the same port. I expect that if I set the port in the dev or test profile it will only change the port for development or integration testing and the other one will use the dynamic port config.

I am using the fixed port setting so I have a fixed spot to point the nextjs application to that I have running separately. I'm not using the integration tests at the moment.

[sberyozkin]

This is how the debug port conflict is managed:

[WARNING] [io.quarkus.deployment.dev.DevModeCommandLineBuilder] Changed debug port to 36451 because of a port conflict

So we'd need to have something similar when a fixed-port property is used, may be:

[WARNING] [....KeycloakDecProcessor] Starting test container on port 36451 because of a port conflict with the devmode container

something like that.

@wmeints I won't have time to look into it now, so if you'd like, have a look. Otherwise, we might get some time in a few weeks after PTOs...

[wmeints]

I have some time tomorrow. I'll take a look if I can create a fix for this.