@keycloak/cloud-native @ahus1 JFYI - the majority of the work is done. But it needs to be polished. It'd be great to review at least the semantics around this. Thanks!

@mabartos - I'm happy to see this feature evolve. It's been a while since I've added it to my wish-list.

I think enabling TLS for the management port is useful, so exposing for adding this. This includes also the client authentication.

The option I think is least useful is management-relative-path. Still people might put it behind a reverse proxy, and then they might want to have it, so I'd be ok to keep it.

Something that surprised me was that the management port answers with a 404, which makes it difficult to test for an admin if it has been set up correctly. I suggest to have a minimal 200 response, maybe something like this:
a9d19ae - this is an adapted snippet from the Quarkus docs, see https://quarkus.io/guides/management-interface-reference

Thinking about it a bit more, it should answer to management-relative-path configurable path, and the root path should redirect to that management-relative-path. WDYT?

The option I think is least useful is management-relative-path.

@ahus1 Thank you for the review! I agree. I don't have a relevant use case in mind that would benefit from changing the context root / relative path for metrics and health.

Unreported flaky test detected

If the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR.

org.keycloak.testsuite.admin.concurrency.ConcurrencyTest#testAllConcurrently

Keycloak CI - Base IT (1)

java.lang.RuntimeException: There were failures in threads. Failures count: 1
	at org.keycloak.testsuite.admin.concurrency.AbstractConcurrencyTest.run(AbstractConcurrencyTest.java:122)
	at org.keycloak.testsuite.admin.concurrency.AbstractConcurrencyTest.run(AbstractConcurrencyTest.java:63)
	at org.keycloak.testsuite.admin.concurrency.AbstractConcurrencyTest.run(AbstractConcurrencyTest.java:59)
	at org.keycloak.testsuite.admin.concurrency.ConcurrencyTest.concurrentTest(ConcurrencyTest.java:61)
...

Report flaky test

Would it make sense to put the management options under http, e.g. --http-management-port? From my perspective it logically belongs there.

@vmuzikar I'd like to follow the Quarkus approach, having it as a separate concept and not mixing it together. I see more UX benefits with that. As we'd use more fine-grained categories, the docs and help would be more readable. Additionally, the Keycloak options could be simpler in terms of the name length. Even for the consistency reasons, we'd need to have options like http-relative-path=http-management-relative-path, and https-certificate-file=https-management-certificate-file. Considering the default ordering of the props in docs, it'd be kinda messy and not so much user-friendly.

@vmuzikar Is it ok to have it separated?

@mabartos Thank you for the summary. @ahus1 Do you have any objections against 1-5?

I'd like to follow the Quarkus approach, having it as a separate concept and not mixing it together

+1 for a separated category. That totally makes sense to me from the readability perspective. What I meant was just the prefix of the option names. To me management sounds a bit ambiguous in Keycloak context. I realize Quarkus uses this naming but I'd argue it doesn't mean it's the best UX for Keycloak use case as well. ;) That's why I was proposing http-management to make it clear it's relevant to an HTTP(S) interface.

What I meant was just the prefix of the option names.

@vmuzikar Oh, I see. Ok, makes sense. We can mirror the convention set for Keycloak HTTP options - http-management-* and https-management-*.

We can mirror the convention set for Keycloak HTTP options

Exactly. :)

@vmuzikar / @mabartos - works for me. Looking forward to a green build and a merge.

@vmuzikar Thanks for the review. Comments should be addressed now.