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

Convention for optionally inferring configuration values #33583

Open
iocanel opened this issue May 24, 2023 · 1 comment
Open

Convention for optionally inferring configuration values #33583

iocanel opened this issue May 24, 2023 · 1 comment
Labels
area/config kind/enhancement New feature or request

Comments

@iocanel
Copy link
Contributor

iocanel commented May 24, 2023

Description

Every know and then I come accross the case of having an Optional configuration property that the user is expected to provide and a secondary boolean flag that pretty much tells Quarkus to try and infer the value of the Optional property.

Recent example comming from: #33437:

    /**
     * The gRPC port to use for the probe (the format is either port or port:service).
     */
    @ConfigItem
    Optional<String> grpcAction;

    /**
     * If enabled and `grpc-action` is not provided, it will use the generated service name and the gRPC port.
     */
    @ConfigItem(defaultValue = "false")
    boolean grpcActionEnabled;

In the example above:

  • If user specified nothing no grpcAction gets exposed.
  • If user specifies grpcAction it's used as is.
  • if user specifies grpcActionEnabled then grpcAction gets inferred.

I would like to propose an alternative for such cases, that is having a value like: <auto> to signify that the property is meant to be automatically configured. Of course for this change to be meaningfull it needs to be widely applied.

Thought's?

Implementation ideas

No response

@iocanel iocanel added the kind/enhancement New feature or request label May 24, 2023
@iocanel iocanel changed the title Convention for optioanlly inferring configuration values Convention for optionally inferring configuration values May 26, 2023
@iocanel
Copy link
Contributor Author

iocanel commented May 26, 2023

I experimented a little bit with it in order to find an elegant solution.

The goal of these experiments was to find a safe way of adopting conventions like the one described.
I didn't manage to find a proper solution but here are some things I've tried and the limitation of each approach.
I am putting my findings here for future reference.

For all the described approaches the end goal was to be able to dfined properties like this:

quarkus.kubernetes.readiness-probe.grpc-action.auto = true
quarkus.kubernetes.readiness-probe.grpc-action = someservice:9999

In other words instead of defining multiple properties at the same level to have some sort of optional fields under the same property to influence the behavior.

ConfigGroup + Converter

quarkus.kubernetes.readiness-probe.grpc-action is not recognized as a valid key.

EnumMap + Converter

  • EnumMap does not seem to be recognized as Map (I think this goes for all types extending Map, but not 100% sure).
  • Only String keys are supported.

Map + Converter

  • can't restrict keys.
  • quarkus.kubernetes.readiness-probe.grpc-action is not recognized as a valid key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/config kind/enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants