Use Address and Services registration to connect to Services by radcortez · Pull Request #43547 · quarkusio/quarkus

radcortez · 2024-09-26T20:16:20Z

Provide a Services repository to register services like Vert.x in a known alias. Consumers can then use these aliases to obtain the required Address to connect to the service:

my.service.url=quarkus://vertx-http

interface MyService {
  Address url();
}

MyService.url().getAsUrl();

The Address configuration can either use the service alias quarkus://vertx-http or a valid url http://localhost:8080. The Address will first query the registry and transform the service alias to the actual address where the service is running or just return the actual value if the service cannot be found.

One of the main goals of this change is to stop relying on system properties and configuration mutation to carry port changes between the configuration and the runtime service. See #42986.

Ideally, Address could also handle http://localhost:0 and query the registry for the service to use, which would allow us to avoid introducing breaking changes in the configuration.

Fixes Assign random ports at configuration start (not later) #42986

radcortez · 2024-09-26T20:32:24Z

It was opened as a draft to discuss the direction.

There are still many missing pieces, and the implementation is far from complete, so it may be difficult to review, but I think we need intermediary reviews before we get too invested in the implementation to avoid wasted work.

radcortez · 2024-09-26T20:34:37Z

See #43220 for additional context

github-actions · 2024-09-26T20:49:13Z

🎊 PR Preview f0762e4 has been successfully built and deployed to https://quarkus-pr-main-43547-preview.surge.sh/version/main/guides/

Images of blog posts older than 3 months are not available.
Newsletters older than 3 months are not available.

cescoffier · 2024-09-27T14:07:40Z

I need to think about it, but it's close to Stork. I think it can be confusing.

cescoffier · 2024-09-27T14:08:13Z

Also, some data will not be available at startup time, but "later".

radcortez · 2024-09-27T16:03:57Z

Also, some data will not be available at startup time, but "later".

Which data?

dmlloyd · 2024-09-27T16:14:42Z

            .overrideRuntimeConfigKey("quarkus.http.port", "0")
            .overrideRuntimeConfigKey("quarkus.http.test-port", "0")
-            .overrideRuntimeConfigKey("quarkus.rest-client.EchoClient.url", "http://localhost:${quarkus.http.port}");
+            .overrideRuntimeConfigKey("quarkus.rest-client.EchoClient.url", "quarkus://vertx-http");


We should not use URLs in this way. The URL specifies the protocol to use, not the address. We could potentially have a special syntax for referencing a service address within a configuration key, alongside an "aware" parser/property type that knows how to parse it. We'd need one for URL configs, and a separate one (or maybe two) for socket address/port number configs.

The reason it's bad, by the way, just in this case for example we don't know whether it's http or https. We could theoretically glean that information from the service, but that's not 100% foolproof either because there could conceivably be URL schemes which are layered combinations of protocols, where the server would (at best) only be aware of the outer protocol. But that's just one example; any time you have a mismatch like this, it will be accompanied by a variety of subtle and hard-to-fix problems.

In this case quarkus://vertx-http is not an URL at all. Is just the key to lookup the service. It could has been foo.bar, as long as the service would register itselft as foo.bar. The service lookup would then return the proper URL.

I admit it is confusing because on how I choose the key name and the configuration name (which is current name).

Right, I got that. But the problem is that the service is identified on the client differently than on the server. We lose information that would normally be found only in the client URL scheme.

This was just a way to make a short alias and then for us to discuss. And doesnt' have to be this way.

I'm not expecting to ask users to go and change all their configuration for service names, so setting the standard url as http://localhost:${quarkus.http.port} would still need to be valid and we would need to rewrite the port (in case of randoms to use the right port).

Or we can just drop the names / alias completely and do only the rewriting of the port when required. Or do you want to make a hard break on that?

It's a little complex because services could be defined by host+port, by just port, by socket address (123.45.67.89:1234), etc. And, clients might define their access to that service by URL, by socket address, or by host+port, or some other creative scheme.

I think the abstraction of a "service" or "network service" is a good start. We can strictly define them as a "named" socket address. This is unambiguous (and actually corresponds reasonably well with what WildFly does).

If a client connects by socket address, then we would need a way to say "socket address or service", with a corresponding class that works with Converter that can give the correct SocketAddress when given access to the registry of running services.

