Remote dev in combination with devservices is broken since 2.0.0.Alpha1

[edeandrea]

Describe the bug

This worked fine in 2.0.0.Alpha1 but is now broken in Alpha2, Alpha3, CR1, CR2, and CR3. When trying to do remote dev it seems that the QUARKUS_DATASOURCE_DEVSERVICES=false environment variable is not respected. When I deploy an application to kubernetes and I set the environment variables QUARKUS_LAUNCH_DEVMODE=true and QUARKUS_DATASOURCE_DEVSERVICES=false, the Pod crashes and never starts. Here's the log from the pod:

2021-06-11 20:03:33,945 WARN  [io.qua.con.ima.dep.ContainerImageProcessor] (build-9) Can't get the current user name, which is used as default for container image group. Can't publish container image info.
2021-06-11 20:03:34,635 WARN  [io.qua.kub.dep.KubernetesProcessor] (build-27) No project was detected, skipping generation of kubernetes manifests!
2021-06-11 20:03:35,130 ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
    [error]: Build step io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor#configurationDescriptorBuilding threw an exception: io.quarkus.runtime.configuration.ConfigurationException: Model classes are defined for the default persistence unit, but no default datasource was found. The default EntityManagerFactory will not be created. To solve this, configure the default datasource. Refer to https://quarkus.io/guides/datasource for guidance.
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.handleHibernateORMWithNoPersistenceXml(HibernateOrmProcessor.java:780)
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.configurationDescriptorBuilding(HibernateOrmProcessor.java:287)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:820)
    at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
    at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
    at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2442)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1476)
    at java.base/java.lang.Thread.run(Thread.java:829)
    at org.jboss.threads.JBossThread.run(JBossThread.java:501)

    at io.quarkus.runner.bootstrap.AugmentActionImpl.runAugment(AugmentActionImpl.java:401)
    at io.quarkus.runner.bootstrap.AugmentActionImpl.createInitialRuntimeApplication(AugmentActionImpl.java:269)
    at io.quarkus.runner.bootstrap.AugmentActionImpl.createInitialRuntimeApplication(AugmentActionImpl.java:66)
    at io.quarkus.deployment.dev.IsolatedDevModeMain.firstStart(IsolatedDevModeMain.java:84)
    at io.quarkus.deployment.dev.IsolatedDevModeMain.accept(IsolatedDevModeMain.java:409)
    at io.quarkus.deployment.dev.IsolatedDevModeMain.accept(IsolatedDevModeMain.java:58)
    at io.quarkus.bootstrap.app.CuratedApplication.runInCl(CuratedApplication.java:132)
    at io.quarkus.bootstrap.app.CuratedApplication.runInAugmentClassLoader(CuratedApplication.java:89)
    at io.quarkus.deployment.mutability.DevModeTask.main(DevModeTask.java:69)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at io.quarkus.bootstrap.runner.DevModeMediator.doStart(DevModeMediator.java:50)
    at io.quarkus.bootstrap.runner.DevModeMediator.doDevMode(DevModeMediator.java:29)
    at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:35)
    at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:25)
Caused by: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
    [error]: Build step io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor#configurationDescriptorBuilding threw an exception: io.quarkus.runtime.configuration.ConfigurationException: Model classes are defined for the default persistence unit, but no default datasource was found. The default EntityManagerFactory will not be created. To solve this, configure the default datasource. Refer to https://quarkus.io/guides/datasource for guidance.
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.handleHibernateORMWithNoPersistenceXml(HibernateOrmProcessor.java:780)
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.configurationDescriptorBuilding(HibernateOrmProcessor.java:287)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:820)
    at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
    at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
    at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2442)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1476)
    at java.base/java.lang.Thread.run(Thread.java:829)
    at org.jboss.threads.JBossThread.run(JBossThread.java:501)

    at io.quarkus.builder.Execution.run(Execution.java:116)
    at io.quarkus.builder.BuildExecutionBuilder.execute(BuildExecutionBuilder.java:79)
    at io.quarkus.deployment.QuarkusAugmentor.run(QuarkusAugmentor.java:153)
    at io.quarkus.runner.bootstrap.AugmentActionImpl.runAugment(AugmentActionImpl.java:399)
    ... 16 more
Caused by: io.quarkus.runtime.configuration.ConfigurationException: Model classes are defined for the default persistence unit, but no default datasource was found. The default EntityManagerFactory will not be created. To solve this, configure the default datasource. Refer to https://quarkus.io/guides/datasource for guidance.
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.handleHibernateORMWithNoPersistenceXml(HibernateOrmProcessor.java:780)
    at io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor.configurationDescriptorBuilding(HibernateOrmProcessor.java:287)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:820)
    at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
    at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
    at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2442)
    at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1476)
    at java.base/java.lang.Thread.run(Thread.java:829)
    at org.jboss.threads.JBossThread.run(JBossThread.java:501)

I can try this out locally by doing ./mvnw clean package -DskipTests && export QUARKUS_LAUNCH_DEVMODE=true && export QUARKUS_DATASOURCE_DEVSERVICES=false && java -jar target/quarkus-app/quarkus-run.jar on a local project (attached to this ticket). If I change the version in the pom.xml to 2.0.0.Alpha1 then everything works fine. Anything later than that and it blows up and does not work.

The application uses Panache reactive and the reactive postgres driver.

