-
Notifications
You must be signed in to change notification settings - Fork 671
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
[Feature] Abstraction and standardization of query tasks #238
Comments
I think this should be done by elevating SQL as an alternative to container in the task spec. IMO task spec contains a reference to the portable code, for which container is a great proxy. In case of queries you don’t need a container as the code itself is portable. And so we could capture the code inline |
* Update productionize_cluster.py * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> * Update cookbook/deployment/cluster/productionize_cluster.py Co-authored-by: Ketan Umare <[email protected]> * Update productionize_cluster.py Co-authored-by: Niels Bantilan <[email protected]> Co-authored-by: Ketan Umare <[email protected]>
Hello 👋, This issue has been inactive for over 9 months. To help maintain a clean and focused backlog, we'll be marking this issue as stale and will close the issue if we detect no activity in the next 7 days. Thank you for your contribution and understanding! 🙏 |
Hello 👋, This issue has been inactive for over 9 months and hasn't received any updates since it was marked as stale. We'll be closing this issue for now, but if you believe this issue is still relevant, please feel free to reopen it. Thank you for your contribution and understanding! 🙏 |
this has been already done. Flyte TaskTemplates can have queries in them |
* SVR-566: Log and monitor failures to parse access tokens Signed-off-by: Katrina Rogan <[email protected]> * update Signed-off-by: Katrina Rogan <[email protected]> * lul Signed-off-by: Katrina Rogan <[email protected]> * fmt Signed-off-by: Katrina Rogan <[email protected]> * debug Signed-off-by: Katrina Rogan <[email protected]> * debug Signed-off-by: Katrina Rogan <[email protected]> * works on my machine Signed-off-by: Katrina Rogan <[email protected]> * debug Signed-off-by: Katrina Rogan <[email protected]> * trying 2 do thingz Signed-off-by: Katrina Rogan <[email protected]> * woops Signed-off-by: Katrina Rogan <[email protected]> * tada Signed-off-by: Katrina Rogan <[email protected]> --------- Signed-off-by: Katrina Rogan <[email protected]>
Motivation: Why do you think this is important?
Now that we have a Presto task and a Hive task in Flytekit, we should consider abstracting them both behind a more general Flytekit query task.
We should also change the way Hive queries currently run (as de facto dynamic tasks), and follow the pattern established by the new Presto plugin. It may not be possible to do this in a backwards compatible way however, especially considering legacy code at Lyft, so the development of a general query task that supports Hive may be independent from the existing Hive task.
Goal: What should the final outcome look like, ideally?
Flytekit tasks that are more general.
Describe alternatives you've considered
None.
Flyte component
Additional context
Original Presto task issue: #203
The text was updated successfully, but these errors were encountered: