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
per-execution interruptible flag not piped through via flytekit #5279
Comments
The issue you're describing about setting the Would you like more detail on the current capabilities related to the Sources: This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not. Mention @RunLLM to ask follow-up questions. See runllm.com for more! |
Note that this issue talked about very much the same thing -- but the solution was to add this per-execution flag to the web form available on the Flyte Console UI. So there, you can set the |
@eapolinario Any thoughts about when this may get attention? |
Motivation: Why do you think this is important?
The
interruptible
flag for an execution is part of anExecutionSpec
, but there is no way to set this on a per-execution basis via flytekit. See the code for ExecutionSpec.interruptible.I would like to specify this value at runtime, but a present there appears to be no way to do this short of writing multiple workflows.
Goal: What should the final outcome look like, ideally?
I should be able to specify
interruptible
on a per-execution basis, just like I can specifyoverwrite_cache
(another example of a value that is part of anExecutionSpec
).This could be done, e.g., with an
interruptible
argument toFlyteRemote.execute()
. (again, just likeoverwrite_cache
)Describe alternatives you've considered
I've considered writing alternate workflows, in which the
@workflow
or@dynamic
specifiesinterruptible
as either True or False, and calling the appropriate one at runtime to create either an interruptible workflow or one that is not.Propose: Link/Inline OR Additional context
No response
Are you sure this issue hasn't been raised already?
Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: