I'm not sure where most of the conversation is going on, but I would like to
add a little experience previously working in large enterprises where SLAs were
a part of day to day life.
I would agree that both use cases are common:
1) Some alert or action for when a DAG or task *should* have completed
but hasn't
2) Some alert or action for when a DAG or task exceeded some time from
when it started
In my experience the organizations I have work with tended to refer to 1 as an
SLA (Service Level Agreement) and 2 as an OLA (Operational Level Agreement),
the idea that a service as a whole should stick to agreed times, but also there
should be operational agreements that only start once prerequisites have been
completed. I am not sure if this is common in general or unique terminology
within the organizations I have worked with.
From my experience I would therefore agree that to many it would be unintuitive
if the behavior is 2 but it is called SLA.
Damian
-----Original Message-----
From: Daniel Standish <[email protected]>
Sent: Wednesday, September 20, 2023 11:29 AM
To: [email protected]
Subject: Re: [DISCUSS] Mechanism of SLA
I don't think of it as really a question about accurate record keeping but more
a question of what an SLA is, i.e. when do you want the warning, or what do you
want the warning based on. I think that the idea has been that it really
means, "if task not done by X time each day then warn". And the way this was
defined is dag schedule + timedelta. And, it does seem that this is sort of a
desired feature. Indeed it just came up again in one of the keynotes. But, it
will be nice to talk about it tomorrow and see what others think.
Thanks for the blog post. Reading it was productive for me. I hadn't really
considered the fact that the existing way that SLA works could be
counterintuitive. I can see how it wcould be. You set it as a timedelta param
on a task, and then this timedelta is added to the dag "should start"
date, instead of task duration. Anyway, again, look forward to chatting about
it.
________________________________
Strike Technologies, LLC (“Strike”) is part of the GTS family of companies.
Strike is a technology solutions provider, and is not a broker or dealer and
does not transact any securities related business directly whatsoever. This
communication is the property of Strike and its affiliates, and does not
constitute an offer to sell or the solicitation of an offer to buy any security
in any jurisdiction. It is intended only for the person to whom it is addressed
and may contain information that is privileged, confidential, or otherwise
protected from disclosure. Distribution or copying of this communication, or
the information contained herein, by anyone other than the intended recipient
is prohibited. If you have received this communication in error, please
immediately notify Strike at [email protected], and delete and
destroy any copies hereof.
________________________________
CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any attachments are
intended solely for the addressee. This transmission is covered by the
Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The information
contained in this transmission is confidential in nature and protected from
further use or disclosure under U.S. Pub. L. 106-102, 113 U.S. Stat. 1338
(1999), and may be subject to attorney-client or other legal privilege. Your
use or disclosure of this information for any purpose other than that intended
by its transmittal is strictly prohibited, and may subject you to fines and/or
penalties under federal and state law. If you are not the intended recipient of
this transmission, please DESTROY ALL COPIES RECEIVED and confirm destruction
to the sender via return transmittal.
