-
Notifications
You must be signed in to change notification settings - Fork 122
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
Scheduled upgrade fails with error parsing version ""
if agent restarts before the upgrade starts
#3912
Comments
error parsing version ""
if agent restarts before the upgrade starts error parsing version ""
if agent restarts before the upgrade starts
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
@pierrehilbert we should get this one fixed, likely it leads to failed upgrades or agents stuck in updating. |
Agree, I already added this to current sprint but didn't assign this yet. |
* simplify fleetapi.Actions.UnmarshalJSON * add test to ensure the state store is correctly loaded from disk * skip state store migration tests, they will be fixes on a follow-up PR as part of elastic#3912
* simplify fleetapi.Actions.UnmarshalJSON * add test to ensure the state store is correctly loaded from disk * skip state store migration tests, they will be fixes on a follow-up PR as part of #3912
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane) |
The issue seems to be on how the actions are loaded from disk. Using the patch patch.txt we can see the test will fail because the upgrade action version isn't loaded.
If you stop the test and check the store file, it contains all the data, but it sin't loaded correctly:
Bug root cause
TL;DR: we deserialise the action from one schema (the
fleetapi.FleetAction
) and serialise a different schema (our concrete action types, like thefleetapi.ActionUpgrade
. When reading from disk, we loose data, such as theversion
from the upgrade actions.Proposed fix
fleetapi.ActionTYPE
models to match the schema we receive from fleet. Add any action specific properties nested underdata
Fix implementation phases (using a feature branch):
fleetapi.ActionTYPE
to match the fleet-server model by adding the specific action properties nested under adata
property. Match fleet server action model and use on JSON for serialisation #4240The text was updated successfully, but these errors were encountered: