-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Codecov Report
@@ Coverage Diff @@
## master #296 +/- ##
==========================================
- Coverage 75.57% 75.46% -0.11%
==========================================
Files 18 18
Lines 1171 1174 +3
==========================================
+ Hits 885 886 +1
- Misses 235 237 +2
Partials 51 51
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
protos/flyteidl/service/signal.proto
Outdated
service SignalService { | ||
// Fetches or creates a :ref:`ref_flyteidl.admin.Signal`. | ||
rpc GetOrCreateSignal (flyteidl.admin.SignalGetOrCreateRequest) returns (flyteidl.admin.Signal) { | ||
// Purposfully left out an HTTP API for this RPC call. This is meant to idempotently retrieve |
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.
hopefully one day we'll have authz!
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.
Does FlyteAdmin have a scheme implemented already? Happy to add something existing. I'm sure starting from the ground up would be a bit out of scope for this work.
protos/flyteidl/admin/signal.proto
Outdated
string token = 3; | ||
|
||
// Indicates a list of filters passed as string. | ||
// More info on constructing filters : <Link> |
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.
nit: can we populate the <Link>
with a sphinx reference
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 be honest, I just copied the list proto from other messages. It doesn't look like any have a link populated. Does one exist? Otherwise I will just remove the link.
} | ||
|
||
// Signal encapsulates a unique identifier, associated metadata, and a value for a single Flyte | ||
// signal. Signals may exist either without a set value (representing a signal request) or with a |
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.
interesting, can i ask why use an implicit behavior and not two separate messages for clarity instead?
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 thought it may be easier for the model transformers within FlyteAdmin, write one and use if everywhere. I think using a single table in FlyteAdmin with both the type and value is the correct approach, so emulating that in proto messages. There does not seem to be strong uniformity between the different model types. I am open to changing this if anyone feels strongly.
string signal_id = 1; | ||
|
||
// A type denoting the required value type for this signal. | ||
LiteralType type = 2; |
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.
Are there broader docs for how this is used? I didn't see an issue as part of the PR and I don't think I quite follow how this eventual value is produced. Could there be a case where we want multiple values as part of a signal?
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.
The best resource is probably the RFC. Currently the implementation is setup so FlytePropeller calls the GetOrCreate RPC endpoint while evaluating the GateNode during each iteration. The node only succeeds if the signal has a value set.
An external entity will set the signal value. For example, a user through the SetSignal RPC endpoint or the UI can set the signal with a post to the RESTful interface.
And I believe the LiteralType proto encapsulates a Collection, Map, etc. So we should be able to support a variety of variable types, including multiple values.
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
protos/flyteidl/core/workflow.proto
Outdated
@@ -68,6 +68,35 @@ message WorkflowNode { | |||
} | |||
} | |||
|
|||
// SignalCondition represents a dependency on an existing signal. |
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.
Can you clarify what you mean by an existing signal?
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 was probably caught up in the flyteadmin side; where a signal does not technically "exist", meaning it can be provided, until propeller processes the gatenode that contains the signal condition. I'll go ahead and remove this, it can be confusing.
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
Signed-off-by: Daniel Rammer <daniel@union.ai>
* added GateNode message Signed-off-by: Daniel Rammer <daniel@union.ai> * added signal service Signed-off-by: Daniel Rammer <daniel@union.ai> * fleshed out Signal service Signed-off-by: Daniel Rammer <daniel@union.ai> * updated signal service with a GetOrCreateSignal and SetSignal API Signed-off-by: Daniel Rammer <daniel@union.ai> * updated signal service api to use GetOrCreate semantics Signed-off-by: Daniel Rammer <daniel@union.ai> * added the ListSignals API Signed-off-by: Daniel Rammer <daniel@union.ai> * fixed SignalListResponse proto name Signed-off-by: Daniel Rammer <daniel@union.ai> * set HTTP API parameters Signed-off-by: Daniel Rammer <daniel@union.ai> * generated protos Signed-off-by: Daniel Rammer <daniel@union.ai> * documented GateNode Signed-off-by: Daniel Rammer <daniel@union.ai> * updated signal list API Signed-off-by: Daniel Rammer <daniel@union.ai> * filled out signal list api Signed-off-by: Daniel Rammer <daniel@union.ai> * addressing pr comments on docs Signed-off-by: Daniel Rammer <daniel@union.ai> * added an output variable name to the signal condition Signed-off-by: Daniel Rammer <daniel@union.ai> * reworded signal condition docs Signed-off-by: Daniel Rammer <daniel@union.ai> * added ApproveCondition to GateNode Signed-off-by: Daniel Rammer <daniel@union.ai> * removed authOpt Signed-off-by: Daniel Rammer <daniel@union.ai> * fixed types Signed-off-by: Daniel Rammer <daniel@union.ai> * updated doc_gen_deps to fix docs generation Signed-off-by: Daniel Rammer <daniel@union.ai> Signed-off-by: Daniel Rammer <daniel@union.ai>
TL;DR
GateNodes are used to stop the execution of downstream nodes. Simple gate node conditions are manual signalling or sleeping for a duration.
Type
Are all requirements met?
Complete description
^^^
Tracking Issue
flyteorg/flyte#208
Follow-up issue
NA