If a client connects by URL, then we would need a way represent a URL with either a "normal" host/port part or else some token which signifies a local service should be used. This would be an extension relative to valid URL syntax so we cannot use java.net.URL/URI to represent these; rather we'd have a Converter-friendly class which can hold either a plain URL or else something that can resolve to a URL when given access to the registry of running services.

We could use a uniform syntax for these cases e.g. @{serviceName} or https://@{serviceName}/my/path, however if we do so, it should be made very clear that this syntax is not resolved by the configuration layer like properties are, but rather by the property's Converter itself.

Except it should not be named service, I prefer David's suggestion.

cescoffier

I'm a bit puzzled.

It seems that the proposed solution is actually a bit far from the initial problem (random ports). It seems to be a mix between service discovery and address resolution.

We should not have something that will introduce confusion.

cescoffier · 2024-10-09T08:35:14Z

+        private final String host;
+        private final int port;
+
+        public Service(final String protocol, final String host, final int port) {


As I already said, this is very close to Stork, and I think, it can be confusing.

Stork also has services, with a very similar API (with secure as additional field indicating if TLS needs to be used or not).

cescoffier · 2024-10-09T08:37:02Z

+        throw new UnsupportedOperationException();
+    }
+
+    public static Optional<Service> get(String name) {


The registration may happen at any time, and there is not way for a consumer to listen for the registration.

cescoffier · 2024-10-09T08:38:06Z

+import java.util.Objects;
+import java.util.Optional;
+
+public final class Address {


Vert.x 5 introduced Address andAddressResolver - that might be confusing to have something so close in term of naming (and actually locgic too)

cescoffier · 2024-10-09T08:39:03Z

+        }
+
+        public URI toUri() {
+            return URI.create(protocol + "://" + host + ":" + port);


It's slightly more complicated in reality (TLS or not, path (when using proxy...)

cescoffier · 2024-10-09T08:40:19Z

-            SmallRyeConfig config = ConfigProvider.getConfig().unwrap(SmallRyeConfig.class);
-            return config.getOptionalValue(uriValue().getName(), String.class);
-        }
+        Optional<Address> uri();


Again, it can be confusing when using stork, as stork will use an URL or baseURL starting with stork://<service-name>.

It's unclear if you need to use Stork or an Address.

cescoffier · 2024-10-09T08:42:10Z

            .overrideRuntimeConfigKey("quarkus.http.port", "0")
            .overrideRuntimeConfigKey("quarkus.http.test-port", "0")
-            .overrideRuntimeConfigKey("quarkus.rest-client.EchoClient.url", "http://localhost:${quarkus.http.port}");
+            .overrideRuntimeConfigKey("quarkus.rest-client.EchoClient.url", "quarkus://vertx-http");


Except it should not be named service, I prefer David's suggestion.

radcortez · 2025-03-27T15:48:29Z

We are discussing other ideas here #46915, before we get to a final implementation

Use Address and Services registration to connect to Services

ad113ca

quarkus-bot Bot added area/config area/core area/grpc gRPC area/rest area/rest-client area/resteasy-classic area/vertx labels Sep 26, 2024

radcortez requested review from cescoffier and dmlloyd September 26, 2024 20:34

dmlloyd reviewed Sep 27, 2024

View reviewed changes

cescoffier reviewed Oct 9, 2024

View reviewed changes

radcortez mentioned this pull request Oct 26, 2024

Migrate Quarkus Vert.x HTTP extension config classes to @ConfigMapping #44115

Closed

radcortez mentioned this pull request Dec 13, 2024

Assign random ports in Config #43220

Closed

radcortez mentioned this pull request Jan 31, 2025

Public API for hostname and port #39209

Closed

radcortez closed this Mar 27, 2025

quarkus-bot Bot added the triage/invalid This doesn't seem right label Mar 27, 2025

Conversation

radcortez commented Sep 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

radcortez commented Sep 26, 2024

Uh oh!

radcortez commented Sep 26, 2024

Uh oh!

github-actions Bot commented Sep 26, 2024

Uh oh!

cescoffier commented Sep 27, 2024

Uh oh!

cescoffier commented Sep 27, 2024

Uh oh!

radcortez commented Sep 27, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cescoffier left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

radcortez commented Mar 27, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

radcortez commented Sep 26, 2024 •

edited

Loading