Move gRPC extension to new Vert.x gRPC impl

[alesj]

Added support for new Vert.x client/server based implementation.
It doesn't instantiate and start any new gRPC servers, it re-uses existing HTTP server.
The client side uses own Vert.x based Channel implementation.

New code is split between server and client side (doh!).
Server side simply registers a new route against existing HTTP server, only serving gRPC requests (based on content-type atm). Actual services and interceptors handling stays the same. The new implementation currently needs to be explicitly enabled: quarkus.grpc.server.use-separate-server=false
Client side instantiates a new Vert.x GrpcClient based Channel implementation, handling client closure at the stop.
Interceptors handling stays the same. Not all previous client config could be mapped onto new implementation (TODO?).
The new implementation currently needs to be explicitly enabled: quarkus.grpc.clients.<name>.use-quarkus-grpc-client=true
I guess once we feel comfortable enough, we'll revert the configuration usage for implementation selection.

Almost all (except the one's with load balancing / Stork) gRPC tests now have double "flavour":

• old gRPC way - with new server
• new Vert.x server way, with re-using HTTP server

Also added a mixture test - mixing old server with new client, and vice-versa.

New Vert.x client implementation is still missing load balancing and name resolver support.
(hence missing Vert.x client based tests ... a TODO)

[quarkus-bot]

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

• title should not end up with dot

This message is automatically generated by a bot.

[cescoffier]

@alesj there are various gRPC tests failing, can you have a look?

[alesj]

Hmmm, I thought I have disabled these plain-text-mutiny tests … as they are sure not to work — missing Stork impl

…

On Tue, 18 Oct 2022 at 16:38, Clement Escoffier ***@***.***> wrote: @alesj <https://github.com/alesj> there are various gRPC tests failing, can you have a look? — Reply to this email directly, view it on GitHub <#28654 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACRA6HTUCKTIG5XQMKMGKLWD2Y7ZANCNFSM6AAAAAARH372TE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cescoffier]

I made a few comments, but it's really great!

[cescoffier]

should we create an epic with the missing pieces (this one, stork...)?

[alesj]

Yeah, that would be good -- so we don't miss out or forget.

[cescoffier]

We need to prepare:

• documentation explaining how to use this mode and the rationale
• the migration guide
• a blog post explaining the concepts and when we will make this the default

[geoand]

We need to prepare:

* documentation explaining how to use this mode and the rationale

* the migration guide

* a blog post explaining the concepts and when we will make this the default

Very much +1.

I've also added the noteworthy-feature label which can be well explained in the resources mentioned above

[quarkus-bot]

Failing Jobs - Building 0adf6c1

Status	Name	Step	Failures	Logs	Raw logs
✔️	Gradle Tests - JDK 11
✖	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.BasicJavaLibraryModuleTest.testBasicMultiModuleBuild line 25 - More details - Source on GitHub

java.lang.AssertionError: 

Expecting path:

✖ io.quarkus.gradle.devmode.BasicJavaLibraryModuleDevModeTest.main line 23 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

📦 integration-tests/gradle/target/classes/basic-java-library-module/application

✖ org.acme.ApplicationConfigResourceTest.testAppConfigEndpoint() - More details - Source on GitHub

java.lang.RuntimeException: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.kubernetes.client.deployment.DevServicesKubernetesProcessor#setupKubernetesDevService threw an exception: java.lang.RuntimeException: java.lang.IllegalStateException: Could not find a valid Docker environment. Please see logs and check configuration
	at io.quarkus.kubernetes.client.deployment.DevServicesKubernetesProcessor.setupKubernetesDevService(DevServicesKubernetesProcessor.java:119)

[gsmet]

@cescoffier I let you merge it if you think it's ready.

[cescoffier]

Yes it is, I just wanted to target 2.15.

[gsmet]

Well, then you're good to go as main is 2.15.

[rsvoboda]

We need to prepare:

• documentation explaining how to use this mode and the rationale
• the migration guide
• a blog post explaining the concepts and when we will make this the default

Atm there is

• release note is quite short - https://quarkus.io/blog/quarkus-2-15-0-final-released/#new-grpc-implementation, not mentioning that the new impl is not enabled by default
• no blog post - https://quarkus.io/blog/
• no entry in migration guide - https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.15

@alesj / @cescoffier / @gsmet

[cescoffier]

@alesj ^

[alesj]

@rsvoboda this was added / commited:

• 44c956d

The blog is wip ...
And I guess some more info at the migration guide would be useful?