The current dependencies are based on how Apex YARN client works. YARN
depends on a DFS implementation for deployment (not necessarily HDFS).
I think a better way to look at this is to consider that instead of an .apa
file the application is a docker image, which would contain Apex and all
depende
Unfortunately the moving of .apa file to a docker image cannot resolve all
problems with the dependencies. If we assume an Apex application should be
run in different execution environments, the application docker image must
contain all possible execution environment dependencies.
I think the bett
In cases where we have an "über" docker image containing support for
multiple execution environments it might be useful for the Apex core to
infer what kind of execution environment to use for a particular
invocation (say based on configuration values/environment variables) and
in that case the co
IMO, support for Kubernetes, Docker images, Mesos and anything outside
of Yarn deployments is a topic by itself and design for such support
needs to be discussed. I do not want to propose any specific design, but
assume that logic to create proper execution environment would be coded
into Apex
