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.

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

Enhance RabbitMQ test to use real data and test with 3.6 #10667

Merged
merged 4 commits into from
Jul 5, 2019

Conversation

sayden
Copy link
Contributor

@sayden sayden commented Feb 11, 2019

"Fixes" this issue #10014 by:

  • Using data returned from an instance
  • The instance is version 3.6

Currently, RabbitMQ module uses local data stored here to mock responses from the server during tests. This also generates file data.json which is not very nice.

AFAIK, the "missing data" reported in the issue are some fields that aren't parsed by design.

Current PR uses exchange Metricset to actively send messages and consume them from a RabbitMQ instance, to later produce a real data.json file.

My main concern about this PR are:

  • Now we need a third party library (https://github.com/streadway/amqp) althought as it's only used on tests, it's not shipped with the release binary.
  • "Missing fields" reported in the issue and the discuss forum aren't being parsed yet. So, that problem isn't solved anyways.

Comments welcome :)

EDIT:
Finally I added some version specific tests using the new framework and updated to_error V2_ interface_. I couldn't update Metricset node to use the new testing framework because it needs 2 HTTP calls to fetch metrics (and the testing framework it only with single HTTP calls at the moment)

@sayden sayden added in progress Pull request is currently in progress. Metricbeat Metricbeat Team:Integrations Label for the Integrations team labels Feb 11, 2019
@sayden sayden self-assigned this Feb 11, 2019
@sayden sayden requested a review from ruflin February 11, 2019 11:45
@sayden sayden requested a review from a team as a code owner February 11, 2019 11:45
@sayden sayden requested a review from jsoriano February 11, 2019 11:45
Copy link
Member

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

If we have new dependencies we need to add them with govendor to the repo as otherwise CI does not find them.

It seems the main objective of this PR is to generate a nicer data.json. For this to happen I wonder if we should better go the approach suggested here? #10648

@@ -61,16 +65,27 @@ func TestFetchEventContents(t *testing.T) {
}

func TestData(t *testing.T) {
server := mtest.Server(t, mtest.DefaultServerConfig)
defer server.Close()
t.Skip("Skipping `data.json` generation test")
Copy link
Member

Choose a reason for hiding this comment

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

There is a check in the WriteEventsReporterV2 for the -data flag. If we want to skip it already here, we should do it based on the -data flag instead of always skipping it.

@sayden
Copy link
Contributor Author

sayden commented Mar 13, 2019

I'll take advantage of the new testing interface now on this PR

@sayden sayden force-pushed the bugfix/mb/rabbitmq-fix-test branch from 43a8c2e to 30e39b0 Compare April 12, 2019 11:34
@sayden sayden requested a review from a team as a code owner April 12, 2019 11:34
"name": "host.example.com"
"@timestamp": "2019-03-01T08:05:34.853Z",
"error": {
"message": "HTTP error 404 in : 404 Not Found"
Copy link
Member

Choose a reason for hiding this comment

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

Error document as example? :-)

[
{
"error": {
"message": "HTTP error 404 in : 404 Not Found"
Copy link
Member

Choose a reason for hiding this comment

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

Not sure if this is expected?

}
}

func TestFetch(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

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

Should we keep this around even though it's skipped. This is as a reminder that we should fix it.

@sayden
Copy link
Contributor Author

sayden commented May 6, 2019

jenkins, test this please

@sayden sayden force-pushed the bugfix/mb/rabbitmq-fix-test branch from 5bc7e22 to 718b00a Compare May 6, 2019 21:11
@sayden sayden added review [zube]: In Review and removed in progress Pull request is currently in progress. [zube]: In Progress labels May 6, 2019
@sayden
Copy link
Contributor Author

sayden commented May 6, 2019

Updated the title to show the current state.

Copy link
Member

@jsoriano jsoriano left a comment

Choose a reason for hiding this comment

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

Thanks for working on this.
Please update the compatibility notes mentioning that it should work with 3.6 too.
It'd be also good if we could test the node metricset with multiple versions, but not sure of the best way of doing it.

@sayden
Copy link
Contributor Author

sayden commented May 29, 2019

I passed this PR to ready again to wait until #12228 is in. Then I'll merge conflict and merge.

@sayden sayden added blocked and removed review labels May 29, 2019
@sayden sayden removed the blocked label Jun 5, 2019
@sayden sayden force-pushed the bugfix/mb/rabbitmq-fix-test branch from 6327d63 to 27a0b1f Compare June 7, 2019 10:52
@sayden sayden added the in progress Pull request is currently in progress. label Jun 7, 2019
@sayden
Copy link
Contributor Author

sayden commented Jun 7, 2019

Ok, conflicts solved :) Ready for review / merging

EDIT: Ups, I forgot to update the compatibility docs. Doing it now.

@sayden sayden added review and removed in progress Pull request is currently in progress. labels Jun 7, 2019
@@ -14,7 +14,7 @@ If `management.path_prefix` is set in RabbitMQ configuration, `management_path_p
[float]
=== Compatibility

The rabbitmq module is tested with RabbitMQ 3.7.4, and it should be compatible
The rabbitmq module is fully tested with RabbitMQ 3.7.4 and partially tested with 3.6.0, 3.6.5 and 3.7.14 and it should be compatible
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to be more specific on "partially tested" here?

Copy link
Contributor

@kaiyan-sheng kaiyan-sheng left a comment

Choose a reason for hiding this comment

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

I'm just curious if we should be more specific on "partially tested". Other than that it looks good to me!

@ruflin
Copy link
Member

ruflin commented Jun 11, 2019

+1 on what @kaiyan-sheng says related to partial testing. Either we are confident it works and is supported or we should not mention it. Otherwise it's consuming for the customer on what to expect and also from a support perspective, if we support it or not.

@sayden
Copy link
Contributor Author

sayden commented Jul 5, 2019

Text have been changed to reflect what's exactly tested with which version

@sayden
Copy link
Contributor Author

sayden commented Jul 5, 2019

jenkins, test this please

@sayden sayden merged commit 1138587 into elastic:master Jul 5, 2019
@sayden sayden changed the title Enhance RabbitMQ test to use real data and test with 3.6 Enhance RabbitMQ tests with more versions other than 3.6 Jul 5, 2019
@zube zube bot changed the title Enhance RabbitMQ tests with more versions other than 3.6 Enhance RabbitMQ test to use real data and test with 3.6 Jul 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Metricbeat Metricbeat review Team:Integrations Label for the Integrations team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants