Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wants to merge 3 commits into from
Closed

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
eebb6e4
Rename DRAGONFLYBSD to DRAGONFLY
mx-psi Mar 23, 2021
69853f5
Add changelog note
mx-psi Mar 23, 2021
fb9addb
Merge branch 'main' into mx-psi/dragonfly-dragonflybsd
mx-psi Apr 2, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,7 @@ release.
- Add details for filling semantic conventions for AWS Lambda ([#1442](https://github.com/open-telemetry/opentelemetry-specification/pull/1442))
- Update semantic conventions to distinguish between int and double ([#1550](https://github.com/open-telemetry/opentelemetry-specification/pull/1550))
- Add semantic convention for AWS ECS task revision ([#1581](https://github.com/open-telemetry/opentelemetry-specification/pull/1581))
- Rename `DRAGONFLYBSD` to `DRAGONFLY` to be consistent with Golang's GOOS values ([#1572](https://github.com/open-telemetry/opentelemetry-specification/pull/1572))

### Compatibility

Expand Down
4 changes: 2 additions & 2 deletions semantic_conventions/resource/os.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,8 +29,8 @@ groups:
- id: OPENBSD
value: 'OPENBSD'
brief: "OpenBSD"
- id: DRAGONFLYBSD
value: 'DRAGONFLYBSD'
- id: DRAGONFLY
value: 'DRAGONFLY'
brief: "DragonFly BSD"
- id: HPUX
value: 'HPUX'
Expand Down
2 changes: 1 addition & 1 deletion specification/resource/semantic_conventions/os.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ In case of virtualized environments, this is the operating system as it is obser
| `FREEBSD` | FreeBSD |
| `NETBSD` | NetBSD |
| `OPENBSD` | OpenBSD |
| `DRAGONFLYBSD` | DragonFly BSD |
| `DRAGONFLY` | DragonFly BSD |
Comment on lines 24 to +27
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@mx-psi mx-psi Mar 23, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

| `HPUX` | HP-UX (Hewlett Packard Unix) |
| `AIX` | AIX (Advanced Interactive eXecutive) |
| `SOLARIS` | Oracle Solaris |
Expand Down