Refocus of os types #1257

[thompson-tomo]

Closes #1257

Changes

Deprecate all existing os types and instead use the field to describe the type of the OS ie windows or Unix. The existing types should be the os.name and/or unix.kernel.name with the later handled via #2641

Note: if the PR is touching an area that is not listed in the existing areas, or the area does not have sufficient domain experts coverage, the PR might be tagged as experts needed and move slowly until experts are identified.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[joaopgrassi]

Blocking as to this is not simply adding more OS types. It is changing the behavior of the attribute entirely.

The links you added to the issue description, for example from ECS https://www.elastic.co/docs/reference/ecs/ecs-os#field-os-type also have a os.type which is pretty much the same as what we have today.

[thompson-tomo]

@joaopgrassi can you review and unblock as implementation is following what was discussed in the semconv.

Unblocking, but we still need to get the system semconv group onboard with this change.

[braydonk]

zos is a real unique operating system type, I don't think we should be removing it.

[thompson-tomo]

From my research it is a Unix os.

[braydonk]

I'm not sold on putting all unixes together. I think there is still value in separating linux, darwin, and bsd at least. While it's true they are all unix-likes, they are unique enough and are treated differently enough in the minds of most users to deserve their own attributes. I think moving all the *bsd attributes to os.name is good so we can keep that, but I think this should restore linux, darwin, and bsd.

[thompson-tomo]

So looking at implementations and language api's the common functionality is being able to determine the OS type which is what is being expressed by this attribute. You can then look at the os.name &/or os.family to get that specific info, you are after.

[mx-psi]

I think the previous state is more useful than just a 'unix' value. It may be too specific today, but I don't think we should jump to the other extreme.

[thompson-tomo]

You have os.name/os.type to be more specific. And in fact this is what I was told to implement in the sem conv meeting as I had originally extended type to include alot of other common os but that was not wanted due to it becoming a never ending list. At the same time we also needing to migrate the other properties from ecs, hence the request was to focus type on the minimal items and provide the other properties.

Also this approach here would nicely complement the solution I have proposed in #66 as if type is Unix, then you can also provide details of the Unix.kernel which could be Linux, Darwin etc.

[thompson-tomo]

To further support the simplification proposed here #2641 has now been created to express the kernel type ie linux, Darwin.

That pr provides another way to maintain the same granularity while introducing consistent attribute usage and further migration of ecs.

[mx-psi]

I think the previous state is more useful than just a 'unix' value. It may be too specific today, but I don't think we should jump to the other extreme.