fmc-live-coding.zip

[quarkus-bot[bot]]

/cc @geoand, @stuartwdouglas

[geoand]

Dev services should likely not be run when using remote-dev

[edeandrea]

Yes which is why I set QUARKUS_DATASOURCE_DEVSERVICES=false. Doing that worked fine in Alpha1 but no longer works in Alpha2, Alpha3, CR1, CR2, or CR3.

My app binds to a database therefore when I set QUARKUS_LAUNCH_DEVMODE=true devservices is kicking in and is not respecting the environment variable telling it not to.

[geoand]

Right, that is definitely undesirable.

[edeandrea]

Good thing I did a dry run yesterday before my customer demo next week :)

[geoand]

We need you to do this sort of demo more often 😜

[edeandrea]

I'll do my demo using Alpha1

[geoand]

Testing the Hibernate ORM Panache Quickstart using either 2.0.0.CR3 or Quarkus built from main and the following in application.properties:

quarkus.hibernate-orm.database.generation=drop-and-create
quarkus.hibernate-orm.log.sql=true
quarkus.hibernate-orm.sql-load-script=import.sql

quarkus.package.type=mutable-jar
quarkus.live-reload.password=changeit

Then building the jar and running it with:

QUARKUS_LAUNCH_DEVMODE=true QUARKUS_DATASOURCE_USERNAME=quarkus_test QUARKUS_DATASOURCE_PASSWORD=quarkus_test QUARKUS_DATASOURCE_JDBC_URL=jdbc:postgresql://localhost/quarkus_test java -jar target/quarkus-app/quarkus-run.jar

runs as expected (against a PosgresSQL started with docker run --ulimit memlock=-1:-1 -it --rm=true --memory-swappiness=0 --name quarkus_test -e POSTGRES_USER=quarkus_test -e POSTGRES_PASSWORD=quarkus_test -e POSTGRES_DB=quarkus_test -p 5432:5432 postgres:10.5)

[edeandrea]

Are you running that local on your machine or in a kubernetes pod? I'm also using panache reactive and the reactive postgres driver. I attached a reproducer example to the original ticket.

[geoand]

Are you running that local on your machine or in a kubernetes pod? I'm also using panache reactive and the reactive postgres driver. I attached a reproducer example to the original ticket.

Yes I know. But what am saying is that things works as expected.

For good measure, I will try your example as well

[edeandrea]

But they dont....

Take my example and run ./mvnw clean package -DskipTests -Dquarkus.kubernetes.deploy=true against a k8s cluster. When the pod deploys it goes into a crash loop state with the error message I gave. The generated k8s resources look correct (i.e. openshift.ymll. It has all of the correct info for the db. Switching the quarkus version back to Alpha1 and re-running things then work.

Additionally, locally if you run

./mvnw clean package -DskipTests && export QUARKUS_LAUNCH_DEVMODE=true && export QUARKUS_DATASOURCE_DEVSERVICES=false && java -jar target/quarkus-app/quarkus-run.jar locally it produces the same error as the pod does upon k8s deployment. Those same commands work in Alpha1.

[geoand]

They do work. I just tried the Hibernate Reactive Panache Quickstart and it worked as well.

There seems to be something wrong with your example. I'll spend a few minutes trying to figure it out

[edeandrea]

Not sure it matters, but another difference between what I'm doing and what you have is that the database username/password/etc is injected via a reference to a secret.

I'm not sure what could be wrong with it. Switching to Alpha1 it works fine. Simply changing the quarkus version to anything later than Alpha1 without any other changes and then it breaks.

[edeandrea]

Also I certainly don't expect you to be working on a Saturday. We can take it up on monday.

[geoand]

I was able to reproduce the problem in the Panache Reactive Quickstart in 2.0.0.CR3. The problem does not seem to exist in the latest build from main.

Trying out your application, it works properly when running:

QUARKUS_LAUNCH_DEVMODE=true QUARKUS_DATASOURCE_USERNAME=quarkus_test QUARKUS_DATASOURCE_PASSWORD=quarkus_test QUARKUS_DATASOURCE_REACTIVE_URL=vertx-reactive:postgresql://localhost/quarkus_test java -jar target/quarkus-app/quarkus-run.jar

using Quarkus built from main (and it does indeed fail when using 2.0.0.CR3).

Also I certainly don't expect you to be working on a Saturday. We can take it up on monday.

Well, good for me I did, now I don't have to do anything about it on Monday 😉

[edeandrea]

Admit it - you were doubting me :)

[geoand]

I doubt everything :)

[edeandrea]

Well, good for me I did, now I don't have to do anything about it on Monday 😉

Except maybe find the flaws in the test suite that allowed this to not be discovered by automated testing? :)

[edeandrea]

I doubt everything :)

Said like a true framework/library developer - its always user error....

[geoand]

I doubt everything :)

Said like a true framework/library developer - its always user error....

Now that is a reach :)

[geoand]

Well, good for me I did, now I don't have to do anything about it on Monday wink

Except maybe find the flaws in the test suite that allowed this to not be discovered by automated testing? :)

There are more pressing things to be done TBH. If this comes up again, someone (maybe me, maybe not) will look into it

[edeandrea]

Any chance of publishing a 2.0.0.CR4 containing this? :)

[geoand]

I don't think CR4 is on the roadmap. .Final will be released most likely next week