Expose track2 module name and version for tracing purpose

[MartinForReal]

Feature Request

Expose track2 module name and version for tracing purpose

We need to add module info into trace context. But Module name and module version are not exposed to public.

e.g.

https://github.com/Azure/azure-sdk-for-go/blob/fb9b7a23d7c37f804a0a9850356b1bd1e5af7a83/sdk/resourcemanager/compute/armcompute/constants.go#L12

Do you think if it is feasible to expose those information? Thanks!

[lirenhe]

@jhendrixMSFT, could you comment on this ask? Is it by design that we don't expose name & version?

[jhendrixMSFT]

The only reason we never exported it in the past was because we didn't think it would be useful. If there's a real need for these to be exported, we can do that.

[RickWinter]

We should export if we can't find a suitable way to query this at runtime.

[RickWinter]

@JeffreyRichter Any concerns with exposing these two fields for all modules?

[JeffreyRichter]

Doesn't our tracing work as-is? Why do these variables need to be exposed for tracing (assuming it already works)? Exposing them is not a big deal but I'd still prefer they NOT be exposed. So, I'd like to understand better what scenario requires them to be exposed.

[MartinForReal]

SDK is a dependency of our library. I need to add this info into log and trace. But if I enable logging in sdk. It will print too many entries. I also need to customize user agent header in request. The length limit is too short. I can't add additional version info into UA header.

[JeffreyRichter]

I don't quite understand. You are writing a package that depends on it Go sdk and you want to grab our module and version info and use it in your own logging which is not related to the logging infrastructure we have in our sdk?

If your app depended on any other module which did not have constants for the module name and version embedded in it, then what would you do? Most modules do not have these constants and I don't think that just because we do we need to expose them.

I'm hesitant to expose them because we don't guarantee that we'll keep them in future versions of that their content will keep the same format.

[MartinForReal]

Sorry for my poor written English.

You are writing a package that depends on it Go sdk and you want to grab our module and version info and use it in your own logging which is not related to the logging infrastructure we have in our sdk?

Yes. I will print this in our own logger.

If your app depended on any other module which did not have constants for the module name and version embedded in it, then what would you do? Most modules do not have these constants and I don't think that just because we do we need to expose them.

Arm requests will be generated by sdk and apiVersion will be overwritten in our lib. So, it is hard to tell which version of sdk is in use. We do need module version info in our log so that we can know that if the dependency has been changed.

I'm hesitant to expose them because we don't guarantee that we'll keep them in future versions of that their content will keep the same format.

As long as I can tell which version the lib depends on, That's ok.

[JeffreyRichter]

You can tell because you build your package with the dependent module versions in your go.mod file.

[MartinForReal]

But I can't print it in logger..

[JeffreyRichter]

I'm not following this enough. I think you know what version of the module you are taking a dependency on when you build your package and therefore, I think you can hard-code this version in your logging code. You do not REQUIRE that we make these constants public to accomplish your goal. While making these constants public might be convenient for you, it is inconvenient for us as we would now have to document them and maintain them in perpetuity.

If I'm not following the problem you're trying to solve, then you have to really explain it to me in detail. Specifically, I need to know the various components that are part of the problem and which entity (the Go SDK, an immediate consumer of the SDK, a more distant consumer of the SDK, etc.) owns which component. I also need to understand how the components integrate with each other.

[chlowell]

Go builds dependency info into executables that you can parse with runtime/debug. For example:

import "runtime/debug"

if bi, ok := debug.ReadBuildInfo(); ok {
	for _, dep := range bi.Deps {
		fmt.Printf("%s %s\n", dep.Path, dep.Version)
	}
}

Output

github.com/Azure/azure-sdk-for-go/sdk/azcore v1.16.0
github.com/Azure/azure-sdk-for-go/sdk/azidentity v1.8.0
...

Does that work for you?

[github-actions[bot]]

Hi @MartinForReal. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

[JeffreyRichter]

@chlowell, this is cool and I had no idea about it! Great suggestion!

[MartinForReal]

Thanks!

[chlowell]

You're welcome!