fix(php): Add awslinux recipe to address al2023 failures #1256
Conversation
| NR_INSTALL_USE_CP_NOT_LN=1 NR_INSTALL_SILENT=true NR_INSTALL_KEY="{{.NEW_RELIC_LICENSE_KEY}}" ./newrelic-install install | ||
| popd > /dev/null | ||
|
|
||
| vars: |
There was a problem hiding this comment.
This vars block looks like a unused variable that someone missed to remove during some cleanup activity that was done earlier in these recipes. So you can remove this Vars. Recipe is fetching the latest version of the php agent using
AGENT_VERSION="$(curl -s "$RELEASE_URL" | grep --only-match "$VERSION_REGEX" | head -n1)"
Tested from my end(as you can refer to the screenshot) that even though we define the agent_version as older one in vars it is pulling the latest agent version
There was a problem hiding this comment.
The var block was initially added to prevent errors when an issue occurred finding the most current agent version (i.e., if the curl command failed for any reason) so that agent version always has at least something.
But I see the recipe now handles that here, so I have removed it from this recipe.
However, this recipe is based off the current pattern of redhat to ensure stability as that recipe has been used/tested for a while, and anything further is beyond the scope of this PR which is only to address the issues occurring with the amazon linux versions that our compatibility page specifies we don't support rpm installs on.
|
Also as we are adding a new recipe specifically for Amazon linux 2023 its worth adding a new test case for PHP installation in amazon linux 2023 So that our test framework is also consistent with the new recipe added. |
The recipe isn't specific for AWS linux 2023, but will apply to all AWS Linux versions that aren't compatible with our rpm package manager and that we only support tarball installations for. Because of the divergence between regular rhel and amazon rhel-based linuxes, it made sense to split the recipes to better deal with any different handling in the future. AL2023 is just the first, but it's likely subsequent amazon linuxes will also use this recipe. @vagrawal-newrelic , regarding adding a test case, we are unfamiliar with your testing infrastructure, but it's likely you can add it in a similar manner to how you added the amazon linux 2 / arm64 test case when this recipe was added. |
This recipe will install on al2023 in a way that complies with our stated compatibilities.
When running the Virtuoso Recipe query on status=FAILED PHP agent installs, most of them stem from the fact that yum is used to install the agent on Amazon Linux 2023, even though yum install method is not supported on Amazon Linux 2023 - https://docs.newrelic.com/docs/apm/agents/php-agent/getting-started/php-agent-compatibility-requirements/#operating-systems.
Amazon Linux 2023 (AL2023) is not directly based on a specific RHEL version. While Amazon Linux 2 was based on RHEL 7, AL2023 uses a combination of Fedora Linux and CentOS Stream as its upstream sources. Specifically, the initial release incorporates parts of Fedora 34, 35, 36, and CentOS 9 Stream and as such is not compatible with our rpm package.
More info here: https://support.newrelic.com/s/hubtopic/aAX8W000000L5iEWAS/php-failed-to-install-new-relic-in-my-amazon-linux-2023-server
Additionally, AL2023 uses DNF (the yum call is just a wrapper to DNF) which is "mostly" similar, but again, not compatible with our yum install method and AL2023 is specifically mentioned as a tarball only install: https://docs.newrelic.com/docs/apm/agents/php-agent/getting-started/php-agent-compatibility-requirements/#operating-systems.
The yum task was only included in the redhat.yml recipe so customers would have the option to later user the rpm manager for agent updates.
As such the call to yum is unnecessary for AL2023 installs since only tarball installation is supported.
The query for PHP agent installs with al2023 now shows the agent getting successfully installed with the new recipe.
