Add start_time and minimum_execution_duration fields to actions#1381
Add start_time and minimum_execution_duration fields to actions#1381michel-laterman merged 9 commits intoelastic:mainfrom
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsTo re-run your PR in the CI, just comment with:
|
|
This pull request does not have a backport label. Could you fix it @michel-laterman? 🙏
NOTE: |
e9093e0 to
4f68eac
Compare
Add start_time and minimum_execution_duration fields to action definition. When start_time and expiration are defined the fleet-server will schedule agent actions within [start:expiration], if the minimum_execution_duration s defined the scheduling range is [start:expiration-minimum_execution_duration]. An agent's scheduled time within the range depends on the agent id's position within the list.
4f68eac to
113a21e
Compare
AndersonQ
left a comment
There was a problem hiding this comment.
I left a question. But LGTM
|
requires elastic/elasticsearch#8616 right? |
internal/pkg/action/dispatcher.go
Outdated
| if start == "" || exp == "" { | ||
| return "" | ||
| } | ||
| startTS, err := time.Parse(time.RFC3339, start) // TODO what format does a date-time string use? |
There was a problem hiding this comment.
Shouldn't we move the validation to the original unpack of the action instead? If there is an unserialization error this means that the contract between fleet and fleet-server is broken. I don't think we should even try to process that event.
There was a problem hiding this comment.
To summarize a quick conversation. We should catch this on the json unpacking, however the model.Action is generated by elastic/go-json-schema-generate which does not support mapping a (json) string/date-time to go's time.Time. The upstream generator we forked our code from has this as an open issue a-h/generate#69 so if we get around to it we should contribute it back
ph
left a comment
There was a problem hiding this comment.
@michel-laterman Changes LGTM, it's there a way to test it end to end with Elasticsearch with an integration test?
|
This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏 |
|
This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏 |
|
This pull request is now in conflicts. Could you fix it @michel-laterman? 🙏 |
What is the problem this PR solves?
Fleet-server should be able to inform agents of actions that are scheduled to start at a later time.
Fleet-server should also be able to spread the start time that different agents within the window of start:expiration.
This should help with ensuring that hundreds (or thousands) of agents don't exhaust the network when upgrading (for instance).
How does this PR solve the problem?
Add start_time and minimum_execution_duration fields to action
definition. When start_time and expiration are defined the fleet-server
will schedule agent actions within [start:expiration], if the
minimum_execution_duration s defined the scheduling range is
[start:expiration-minimum_execution_duration]. An agent's scheduled time
within the range depends on the agent id's position within the list.
How to test this PR locally
See testing in elastic/elastic-agent#419
Checklist
[ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related issues