LGTM. The primary / secondary bit doesn't really make sense, but if it is what the back-end team wants, I can acquiesce.

Added the "don't merge" label. I'll hold off on merging until @nathanielmanistaatgoogle and/or @murgatroid99 can weigh in.

Luhguhtum, but I'd also appreciate hearing from @murgatroid99.

I don't actually know what the primary vs secondary user agents are supposed to be, semantically. Node appends its own user agent string to the provided primary user agent string, so I just assumed that the calling library was expected to provide its own primary user agent string.

I'm going to merge then since the consensus from the two gRPC maintainers is like 75% of a thumbs up: "do it" and "not sure"

I'd say this should probably be documented somewhere though?

@dhermes: Aww, phooey, I just had a conversation on your behalf with @ctiller.

A few takeaways:

• If an application attempts to set user-agent as though it were an ordinary piece of metadata, the core will eat the supplied value and not put it on the wire, so using (a) channel argument(s) is the only way to alter the user-agent sent to the server along with your RPCs. So the whole conversation we had the other day about which means was preferred apparently could have been resolved by the knowledge that only one means is effective.
• Culturally, the "most important" or "most specific" information in the user-agent string goes first, so I erred in guiding you to pass your application information as a secondary, rather than primary, user agent channel arg. My apologies; today I learned.

I've filed grpc.github.io issue 380 to track improving our documentation for user-agent application best practices.

It's an easy fix, I'll send the PR to fix post-haste. Thanks for looking into it.