armerify

[codefromthecrypt]

I think we can do more and get out of dodging netty and/or boringssl conflicts by moving the stackdriver collector (not necessarily the sender) to armeria. This would imply figuring out if armeria has an oauth feature which is compatible with stackdriver

cc @openzipkin/armeria

[anuraaga]

What does it mean to migrate the collector to armeria? I thought the armeriafication of zipkin-server effectively makes all collectors armeria.

As for sending, here's an example of using armeria to issue gRPC to Google apis, including trace

https://github.com/curioswitch/curiostack/blob/master/common/google-cloud/core/src/main/java/org/curioswitch/curiostack/gcloud/core/grpc/GrpcApiClientBuilder.java

[codefromthecrypt]

What does it mean to migrate the collector to armeria? I thought the armeriafication of zipkin-server effectively makes all collectors armeria.

what I mean to say is that the sender may still want to be normal grpc as that's inside calling applications. we can scope the change to collector only in other words vs assuming armeria sending from instrumented applications will be routine.

As for sending, here's an example of using armeria to issue gRPC to Google apis, including trace https://github.com/curioswitch/curiostack/blob/master/common/google-cloud/core/src/main/java/org/curioswitch/curiostack/gcloud/core/grpc/GrpcApiClientBuilder.java

thanks!

[codefromthecrypt]

@anuraaga your approach looks good. Only concern is that it doesn't appear the auth package is extracted into a jar we could consume. I wonder if it could be a submodule in armeria or somewhere else?

[anuraaga]

Ah yeah - that package is sort of overkill, it is to get auth tokens using armeria, but in reality is only called every few minutes anyways. Zipkin should use the official Google auth library that just uses a Java URL.

I can whip something up over the weekend

[codefromthecrypt]

PS I noticed we are still depending on grpc classes, which brings in a tainted dependency tree as they assume late version of guava (and old version of gson but not to api peril). Would be nice to implement grpc transport without this problem, but for now we can dodge. The issue is mostly the fight over guava which requires our server to artificially track here just to not conflict..

[anuraaga]

Hmm - it would be almost trivial to issue raw requests without the armeria-grpc at all in this case.

Unary requests are simple to frame. It would be difficult though to support advanced features like message compression, though, for which even armeria-grpc leaves the details to grpc-core. I guess message compression could be useful if posting from a different cloud, but don't know if the trace server even enables it.

[codefromthecrypt]

@anuraaga yeah I suppose it would just be about the request auth etc.

for this specific integration though, only what is supported by stackdriver is needed.. but you are right to say certain compression things will make sense to support. There's sortof a push and pull here, but one guarantee is that grpc dep chain moves regardless of us and in incompatible ways. One of the benefits to armeria was to try and get out of that :P

[anuraaga]

The request auth would be using the google auth library, which is not updated as much as grpc (though I guess still depends on guava...). I think in practice, it really is only about compression. If we decided not to support it, we can rip out all the gRPC. I lean towards doing so since I guess most people will be using this in on GCP and don't care about compression.