If one gpg check is working, upgrade should continue

[pierrehilbert]

What does this PR do?

This PR removes the break in the verify loop to continue in case one verify is successful.

Why is it important?

This change will allow upgrade to continue if remote gpg key is unreachable.

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Author's Checklist

• [ ]

How to test this PR locally

Related issues

Closes #3368

Use cases

Screenshots

Logs

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[mergify]

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

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[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

• Start Time: 2023-09-20T14:00:06.567+0000

• Duration: 26 min 47 sec

Test stats 🧪

Test	Results
Failed	0
Passed	6301
Skipped	59
Total	6360

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages.

• run integration tests : Run the Elastic Agent Integration tests.

• run end-to-end tests : Generate the packages and run the E2E Tests.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	98.78% (81/82)	👍
Files	66.327% (195/294)	👍
Classes	65.751% (359/546)	👍
Methods	52.686% (1128/2141)	👎 -0.074
Lines	38.2% (12800/33508)	👎 -0.031
Conditionals	100.0% (0/0)	💚

[michalpristas]

it's not fixing the issue but we can push this in and have at least one strategy with verifiers to reduce number of failures

[cmacknz]

This isn't really the standard way to do this, if the operation succeeded err should be nil.

Now that I've seen this approach, I think a better solution would be to have the composed verifier log each verifier that failed but return a nil error if at least one of them succeeded.

If you wanted to keep doing it this way, you would want to return the details of what happened as a separate structure so it can be logged at this level but I think it will be much simpler to handle the logging directly in this block of the composed verifier

Something like the following should handle most of this, it already builds up a joined error of each failure and only returns it if all of the verifiers fail. We just need to add a log statement and a Name method to the verifier interface so you can log which one failed.

--- a/internal/pkg/agent/application/upgrade/artifact/download/composed/verifier.go
+++ b/internal/pkg/agent/application/upgrade/artifact/download/composed/verifier.go
@@ -5,7 +5,7 @@
 package composed

 import (
-       "github.com/hashicorp/go-multierror"
+       "errors"

        "github.com/elastic/elastic-agent/internal/pkg/agent/application/upgrade/artifact"
        "github.com/elastic/elastic-agent/internal/pkg/agent/application/upgrade/artifact/download"
@@ -43,11 +43,10 @@ func (e *Verifier) Verify(a artifact.Artifact, version string, skipDefaultPgp bo
                        return nil
                }

-               err = multierror.Append(err, e)
+               err = errors.Join(err, e)

                if errors.As(e, &checksumMismatchErr) || errors.As(err, &invalidSignatureErr) {
-                       // Stop verification chain on checksum/signature errors.
-                       break
+                       log.Warningw("Verifier failed!", "verifier", v.Name(), "error", err)
                }
        }

[cmacknz]

You would still want the logger here to log the case where the all fail, which should be logged at the Error level.

You should be able to pass the logger you have here into the function call.

[pierrehilbert]

So just to ensure that I get it correctly: you prefer me to log directly in the composed/verifier.go instead of step_download.go to avoid returning something in the error output if at the end the upgrade was successful (from a conceptual perspective, success = no error)?

[cmacknz]

Yes, we need success = "no error".

The trouble you are running into is that you need to log twice, once inside the composed/verifier.go file for non-fatal errors that won't be returned (since final success = no error) and once when the verifier is called from the upgrade process for the fatal error where all verifiers failed.

[elastic-sonarqube]

SonarQube Quality Gate

26.7% Coverage on New Code (is less than 40%)

See analysis details on SonarQube