functionaltests: Add 7x to 8x standalone to managed test

[ericywl]

Motivation/summary

Add tests for 7.x -> 8.x:

• 7.x standalone -> 8.x standalone -> 8.x managed
• 7.x standalone -> 7.x managed -> 8.x managed

Note: Requires #16537 to be merged first.

How to test these changes

Run functionaltests with this branch: https://github.com/elastic/apm-server/actions/runs/14436234632.

[mergify]

This pull request does not have a backport label. Could you fix it @ericywl? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-7.17 is the label to automatically backport to the 7.17 branch.
• backport-8./d is the label to automatically backport to the 8./d branch. /d is the digit.
• backport-9./d is the label to automatically backport to the 9./d branch. /d is the digit.
• backport-8.x is the label to automatically backport to the 8.x branch.
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.

[mergify]

This pull request is now in conflicts. Could you fix it @ericywl? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b functionaltests-7to8 upstream/functionaltests-7to8
git merge upstream/functionaltests-add-v7-support
git push upstream functionaltests-7to8

[mergify]

This pull request is now in conflicts. Could you fix it @ericywl? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b functionaltests-7to8 upstream/functionaltests-7to8
git merge upstream/main
git push upstream functionaltests-7to8

[endorama]

I see that the tests are still failing for 8.x, maybe it needs to ignore 7.x data stream as well?

As the above issue needs to be addressed, I'd suggest to extract some small refactoring into separate PRs to focus on the 7 to 8 test that is already quite sizeable.

The code for the 7 to 8 test looks good to me, so if tests are green we can move forward merging this :)

[mergify]

This pull request is now in conflicts. Could you fix it @ericywl? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b functionaltests-7to8 upstream/functionaltests-7to8
git merge upstream/functionaltests-minor-refactor
git push upstream functionaltests-7to8

[mergify]

This pull request is now in conflicts. Could you fix it @ericywl? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b functionaltests-7to8 upstream/functionaltests-7to8
git merge upstream/functionaltests-minor-refactor
git push upstream functionaltests-7to8

[mergify]

This pull request is now in conflicts. Could you fix it @ericywl? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b functionaltests-7to8 upstream/functionaltests-7to8
git merge upstream/main
git push upstream functionaltests-7to8

[endorama]

The last run had 2 failures

A failure in TestUpgrade_7_17_to_8_x_Snapshot_Standalone_to_Managed/UpgradeFirst, this is a terraform error, see https://github.com/elastic/apm-server/actions/runs/14399137531/job/40380766371#step:7:163

A failure in TestUpgrade_9_0_to_9_1_Snapshot both default and reroute, related to these errors:

"[
{2025-04-11 08:44:25.414 +0000 UTC refresh cache error: refresh cache elasticsearch returned status 403 agentcfg}
{2025-04-11 08:44:25.414 +0000 UTC stopping refresh cache background job: elasticsearch config is invalid agentcfg}
]"

Inspecting the logs it seems the error "recovers" to become a 503. I'm thinking this may be due to the fleet server bootstrapping the apm server. I'm not 100% confident this is the right choice but it feels safe to ignore (probably worth checking with the Fleet team though).

[endorama]

minor comments for the PR but there are test failures to address.

[endorama]

The next step here would be to refactor all data stream check to follow a similar pattern: instead of a list checked in a order sensitive manner, use a map where the checker can match keys to data streams and then use the specific check value for assertions. Not to be addressed in this PR.

[endorama]

Why are we also checking non standalone DS here?

[ericywl]

Not sure what you mean by this? When we ingest in managed mode, we check the data streams.

[endorama]

My confusion stemmed from using legacy here. In this case this step is used for 7.x tests in both standalone and managed modes, so it's correct that is checking data streams. Thanks for clarifying that.

[ericywl]

Updated and ran new passing run: https://github.com/elastic/apm-server/actions/runs/14436234632.