Skip to content
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

Watcher does not consider build hash when determining if upgrade was rolled back #3821

Closed
AndersonQ opened this issue Nov 25, 2023 · 2 comments · Fixed by #3837, #3827 or #3842
Closed

Watcher does not consider build hash when determining if upgrade was rolled back #3821

AndersonQ opened this issue Nov 25, 2023 · 2 comments · Fixed by #3837, #3827 or #3842
Assignees
Labels
bug Something isn't working Team:Elastic-Agent Label for the Agent team

Comments

@AndersonQ
Copy link
Member

AndersonQ commented Nov 25, 2023

With the introduction of the tracking of UPG_ROLLBACK state the watcher compares the new version of the agent with the previous one. However when comparing it only uses the major.minor.path[-SNAPSHOT], ignoring the build hash.

If the agent is upgraded from an SNAPSHOT version to another the watcher considers they as being the same version and therefore it marks the upgrade as UPG_ROLLBACK and neither logs why it changed the upgrade status nor adds any information to the new state.
This leads to an successful upgrade, a healthy agent but marked as UPG_ROLLBACK as shown below. Without any log or information explaining why the agent is on an UPG_ROLLBACK state.

Screenshot from 2023-11-24 15-35-48

The culprit seems to be here:

// If the marker exists but the version of Agent we're running right
// now is the same as the prevVersion recorded in the marker, it means
// the upgrade was rolled back. Ideally, this UPG_ROLLBACK state would've
// been recorded in the marker's upgrade details field but, in case it
// isn't for some reason, we fallback to explicitly setting that state as
// part of the upgrade details in the marker.
if marker.PrevVersion == currentVersion {

The UpgradeMarker has both hashes, it just need to be used when comparing the versions

type UpdateMarker struct {
// Hash agent is updated to
Hash string `json:"hash" yaml:"hash"`
//UpdatedOn marks a date when update happened
UpdatedOn time.Time `json:"updated_on" yaml:"updated_on"`
// PrevVersion is a version agent is updated from
PrevVersion string `json:"prev_version" yaml:"prev_version"`
// PrevHash is a hash agent is updated from
PrevHash string `json:"prev_hash" yaml:"prev_hash"`
// Acked is a flag marking whether or not action was acked
Acked bool `json:"acked" yaml:"acked"`
Action *fleetapi.ActionUpgrade `json:"action" yaml:"action"`
Details *details.Details `json:"details,omitempty" yaml:"details,omitempty"`
}

For confirmed bugs, please report:

  • Version: main
  • Operating System: all
  • Discuss Forum URL: N/A
  • Steps to Reproduce: Upgrade from a snapshot build to another from the same version.
@AndersonQ AndersonQ added the bug Something isn't working label Nov 25, 2023
@cmacknz cmacknz changed the title Watcher does not consider build hash when comparing versions Watcher does not consider build hash when determining if upgrade was rolled back Nov 25, 2023
@cmacknz cmacknz added the Team:Elastic-Agent Label for the Agent team label Nov 25, 2023
@elasticmachine
Copy link
Contributor

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

@pchila
Copy link
Member

pchila commented Nov 30, 2023

Reopening as it needs fixes from PRs #3827 #3837

@pchila pchila reopened this Nov 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment