add resource + attributes

[codeboten]

Currently the only attribute that's required is service.name.

[tsloughter]

I don't think service.name should be required. It isn't required to set OTEL_SERVICE_NAME.

[codeboten]

I don't think service.name should be required. It isn't required to set OTEL_SERVICE_NAME.

Fair, i figured since SDKs override it anyways, it would be handy to have it required, but i can remove it as well

[pirgeo]

Is there a way of setting it as recommended? Also: would the file-based config always be the "lowest" priority and overwritten when the value is set somewhere else?

[tsloughter]

SDK's override it?

My initial thought when seeing this was an issue with Erlang because it is able to automatically set it for the user, but if the user sets it in the config this would be taken over the detected service name.

[pirgeo]

SDK's override it?

I don't think they should do that. I am trying to understand what the priority is.

My understanding is:

• Use the service name provided in code (EDIT: on SDK setup, that is what I meant above)
• If that isn't set, use the service name provided in the config file
• If that isn't set, use the OTEL_SERVICE_NAME env var
• If that isn't set, use the value provided by a resource detector
• If none of these are set, use unknown_service

Am I missing something? Is the order okay?

[jack-berg]

@pirgeo in the OTEP we discussed whether file configuration should include layering with other sources of config like environment variables, and decided no. See this comment. Working on codifying this in the specification with this line:

The SDK components MUST strictly reflect the Configuration and ignore the environment variable configuration scheme.

[codeboten]

SDK's override it?

@tsloughter I mispoke, I meant that the SDKs will default to unknown_service if no service name is set.

[pirgeo]

@jack-berg Thanks for the clarification. It seems I need to read the OTEP / discussion around it a bit more carefully! 😄

[codeboten]

Moved the discussion around requiring service.name into its own issue, PTAL

[MikeGoldsmith]

Pending further discussion of service.name in #11 - this looks good to me.