-
Notifications
You must be signed in to change notification settings - Fork 42
Introduce tests for elastic-agent upgrade procedure #506
Conversation
@@ -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" |
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 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
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.
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.
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.
Thanks for pushing up the draft!
And certs for "<os>" are installed | ||
When agent is upgraded to version "latest" | ||
Then process waits for "2m" | ||
And agent is in version "latest" |
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.
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.
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.
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 }() |
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 liked this post-condition style!
return fts.anAgentIsDeployedToFleetWithInstaller(image, installerType) | ||
} | ||
|
||
func (fts *FleetTestSuite) installCerts(targetOS string) error { |
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'd delegate this logic to the installer, as it has the code for debian/centos in separated methods. wdyt?
@mdelapenya updated steps and code to make it nicer, can we get this in? |
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. |
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. |
What does this PR do?
Just sharing WIP of Upgrade tests
Why is it important?
Checklist
make notice
in the proper directory)cc #341