Skip to content
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

Some Quarkus mode are enforcing a specific profile making it impossible to use another config profile #27760

Closed
ia3andy opened this issue Sep 6, 2022 · 6 comments · Fixed by #28091
Assignees
Labels
Milestone

Comments

@ia3andy
Copy link
Contributor

ia3andy commented Sep 6, 2022

Describe the bug

I am trying to use remote dev mode on openshift, I have a specific profile for openshift named openshift.

When I activate remote dev mode, dev profile gets activated breaking the configuration which needs the openshift profile to work.

Expected behavior

Have both dev and openshift profiles enabled when it was used at build time or when it is set with quarkus.profile.

Actual behavior

Only dev gets activated

How to Reproduce?

I can prepare a reproducer if needed.

@ia3andy ia3andy added the kind/bug Something isn't working label Sep 6, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented Sep 6, 2022

/cc @geoand, @iocanel

@ia3andy ia3andy changed the title Some Quarkus mode are enforcing a specific profile making it impossible to use another profile Some Quarkus mode are enforcing a specific profile making it impossible to use another config profile Sep 6, 2022
@ia3andy
Copy link
Contributor Author

ia3andy commented Sep 6, 2022

cc @radcortez @dmlloyd

@dmlloyd
Copy link
Member

dmlloyd commented Sep 8, 2022

There needs to be clear semantic rules around how the profiles combine. For example, if profiles %a and %b are both active, then properties %a.foo and %b.foo in the same configuration file are in conflict.

I would suggest that the order of profile activations would determine the relative priority of the properties. Just as %a.foo would take precedence over foo when %a is activated, then activating profiles in the order %a, %b would cause %a.foo to have precedence over %b.foo, and in turn %b.foo has precedence over foo. Reversing the order (i.e. %b, %a) would in turn cause %b.foo to have precedence over %a.foo which in turn has precedence over foo. In this way, a virtual "empty" profile can be seen as an always-activated profile which always has lower priority in comparison to explicitly activated profiles.

Thoughts?

@radcortez
Copy link
Member

This is what we already have implemented in SmallRye Config:
https://smallrye.io/smallrye-config/Main/config/profiles/

The difference is that we reverse the order of the profile listing, meaning that if we have profile a and b in this order, b has precedence over a. The rationale was that you are most likely going to define the generic profiles first and the specific ones later, for instance, if you have a profile common and another dev, you most certainly want to have dev override common, so it is more natural to express that by common,dev (in my opinion :)).

@dmlloyd
Copy link
Member

dmlloyd commented Sep 12, 2022

That works, we just have to be sure that it is very clear that "last is best".

@ia3andy
Copy link
Contributor Author

ia3andy commented Sep 12, 2022

That sounds good, @radcortez let me know if I can help on this ;-)

@radcortez radcortez self-assigned this Sep 13, 2022
@quarkus-bot quarkus-bot bot added this to the 2.16 - main milestone Nov 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants