milenkovicm opened a new pull request, #1066:
URL: https://github.com/apache/datafusion-ballista/pull/1066
# Which issue does this PR close?
<!--
We generally require a GitHub issue to be filed for all bug fixes and
enhancements and this helps us generate change logs for our releases. You can
link an issue to this PR using the GitHub syntax. For example `Closes #123`
indicates that this PR will close issue #123.
-->
Closes #.
# Rationale for this change
First of all, apologies for a gigantic PR, but I did not see better way of
making this proposal.
With this proposal I'd like to propose one way forward for ballista,
direction is not set in stone so we could discuss alternatives.
I'd like to set the stage with driving idea, it may help understanding PR
better.
I believe if we want to revive ballista we need to make it a library rather
than full fledge application with all batteries included. If we continue
developing it as an application, core code will just grow, putting maintainers
on pressure to maintain code which may not be related to core ballista mission.
Making ballista as library, which could bootstrap schedulers and executors
with few lines of code, with possibility to plug in additional functionalities
will keep use-case specific code out of ballista. We should make it as simple
as bootstrapping datafusion application.
Second goal, I believe, should be keeping ballista functionalities on par
with datafusion releases. At the moment ballista is missing a lot of
functionalities, like writes, sinks, to name a few. The main, short term, goal
would be to get writes, inserts supported.
Lastly, client-scheduler, and scheduler-executor interaction should be
improved. Client-scheduler at the moment communicate using custom made gprc
protocol, which could get support for UDF(s), configuration ... current
client-scheduler protocol can be made an optional component, so users can bring
their own frontend such as spark connect, or similar. scheduler-executor as
well can be extended to support session configuration information, ...
So with those high level goals in mind, I have done a bit of code trimming
and maintenance. I have removed some code which I personally believe
should/could be an "add-on" to ballista.
# What changes are included in this PR?
This PR removes:
- python support (datafusion python is the main effort, we should focus
making it run on ballista)
- helm support (this can be contrib project)
- good part of ci directory (ci works without it)
- plugin sub-system (never finalized)
- caching support (this can be a contrib project)
- support for hdfs (library too old, there are newer library to be used)
- UI (can be a contrib project)
- made keda, rest-api, flight-sql optional (we could move them to contrib
project)
- key value store is gone, only memory store remains
- removes some dependencies which were detected as not used
This PR adds no functionality, but updates most of the dependencies.
# Are there any user-facing changes?
<!--
If there are user-facing changes then we may require documentation to be
updated before approving the PR.
-->
<!--
If there are any breaking changes to public APIs, please add the `api
change` label.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
