Skip to content
This repository has been archived by the owner on Sep 17, 2024. It is now read-only.

Introduce tests for elastic-agent upgrade procedure #506

Merged
merged 27 commits into from
Dec 9, 2020

Conversation

michalpristas
Copy link
Contributor

@michalpristas michalpristas commented Dec 2, 2020

What does this PR do?

Just sharing WIP of Upgrade tests

SUITE=fleet DEVELOPER_MODE=true TAGS="fleet_mode && upgrade-agent" LOG_LEVEL=TRACE make -C e2e functional-test > test.upgrade.out

Why is it important?

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 run the Unit tests for the CLI, and they are passing locally
  • I have run the End-2-End tests for the suite I'm working on, and they are passing locally
  • I have noticed new Go dependencies (run make notice in the proper directory)

cc #341

@elasticmachine
Copy link
Contributor

elasticmachine commented Dec 2, 2020

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: Pull request #506 updated

  • Start Time: 2020-12-08T11:21:32.104+0000

  • Duration: 39 min 49 sec

Test stats 🧪

Test Results
Failed 0
Passed 81
Skipped 10
Total 91

💚 Flaky test report

Tests succeeded.

Expand to view the summary

Test stats 🧪

Test Results
Failed 0
Passed 81
Skipped 10
Total 91

@@ -43,6 +43,10 @@ var agentVersionBase = "8.0.0-SNAPSHOT"
// It can be overriden by ELASTIC_AGENT_VERSION env var
var agentVersion = agentVersionBase

// agentStaleVersion is the version of the agent to use as a base during upgrade
// It can be overriden by ELASTIC_AGENT_STALE_VERSION env var. Using latest GA as a default.
var agentStaleVersion = "7.10.0"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add it to the Jenkinsfile as an input parameter? This way we will allow manual tests on CI simply setting that input parameter in Jenkins UI

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding it to Jenkins as an optional param is even better... where it uses the value if passed... but if not, we can do some parse and math logic to get the current-minus-1 version (from the stack deployed or other e2e-testing variable) and use that instead. It is more future proof and will require less maintenance, right?

It is worth some discussion, open to what ever you want to merge, and if not tackled now, we can just drop a ticket in for the reminder of the work.

Copy link
Contributor

@EricDavisX EricDavisX left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pushing up the draft!

@michalpristas michalpristas marked this pull request as ready for review December 3, 2020 13:34
@michalpristas michalpristas changed the title Draft of upgrade test Introduce tests for elastic-agent upgrade procedure Dec 3, 2020
And certs for "<os>" are installed
When agent is upgraded to version "latest"
Then process waits for "2m"
And agent is in version "latest"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is great - after this I would like to see some of the other validation steps copied in, to make sure it is sending docs in to ES. ... and I realize we may not have that for Fleet cases (only for stand-alone) so we may leave this and add it as a separate item if we must.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

its a really weak validation as it is, no proof of what Agent is or can do after it is upgraded. But it is a start, nothing wrong with incremental improvements

@@ -138,6 +145,123 @@ func (fts *FleetTestSuite) contributeSteps(s *godog.Suite) {
s.Step(`^the policy will reflect the change in the Security App$`, fts.thePolicyWillReflectTheChangeInTheSecurityApp)
}

func (fts *FleetTestSuite) anStaleAgentIsDeployedToFleetWithInstaller(image, version, installerType string) error {
agentVersionBackup := agentVersion
defer func() { agentVersion = agentVersionBackup }()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked this post-condition style!

return fts.anAgentIsDeployedToFleetWithInstaller(image, installerType)
}

func (fts *FleetTestSuite) installCerts(targetOS string) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd delegate this logic to the installer, as it has the code for debian/centos in separated methods. wdyt?

@michalpristas
Copy link
Contributor Author

@mdelapenya updated steps and code to make it nicer, can we get this in?

@EricDavisX
Copy link
Contributor

There were some smaller debates, but code fine as is with one item I did want to confirm about branch support over time vs hard-coded (Agent) file version (7.10.0).

Did we run the other branches yet to see how they would work... we can test them in the backport PRs I guess.

I'm trying to figure if we want to take the low-fi approach and just update the stale-agent value when needed... I suppose over time the worst that will happen is that it uncovers an upgrade bug that we won't care to fix (too old, unsupported case) or maybe if we aren't testing on new enough versions routinely then we may miss an upgrade bug for whatever reason from more recent 'stale' version to current. The fix in this case is just to update the version in the different branches when those branches are created, we just need to remember to do that, that is if we don't put in some dynamic logic.

@EricDavisX
Copy link
Contributor

Michal and I discussed and we'll merge as is. And I logged a ticket for the remaining work and ideas to resolve the version problem with dynamic version assessment.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants