README clarifications

[codefromthecrypt]

per #42 (comment)

We should highlight that this code (which ends up in the openzipkin/zipkin-gcp docker image) replaces the preceding gcr.io/stackdriver-trace-docker/zipkin-collector, but it is different. Primarily, the stackdriver module here is a server extension, not enabled by default. We should also note the oauth scope required for stackdriver quite loudly

https://www.googleapis.com/auth/trace.append oauth scope is required

translation from old to new:

kubectl run zipkin-collector --image=gcr.io/stackdriver-trace-docker/zipkin-collector --expose --port=9411
kubectl run zipkin-gcp --image=openzipkin/zipkin-gcp --env="STORAGE_TYPE=stackdriver" --expose --port=9411

Thanks for the advice @jsw

[jsw]

Also note that thankfully I did not need to specify GOOGLE_APPLICATION_CREDENTIALS or STACKDRIVER_PROJECT_ID, as expected as those should be inferred from GKE. Or maybe it's the case that I could configure those to send to a different Stackdriver account than the one associated with the current cluster.

I'd also expect STORAGE_TYPE=stackdriver to be a default given what I thought the primary use case for this image is, but based on your previous comments, I'm guessing that may not always be the case?

[codefromthecrypt]

I'd still hesitate on stackdriver being default.. Imagine when we have support for Google Pub/Sub collector. When that occurs it becomes more obvious why choosing a default could be problematic. For example, in zipkin-aws we have xray available, but off by default as well. There are SQS and Kinesis components there.

[jsw]

Makes sense. Perhaps the point of the gcr.io/stackdriver-trace-docker/zipkin-collector image is to set stackdriver as the storage? I'm not sure where the associated Dockerfile for that is.

[codefromthecrypt]

Makes sense. Perhaps the point of the gcr.io/stackdriver-trace- docker/zipkin-collector image to set stackdriver as the storage? I'm not sure where the associated Dockerfile for that is.

There's some history perhaps missing here. The image here is the successor to the "zipkin-collector" one. Formerly, it was a custom image so supported less features (ex Kafka). I suspect @mtwo or @saturnism or someone with access will update the canonical docs later.

[codefromthecrypt]

@saturnism @mtwo (or anyone else) do one of you know how to verify an account?

@zachdaniel mentioned this:
In kubernetes getting PERMISSION_DENIED: The caller does not have permission, but I checked and those oauth scopes are granted on the cluster.

I tried to verify what we have and I can't seem to figure it out.

Ex I googled around enough to figure out how to get gcloud installed

brew install caskroom/cask/google-cloud-sdk

I associated it with our account etc.

Then I found this doc to try to see permissions for the service account I use:

16:55 $ gcloud iam service-accounts describe stackdriver-zipkin@zipkin-demo.iam.gserviceaccount.com
displayName: stackdriver-zipkin
email: stackdriver-zipkin@zipkin-demo.iam.gserviceaccount.com
etag: BwVAn_6DdwA=
name: projects/zipkin-demo/serviceAccounts/stackdriver-zipkin@zipkin-demo.iam.gserviceaccount.com
oauth2ClientId: '103291061020214604728'
projectId: zipkin-demo
uniqueId: '103291061020214604728'
✔ ~/Downloads 
16:58 $ gcloud iam service-accounts get-iam-policy stackdriver-zipkin@zipkin-demo.iam.gserviceaccount.com
etag: ACAB

Basically I see nothing that I could use to help @zachdaniel troubleshoot his access, as I don't know how to even verify mine. Whatever we end up with should likely go into a troubleshooting section.

[mtwo]

Either Ray or myself can update the docs whenever you wish, just say the word!

I assume that @zachdaniel is using GKE? In that case, the project scope selection is automatic and there's no need to specify a service account or configure anything. However, the Trace API isn't enabled by default - I'm guessing it needs to be enabled and then the errors will go away.

[zachdaniel]

@mtwo that is correct, that was all I needed :)

[zachdaniel]

Actually I also needed to ensure the service account had write permissions to the Trace API as well, sorry.

[mtwo]

@adriancole should I update the GCP docs to point at the new container images? Happy to make the changes if everything is good to go

[codefromthecrypt]

Yes please do! Note the STORAGE_TYPE variable needs to be set to stackdriver

…

On Wed, 11 Apr 2018, 23:26 Morgan McLean, ***@***.***> wrote: @adriancole <https://github.com/adriancole> should I update the GCP docs to point at the new container images? Happy to make the changes if everything is good to go — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD617ZbiQY21tpDBRFnkZHdvjTrE4K5ks5tniCogaJpZM4TNamg> .

[mtwo]

Right now our docs cover how to get this working via container within GCP, container outside of GCP, or as a .jar. I'm going to keep the container-focused sections and will direct people who want .jar instructions to the documentation here on GitHub.

Sound okay?

[codefromthecrypt]

sgtm

[jsw]

@mtwo @adriancole Per Google's documentation

Zipkin tracers and the Stackdriver Trace instrumentation libraries can't append spans to the same traces, meaning that traces that are captured in one library won't contain spans for services instrumented in the other type of library... This is because Zipkin and Stackdriver Trace use different formats for propagating trace context between services.

Is there any work being done to resolve this limitation?