-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add start_time and minimum_execution_duration fields to actions #1381
Conversation
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
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 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
@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.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues