Proposal: zipkin-gcp #45
Comments
|
does it still make sense to have Stackdriver storage? |
|
does it still make sense to have storage?
Storage allows non-java apps to send, so depends on how much of this there
is. For example, it wouldn't matter for Spring, but it could for existing
apps using zipkin-go or things like lyft envoy.
|
|
Sounds like we should def keep it! |
|
Before I broadcast further, is it safe to say that goog folks helping with
this wouldn't decrease as an effect of moving to an openzipkin org? While
myself and others are comfortable helping with regular releases, docker,
zipkin-drift etc, it would be nice to know if y'all will still champion and
watch over the code.
|
|
@saturnism when you mention that there are multiple Zipkin subprojects targeting different cloud environments, do you mean Zipkin collectors like this one that forward data to a different backend or something else? Is the proposal that we transform this into a Zipkin collector that can forward traces to many different backends? |
|
@mtwo different zipkin collectors are definitely part of it. but also different senders as well. E.g., a zipkin sender that can send directly to Stackdriver or Pub/Sub. As well as collectors that can consume Zipkin from Pub/Sub too. We would still have the current storage module, etc. For example, there is currently a stackdriver-zipkin collector module - but i feel it's not how zipkin defines collectors AFAIK. Collectors listens to some input sources, such as pub/sub. |
|
@mtwo also, with these modules, users have a lot of choices in terms of how they can mix & match the components to their needs. For example:
|
|
Got it, thanks. So with this design, a single sender would allow traces to be exported from Brave or a Zipkin server? Seems neat. @adriancole no issues from me with moving the project to another org, let me double check with legal and let's get @bogdandrutu to comment as well. |
|
@mtwo that's the idea :) and brave is pretty awesome already. |
|
FYI for all, @saturnism and I are on a thread to get the repo moved. We'll post back once we get confirmation. |
|
FYI for all, @saturnism <https://github.com/saturnism> and I are on a
thread to get the repo moved. We'll post back once we get confirmation.
cool. working on things to make the conversion easier. For example, a
change is landing soon in both brave and sleuth to make it unnecessary to
split IDs. We can likely push that type of change through most libraries
which makes conversion to stackdriver far more direct.
|
|
I asked around internally about issues with porting this and nobody raised an exception, so I think we're good to go. Did you want to just fork the code or have the repo moved (assuming that GitHub supports such an operation)? Forking might be easier so that we can keep the collector operating as-is until the replacement is ready. |
|
Thanks for getting back.. I meant to nag you anyway.
I think moving the repo is the least confusing long-term, and how we've
dealt with similar repos. Probably easiest way is to leave the repo here
until the code is in the right shape, then move it. So, basically move it
after it is ready then immediately release under the zipkin packaging (like
the same hour we move it).
Make sense?
So probably first step is to rename the repo here to zipkin-gcp. I can help
shuffle the code having done it recently for aws.
…On Fri, Oct 20, 2017 at 6:41 AM, Morgan McLean ***@***.***> wrote:
I asked around internally about issues with porting this and nobody raised
an exception, so I think we're good to go. Did you want to just fork the
code or have the repo moved (assuming that GitHub supports such an
operation)?
Forking might be easier so that we can keep the collector operating as-is
until the replacement is ready.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#45 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD61-Cdt6nFq5qZx80irJcoFhmLzeKhks5st9AKgaJpZM4PSFiz>
.
|
|
I don't have perms to change the name, but Bogdan or Gopi likely do. However given that this is in the Google org, it may end up being easier to fork it to the Zipkin org and then delete it here once the work is done (?). |
|
The name change isn't important enough to make a fork and then kill it in
zipkin org (people might get confused and fork it between now and then..)
Let's leave the name as is until move if a problem.
|
|
FYI I have started on this, and probably need a day or two before raising a PR. When I raise the PR, it will look just like the other zipkin extensions (including build setup so we can publish it). When ready to merge, we can do a last release here, then move the repo and do a first release there. cc @anuraaga |
gRPC uses Netty 4.1 and `netty-tcnative-boringssl-static`, which is sensitive to Netty versions. DataStax Cassandra driver 4.0 uses Netty 4.1, but the driver isn't out, yet. By using the published shaded jar, we can dodge the conflict for now. I've verified that we can connect to google cloud services after this change. I've also verified that there's no significant jar size change. See https://github.com/grpc/grpc-java/blob/master/SECURITY.md#netty See openzipkin/zipkin-gcp#45
|
I had to make a server change to dodge netty conflicts. This is blocking work, but not for long openzipkin/zipkin#1788 |
gRPC uses Netty 4.1 and `netty-tcnative-boringssl-static`, which is sensitive to Netty versions. DataStax Cassandra driver 4.0 uses Netty 4.1, but the driver isn't out, yet. By using the published shaded jar, we can dodge the conflict for now. I've verified that we can connect to google cloud services after this change. I've also verified that there's no significant jar size change. See https://github.com/grpc/grpc-java/blob/master/SECURITY.md#netty See openzipkin/zipkin-gcp#45
|
#48 sorry took me so long to get started on this |
|
#109 is for pub/sub |
gRPC uses Netty 4.1 and `netty-tcnative-boringssl-static`, which is sensitive to Netty versions. DataStax Cassandra driver 4.0 uses Netty 4.1, but the driver isn't out, yet. By using the published shaded jar, we can dodge the conflict for now. I've verified that we can connect to google cloud services after this change. I've also verified that there's no significant jar size change. See https://github.com/grpc/grpc-java/blob/master/SECURITY.md#netty See openzipkin/zipkin-gcp#45
There are a couple of zipkin subprojects targeting different cloud environments. We should look into how to evolve this into the same fold, e.g., zipkin-gcp. zipkin-gcp should can have the following:
We can also use
spring-cloud-gcp-coreas the basis for getting Project ID and Credentials.Current
stackdriver-zipkinbehavior can ultimately be composed by:The text was updated successfully, but these errors were encountered: