https://github.com/quarkusio/quarkus/pull/13601 changes default URL for non application endpoints

 It is breaking change at it needs to be clearly communicated to the customers

Discussion from Zulip to give some context:

Rostislav Svoboda: Hi @Thomas Qvarnstrom , I did some MP metrics quickstarts failure investigation and it turns out it failed because of https://github.com/quarkusio/quarkus/pull/13601 change merged on Friday

Rostislav Svoboda: The fix is "easy" - https://github.com/quarkusio/quarkus-quickstarts/pull/730/files

Rostislav Svoboda: But it can have implications on customer deployments, e.g. when they use something home baked or custom deplouyments descriptors, URL for metrics, halth, etc. will be changed in Quarkus 1.11

Thomas Qvarnstrom: @Rostislav Svoboda Is this an issue in community or product?

Rostislav Svoboda: Quarkus 1.10 uses /health, /metrics, Quarkus 1.11 will use by default /q/health, /q/metrics

Rostislav Svoboda: This will have implication on RHBQ 1.11

Rostislav Svoboda: breaking change

Thomas Qvarnstrom: This has been discussed in team meetings before and for backwards compatibility you can set quarkus.http.framework-root-path=/. I don't recall the reasoning behind this right now (dealing with other stuff).

Thomas Qvarnstrom: I believe this had to do with the developer console.

Rostislav Svoboda: I know about the the property, just wanted to highlight it as it affects RHBQ 1.11 release

Rostislav Svoboda: and it comes in the last community release before productization

Thomas Qvarnstrom: Yes, good. Can you log JIRA ticket about it in cannonball so that we don't forget about it.

Rostislav Svoboda: having stuff under /q can help to block access for non application endpoints

Rostislav Svoboda: one block rule ...

Thomas Qvarnstrom: Exactly, so that we you can for example only allow '/q' to 127.0.0.1.

George Gastaldi: It would be nice to have documented the steps on how to block access (in Openshift perhaps) to /q from the outside world

Thomas Qvarnstrom: IMO as long as we document that we for security reasons has moved these to a separate path allowing you to have more granular security configurations and as long as we explain that using that setting you can revert back to the old behavour I think it's fine to include in RHBQ 1.11. It wouldn't be ok for 1.7.6.