-
Notifications
You must be signed in to change notification settings - Fork 19
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
Enhancement: Support different SLA types #2906
Conversation
dylanbhughes
commented
Jan 29, 2025
•
edited
Loading
edited
…ylan/enhancement/dynamic-sla-types
Related to CLOUD-1035 |
} | ||
|
||
public durationInSeconds(): number { | ||
return this.trigger.within | ||
} | ||
|
||
public getSlaType(): string { | ||
return ServiceLevelAgreementType.TimeToCompletion | ||
public getSlaDefinitionKeyValuePairs(): { key: string, value: unknown }[] { |
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 happening because we don't preserve the full state of what a user asked for in the SLA object on the backend. We turn the SLA into an automation and stick some labels on it in the db to preserve the minimal SLA state we need (severity, type, etc) but we don't have the properties exposed in the OSS client. Example:
class FrequencySla:
stale_after: timedelta
flow.deploy(_sla=FrequencySla(severity="minor", stale_after=timedelta(hours=1)))
We store automation.labels = {"prefect.sla.severity": "minor", "prefect.sla.type": "FrequencySla"}
in the db. So I'm "re-assembling" the interface we provided to the user at deploy time.
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.
LGTM!