jaeger_remote needs clarity

[marcalff]

The yaml node for jaeger_remote currently has the following schema:

• an optional endpoint property
• an optional interval property
• an optional initial_sampler property

The endpoint should probably be required.

The interval should be required, or a default value should be defined. The unit for this value should be defined as well.

The initial_sampler should be required, or a default behavior should be defined (always_off, always_on ?).

This is blocking for the 1.0.0 release, as any changes here (optional property that becomes mandatory) will be a breaking change.

Blocking for #161

[marcalff]

Also, jaeger_remote is not covered in examples.

[jack-berg]

The endpoint should probably be required.

Maybe.. The spec isn't clear on this. Relevant spec language is available in environment variable doc and trace sdk doc. Neither talks about whether properties are required or optional, and if optional what their default values are. I think its reasonable to think that endpoint should be required, but counter points include:

• Endpoint is discussed in the same manner (no mention of required vs. optional or default values) as the other properties and it doesn't seem like pollingIntervalMs or initialSamplingRate should be required.
• We have precedent for other components which have an optional endpoint property including otlp exporter, zipkin exporter.

The interval should be required, or a default value should be defined. The unit for this value should be defined as well.
The initial_sampler should be required, or a default behavior should be defined (always_off, always_on ?).
Also, jaeger_remote is not covered in examples.

Yup good call. These are all related to jaeger_remote not being covered in the examples, which is probably the cause of an oversight in type_descriptions.yaml.

[marcalff]

We need to do something about jaeger_remote.

Possible ways to resolve this:

• provide clarity as required. Not likely given that the spec itself misses details.
• mark it experimental
• remove it entirely from the 1.0.0 spec, to be added back if/when it is clarified

I think we should make it experimental for now.

@jack-berg @codeboten any preference ?

[jack-berg]

I think we should make it experimental for now.

This seems appropriate. Can come back and stabilize it once there is clarity in the spec but no need to guess and risk making the wrong assumption, and no need to hold up stability while awaiting clarity.