Allow for layered profiles to simplify use of command mode and "dev" deployments

[maxandersen]

Description With command mode and openshift/kubernetes deployment extension I'm starting to think it would be useful to have a notion of layered profiles.

Usecase is as follows for command mode: Today when adding a @QuarkusMain into a project that also has a http end point things gets messy.

For now I'm adding a cli profile to my application.properties with the following content:

%cli.quarkus.log.level=SEVERE
%cli.quarkus.hibernate-orm.log.sql=false
%cli.quarkus.banner.enabled=false

Now I can run the cli with QUARKUS_PROFILE=cli and output is now more sane.

Problem is that as soon as I want to use quarkus:dev mode I loose the cli settings and if I enable cli profile I loose the dev settings (i.e. I would like to have quarkus.hibernate-orm.database.generation=drop-and-create on only for devmode)

Only other alternative I come up with is to split out the cli class in separate module but that is not great either as it requires:

• 1 java file (MyCli.java)
• 1 redundant/duplicated application.properties
• 1 pom.xml
• ~9 directories (src/main/*)

Similar issue occurs using kubernetes/openshift extension where you like to have a "dev-deployment" profile but not wanting to duplicate the "dev" settings just to do a deployment.

Thus my suggestion is to allow for layered profiles particularly to handle command mode but potentially also useful beyond it.

Implementation ideas This makes current getActiveProfile() less precise, but could just have it return the "default" profile which would be either prod, dev or test as it is today. Then have two methods, like List<String>[] getActiveProfiles() and boolean isProfileActive(String name) to allow more fine grained detection.

[maxandersen]

@dmlloyd @stuartwdouglas comments/alternatives to this ?

[dmlloyd]

We should not use profiles for CLI IMO. It is orthogonal to the original use case for profiles.

[maxandersen]

@dmlloyd what would be used instead ? if not profiles then only option (I see) is a separate module which is just overkill (see above amount of junk that adds).

Also, its not just for command mode/cli. see comment about deployment variations.

[dmlloyd]

Profiles just were not designed in this way, and furthermore they're partway through being added to the MP Configuration specification.

The problem definition is that essentially you want to be able to build more than one program from the same code base. The problem definition of profiles is that the same program has different behaviors in different scenarios.

What about instead of overloading profiles, we add a new "layer" of indirection for application? So profiles would use %foo but applications could use, for example, @bar and be processed after profiles.

In this way, you can have both a profile and an application. The application name could normally be set using a Maven profile for example. Then your configuration could contain something like:

@app1.quarkus.package.main-class=com.myapp.App1
@app2.quarkus.package.main-class=com.myapp.App2
%dev.@app2.quarkus.package.main-class=com.myapp.App2WithDebugStuff
# etc.

This keeps the configuration compact.

Now if your two applications have radically different configuration, you're going to want to rethink your stance on having two modules. There is a point where the configuration gets too ridiculous!

[stuartwdouglas]

Why do you have an app that is both a CLI app and a HTTP based app? Are they run from seperate main classes, just both in the same package? This just generally seems problematic as when you run the CLI app it is still going to open the HTTP endpoint.

[maxandersen]

Now if your two applications have radically different configuration, you're going to want to rethink your stance on having two modules. There is a point where the configuration gets too ridiculous!

yes, I fully get that - this is for the case where majority of setup is exactly the same except for a few parameters.

I'm not sure the "app" approach would cover the aspect of being able to layer things in the deployment usecase (i.e. variations wether you target minikube or openshift) ?

[maxandersen]

Why do you have an app that is both a CLI app and a HTTP based app? Are they run from seperate main classes, just both in the same package? This just generally seems problematic as when you run the CLI app it is still going to open the HTTP endpoint.

I can see usecases for that - but also kinda hoping we had a way to say "quarkus.http.enabled=false" - you still want all the other setup happening just that in this run variation I don't need http requests handled.

[famod]

@maxandersen

Thus my suggestion is to allow for layered profiles particularly to handle command mode but potentially also useful beyond it.

Sounds like #6810. @radcortez is already working on an enhancement for sr-config: https://github.com/smallrye/smallrye-config/pull/399

[radcortez]

I believe this is now supported with multiple profiles: https://quarkus.io/guides/config-reference#multiple-profiles