Move Fields from pacakge libbeat/common to libbeat/mapping

[kvch]

The structures Field and Fields are moved from common to the package mapping.
This is a step towards moving things from the abused package common.
I would like to move fields and other asset related functionality to this package in the future.

[ruflin]

+1 on moving field out, but I don't think there is a direct relation between asset and field. Field is not even used in the asset package as far as I remember. I would like to keep the asset package reserved for the registry and asset generation. What about moving field to it's own package, for example common/field?

[urso]

Maybe time to define a project name for fields.yml.

I'm no fan of the common package alltogether. Same goes for sub-packages named after common/<x>.

How about renaming the Fields type to Document, or Schema while we are at it? Such that we have field.Schema or field.Document, assuming we named the package/project field.

Alternative package names:

• fields
• schema
• mapping
• diag(ramming)
• (evt/event-)model

[kvch]

@ruflin I have moved the collection of fields be it in the form of an encoded string or yaml in a draft PR where I implement supporting additional fields.yml files. My reasoning was that every data/resource is an asset which is required to generate a template. As Field/Fields is a data structure required for that process, it seems like the perfect place for this. I also tried to avoid a Golang anti-pattern of creating many small packages. But I am fine with keeping this small. I think we need to define the term asset to make a proper decision.

@urso Great idea! I like the name Schema as these fields define the composition of a template and provide additional metadata (e.g. documentation).Maybe mapping.Schema would be the most appropriate as these fields supposed to describe a mapping of an index. Hm... Sounds a bit weird. Or mapping.Document as it stores a mapping of a document? I need a bit more time to think.

[ruflin]

The asset package is not only intended to package fields but the goal was that it can handle anything we want as asset in the golang code. This could also be a config file or an ingest pipeline or other things. That is why I would prefer not to have it in this package.

If I understand it correctly, this package change is needed for a follow up PR? To not block this, I suggest we move it for now to its own package and follow up with a renaming discussion. For schema keep in mind, we have an other schema package ...

[kvch]

@ruflin @urso I moved Field and Fields from asset to mapping. I think this package name is the most suitable because these fields describe an ES mapping.

[kvch]

Failing tests are unrelated to this change.

[ruflin]

LGTM, don't have strong opinions about the naming of the package.

@elastic/apm-server This change might affect apm-server too?

[ruflin]

@kvch Any idea what happened with the windows tests in https://beats-ci.elastic.co/job/elastic+beats+pull-request+multijob-windows/5947/beat=filebeat,label=windows/ Never saw them failing at once all together. Will rerun CI to be sure it's not related.

[ruflin]

jenkins, test this

[kvch]

@ruflin i have reopened the tickets of those flaky tests