[iptables] Regenerate test expectations

[aleksmaus]

Proposed commit message

Regenerate test expectations that are failing now.
Not even sure if we suppose to release the version of the package for this kind of thing. Will place the PR and will see what happens.

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.
• I have verified that Kibana version constraints are current according to guidelines.

Related issues

• Closes [Stack 8.16.0-SNAPSHOT] [iptables] Failing test daily: system test: journald in iptables.log #10757

[elasticmachine]

Pinging @elastic/sec-deployment-and-devices (Team:Security-Deployment and Devices)

[aleksmaus]

Tested on few latest versions of the stack, that's what we get for this IP resolution now

While the test expectation was

-                "geo": {
-                    "continent_name": "Asia",
-                    "country_iso_code": "BT",
-                    "country_name": "Bhutan",
-                    "location": {
-                        "lat": 27.5,
-                        "lon": 90.5

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: b4a3dd0

Failed CI Steps

• Check integrations iptables

History

cc @aleksmaus

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[aleksmaus]

Hmm, it's odd, it fails in CI now with these regenerated files, while it passes against the snapshots of 8.14, 8.15, 8.16 that you get with the cloud deployment.

test case failed: Expected results are different from actual ones: --- want
+++ got
@@ -80,9 +80,15 @@
             },
             "source": {
                 "as": {
-                    "number": 35908,
-                    "organization": {
-                        "name": "VPLSNET"
+                    "number": 35908
+                },
+                "geo": {
+                    "continent_name": "Asia",
+                    "country_iso_code": "BT",
+                    "country_name": "Bhutan",
+                    "location": {
+                        "lat": 27.5,
+                        "lon": 90.5

@andrewkroh @taylor-swanson How do you guys go about reproducing the exact environment for geoip processors, so you can get the proper test expectations generated that line up?

[andrewkroh]

elastic-package is supposed to setup ES with a custom DB to ensure reproducibility. Did something change where this DB is not be loaded properly?

https://github.com/elastic/elastic-package/blob/main/docs/howto/ingest_geoip.md

---

If the change is only affecting test files (no user facing changes) then we shouldn't need to make a release, so could omit the manifest/changelog edits.

[andrewkroh]

Suggested change

	link: https://github.com/elastic/integrations/pull/8888888
	link: https://github.com/elastic/integrations/pull/10871

[aleksmaus]

elastic-package is supposed to setup ES with a custom DB to ensure reproducibility. Did something change where this DB is not be loaded properly?

Ahh, that's good to know. That explains why the different results, then. Don't see the same errors with the local tests runs. Will close this PR then and dig more for repro locally.