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
[Docs] improve docs on eager workflow remote execution #5288
Comments
Thank you for opening your first issue here! 🛠 |
Thank you for your detailed feedback on the documentation for eager workflows in Flyte, especially regarding remote execution. Your points highlight important areas for improvement in clarity and usability for users who are not directly involved in cluster management.
Your suggestions for making the remote execution code resemble local execution as closely as possible are insightful. Enhancing the documentation to better cater to non-DevOps personnel will indeed make the feature more accessible and easier to adopt. Would you like more detailed guidance on how to configure and use eager workflows remotely, including code examples and configuration details? This could potentially help you move forward with your implementation while the documentation is being improved. 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! |
@vttrifonov thank you for the feedback, we are aware, we have currently not dedicated enough resources to eager workflows. We will get to them soon, later in this year Q3ish If not would love your help.
|
Description
I am very excited to learn about eager workflows! Unfortunately, so far I have not managed to make them work for me outside of sandbox and local.
The documentation focuses mostly on sandbox/local execution and for remote there is just a blurb. Throughout the doc it seems like
@eager()
is enough to decorate the eager workflows but is seems like for remote workflows@eager(remote=...)
needs to be included everywhere (?). I understand (vaguely) why this is, but it does not make for a good looking code... This is not needed for@task
and@workflow
so the natural expectation is that it should not be needed for@eager
as well. In any, case a more complete example with eager sub-workflows with remote in mind will be nice.The second issue I ran into is that even when remote is set it turns out I also need 'secret_group' and 'secret_key' (otherwise an
AssertionError: secret_group must be defined when using a remote cluster
pops). This is where my attempts for using this feature have stalled. The documentation makes it sound like the person who writes the workflows (me) is the same as person who sets up the cluster (a very busy team of devops in our case). Other than toy examples, this is not true in general. For example, the doc saysWhen I read this initially I thought that I need to setup the cluster somehow (it sounds like my_client..., I've configured, my cluster etc) but then upon reading the secrets and authentication page (this should be linked in the eager workflow doc) it became more clear this is something that perhaps devops needs to do and then I get it from them. Not sure yet... I do not know much about setting up Kubernetes clusters but overall the impression is that to run
@eager
now I also need help from devops to intervene somehow.Overall,
@eager
is a great feature that needs to crystalize further. I am hoping my comments here will help a bit. Ideally, the remote executing code should look (mostly) like the local one. In the meantime, a bit better documentation (for non-devops people) for what it takes to setup and run with remote will be helpful.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: