MongoDB: Enable ECS dependency

[mtojek]

What does this PR do?

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
  - [ ] If I'm introducing a new feature, I have modified the Kibana version constraint in my package's manifest.yml file to point to the latest Elastic stack release (e.g. ^7.13.0).

How to test this PR locally

CI will verify if the integration works correctly.

Issues

• [Discuss] Avoiding duplication of ECS field definitions package-spec#63

[mtojek]

Fun fact: isn't service.address defined in ECS schema?

[jsoriano]

Interesting, then maybe a different field should be used here? Maybe server.address.

[mtojek]

I replied to the comment below:

I'm not sure about consistency with Beats in this case, but it seems like a good candidate to the ECS repository. Should I open an issue in the ECS repo?

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Pull request #1171 updated

• Start Time: 2021-06-23T10:11:17.117+0000

• Duration: 16 min 48 sec

• Commit: feae2ce

Test stats 🧪

Test	Results
Failed	0
Passed	29
Skipped	0
Total	29

Trends 🧪

[jsoriano]

I haven't promoted 0.4.0 yet, so this can go to this version.

[mtojek]

Well, revision 0.4.0 has been already released to snapshot, so this version is "burnt". I updated the changelog to 0.4.1-next to prevent releasing this change immediately after merge.

In general the package is copied to the package-storage whenever an unreleased version is detected in package manifest.

[jsoriano]

Oh ok, I didn't know about this, I thought they needed to be explicitly promoted.

Then we have the problem of not knowing what is released as 0.4.0 in snapshot, as I added the two enhancements in two different PRs.

[mtojek]

It seems that 0.4.0 contains only: https://github.com/elastic/package-storage/blob/snapshot/packages/mongodb/0.4.0/changelog.yml#L4

Would you like me to promote this PR as 0.5.0, so it will include also the other PR?

[mtojek]

We agreed offline to go with 0.5.0

[jsoriano]

Interesting, then maybe a different field should be used here? Maybe server.address.

[mtojek]

Interesting, then maybe a different field should be used here? Maybe server.address.

I'm not sure about consistency with Beats in this case, but it seems like a good candidate to the ECS repository. Should I open an issue in the ECS repo?

[jsoriano]

I'm not sure about consistency with Beats in this case, but it seems like a good candidate to the ECS repository. Should I open an issue in the ECS repo?

Yes, I think we should clarify this.

For example in this issue elastic/beats#8941 it seems to be assumed that this is an ECS field, but in beats it is still defined as a common field in Metricbeat. And I see that many other integrations have it in ecs.yml too.

In other beats server.address is used instead, so I am leaned to think that this is more an issue in Metricbeat (and the data streams that depend on it).

I also understand that service.address and server.address can be redundant, so service.address may not fit in ECS.

[jsoriano]

LGTM, no need to solve the service.address mistery here.