[semantic conventions] Rename os.type value DRAGONFLYBSD to DRAGONFLY

[mx-psi]

Changes

The os.type values seem inspired by the GOOS list (see here). All the values present both in the OpenTelemetry specification and the GOOS list match except for the one for Dragonfly BSD, which is named DRAGONFLYBSD on the spec and DRAGONFLY on the GOOS list.

This PR renames the constant to DRAGONFLY in the OpenTelemetry specification. Renaming the constant to DRAGONFLY makes implementing this convention on Go easier, removing the need to have a special case for this operating system family.

See summary of current arguments here

[arminru]

Please mention this breaking change in CHANGELOG.md. Thanks!

[mx-psi]

@arminru Done!

[arminru]

The current value is, however, consistent with the others that also end in BSD.
Do you know of any comparable libraries/lists other than the GOOS one? I could imagine this is just a Go peculiarity rather than the other way round.

[mx-psi]

Rust seems to also use dragonfly for its env::consts::OS constant, while ending the rest in BSD

[arminru]

In Java, for example, the os.name system property seems to return DragonFlyBSD for Dragonfly BSD (reference).

Seems like there's no right nor wrong here, either set of implementations will have to deal with it accordingly then.

[mx-psi]

I agree that there is no right or wrong answer (I apologize if the tone of my PR made it sound like there was).

That being said I think the current spec makes things much easier in general for Go than other languages: the rest of values match the runtime.GOOS one exactly while e.g. they differ for Rust (DARWIN vs. macos) and they need more work in Java (Java is more verbose and needs more elaborate handling of Windows and macOS). Given that this is the only thing stopping Go from not having special cases I think it would make sense to change it. It is also my impression that it's more likely that this kind of attributes get added at the Collector level (which is written in Go) than on the different instrumentation languages.

[rakyll]

FWIW, we chose https://github.com/open-telemetry/opentelemetry-specification/blob/main/semantic_conventions/resource/host.yaml#L24 independently from GOARCH. Not sure if we should optimize the enums for one language or the other. If we would like to be Go-friendly, we might want to address the host.arch enum values as well.

[arminru]

@mx-psi

I agree that there is no right or wrong answer (I apologize if the tone of my PR made it sound like there was).

No worries, I didn't have that impression. 🙂

It is also my impression that it's more likely that this kind of attributes get added at the Collector level (which is written in Go) than on the different instrumentation languages.

This makes sense if the collector is deployed in agent mode but not when used as gateway in standalone mode. If we define our goal to allow for easier Go support in these cases (not because we favor the Go SDK but because of the collector), I agree that we should do what @rakyll suggested.

That being said, I don't have an opinion here - either (the current value or what you suggested) should be fine.
@carlosalberto @bogdandrutu Given you already approved it I suppose you favor using the Go-like values, right?

[anuraaga]

I'd suggest sticking with the current name since "all the BSDs end with BSD" seems consistent and consistency is important in a spec I think. In the API we can expect more language considerations, often loosening restraints, for semantic conventions they're just data so should prioritize the data over any language conventions I think.

[anuraaga]

Also some somewhat academic it does seem like a reasonable safety measure vs someone creating dragonfly linux someday.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[mx-psi]

Below is the summary of current arguments as suggested by the contributing guide.

Summary of arguments

In favor of DRAGONFLY

1. This is the only value that differs from the GOOS list; it would be less surprising and marginally easier to implement in Go to have DRAGONFLY.
2. OpenTelemetry instrumented languages that have a query for OS family (Go and Rust) both use dragonfly as their value.

In favor of DRAGONFLYBSD

1. Other OpenTelemetry instrumented languages like Java use Dragonfly BSD when querying for the OS name (Java only reports the OS name, not the OS family).
2. DRAGONFLYBSD is consistent with the rest of BSD families (OPENBSD and NETBSD)
3. Makes it easier to extend the spec in case of a 'Dragonfly Linux' OS family.

[Oberon00]

I think we should stay with DRAGONFLYBSD. If we had started with DRAGONFLY, I think it is likely a PR would have come in to change to DRAGONFLYBSD. It seems mostly arbitrary to me which of these names to use, so I vote for not changing it.

[mx-psi]

Hi all, given the lack of consensus and the arguments against this change presented above I am closing the PR. Thanks all for the comments!