+1 Lgtm, thanks Ke for the proposal.
On Tuesday, December 10, 2019, Prateek Maheshwari
wrote:
> Looks good to me as well. +1 for the overall proposal, and thanks for
> putting it together.
>
> - Prateek
>
> On Tue, Dec 10, 2019 at 1:26 PM Xinyu Liu wrote:
>
> > Thanks for updating the SEP wiki.
Looks good to me as well. +1 for the overall proposal, and thanks for
putting it together.
- Prateek
On Tue, Dec 10, 2019 at 1:26 PM Xinyu Liu wrote:
> Thanks for updating the SEP wiki. The revised design looks clear to me.
> Some config name might be simplified, e.g.
> job.config.loader.proper
Thanks for updating the SEP wiki. The revised design looks clear to me.
Some config name might be simplified, e.g. job.config.loader.properties.path.
Overall it looks good.
Thanks,
Xinyu
On Fri, Dec 6, 2019 at 1:52 PM Ke Wu wrote:
> As we are revamping our config loading logic in SEP-23: Simpli
As we are revamping our config loading logic in SEP-23: Simplify Job Runner, we
will introduce backward incompatible changes on the job submission logic, i.e.
deprecating the usage of --config-factory and --config-path, which reads a full
config upon job submission, instead, we will only provide
Hi Xinyu,
Please see the response in line:
> 1. After this change, seems the original config-factory and config-path
> are only used to supply parameters for submitting job. Is that the case?
> Which configs are still needed in the submission?
Yes, only configs related to job submission is
Thanks a lot for putting out the design for simplifying the job submission
process. The motivation makes sense to me that most of the planning and
config generation should be done after submitting to the cluster, instead
of during the submission, which can happen in a local sandbox without the
acce
