-
Notifications
You must be signed in to change notification settings - Fork 146
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
Add integration test upgrading latest release to a build from the current PR #5457
Add integration test upgrading latest release to a build from the current PR #5457
Conversation
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
…/elastic-agent into 4560-integration-test-pr-build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may have misunderstood the intent of the PR so please correct me if I am wrong but the purpose here is to have a fleet-managed agent (installed using the latest release) upgrade to the version built from source on the branch, correct?
Why do we need to impersonate the artifact server, messing with /etc/hosts? Wouldn't a simple httptest.Server
serve the package we have available locally? We should be able to set that on the policy using Fleet API...
Am I missing something?
Yes :) The issue is the agent will only upgrade to package it can verify the signature. In order to do so it uses 3 keys:
therefore, I needed to serve the key from a HTTPS server that matches the hard-coded address in the agent. I could use a proxy or something like that. However, impersonating API keeps it all in the test itself and does not rely on other tools. |
Ok, so for a limitation on ESS fleet-server side (not being able to send a I am not sure this is the best way to get a fleet-managed agent to upgrade to a locally signed package (we already support the test for standalone agents since we can pass the additional options). Maybe it's time to have integration tests run with something other than ESS deployments, using a fleet-server we can configure? @cmacknz do we still want to persevere in using ESS deployments in integration tests even if it forces us to implement these sort of workarounds ? @AndersonQ thanks for the explanation, I see now what constraints we have on integration tests involving fleet-managed agents, I will have another look |
I agree 100% with you, but it's the current limitations we have.
being able to deploy a fleet-server would also help us with the mTLS tests |
pkg/testing/fixture_install.go
Outdated
stamp := time.Now().Format(time.RFC3339) | ||
// on Windows a filename cannot contain a ':' as this collides with disk | ||
// labels (aka. C:\) | ||
stamp = strings.ReplaceAll(stamp, ":", "-") | ||
|
||
// Subtest names are separated by "/" characters which are not valid | ||
// filenames on Linux. | ||
sanitizedTestName := strings.ReplaceAll(f.t.Name(), "/", "-") | ||
prefix := fmt.Sprintf("%s-%s", sanitizedTestName, stamp) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this could be grouped in a generic utility function SanitizePath
or whatever other name...
@@ -247,6 +393,7 @@ func testUpgradeFleetManagedElasticAgent( | |||
nonInteractiveFlag = true | |||
} | |||
installOpts := atesting.InstallOpts{ | |||
Insecure: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be passed as parameter so that we use insecure: true only on the new test ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this line wasn't needed after all ? I cannot find it in the latest version of the PR
|
||
// prepareFileServer prepares and returns a started HTTPS file server serving | ||
// files from rootDir and using cert as its TLS certificate. | ||
func prepareFileServer(t *testing.T, rootDir string, cert tls.Certificate) *httptest.Server { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's better if we say what we actually do in this function
func prepareFileServer(t *testing.T, rootDir string, cert tls.Certificate) *httptest.Server { | |
func startHttpsFileServer(t *testing.T, rootDir string, cert tls.Certificate) *httptest.Server { |
return server | ||
} | ||
|
||
// prepareTLSCerts generates a CA and a child certificate for the given host and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am pretty sure there's already a function in test code that does this: can we avoid the duplication ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, I searched the repo and I could not find it. There is thought https://github.com/elastic/elastic-agent-libs/blob/v0.10.1/testing/certutil/certutil.go#L196 which almost works, but it doesn't because it does not allow to configure the host
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the other function is only missing the hostname I would rather extend the existing function, generating certificates is tedious and error prone, I would rather avoid the duplication...
Not blocking, anyways
Quality Gate passedIssues Measures |
|
What does this PR do?
Adds an integration test which upgrades the latest Elastic Agent release to the version built form the current PR being tested.
Why is it important?
It'll allow us to catch any bug preventing the agent from upgrading before merging the PR.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added an entry in./changelog/fragments
using the changelog toolDisruptive User Impact
How to test this PR locally
Related issues
Questions to ask yourself