[jira] [Commented] (REEF-54) Creating skeleton of driver configuration files

["Julia (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/REEF-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272263#comment-14272263 ] 

Julia commented on REEF-54:
---------------------------

There are both static and dynamic portions of driver configuration settings that are not set in Bridge JobClient. Our clients today call REEF Launcher with the pre-created driver config file therefor they get those portions of driver config from Java reef code.  To have a total decoupling, we need to abstract/refactor those configuration portions so that the skeleton would contain complete Java configuration and leaving dynamic portion to the clients. That can be in an separate issue/PR.

As a first step, in this issue, we would like to achieve the same result as what our clients are doing today.  We will generate a skeleton of config file with the same content as Bridge JobClient generates. After the client insert their config data, they would get the same config file as they are using today. 

> Creating skeleton of driver configuration files
> -----------------------------------------------
>
>                 Key: REEF-54
>                 URL: https://issues.apache.org/jira/browse/REEF-54
>             Project: REEF
>          Issue Type: Sub-task
>            Reporter: Julia
>            Assignee: Julia
>
> Client can submit a Job through REST API. For that, they need a serialized driver configuration file. In .Net/Java hybrid driver (see REEF-51 for a description of that), today the driver config file is created in Java JobClient, that is inconvenient for the clients.
>  
> In order for clients to set their parameters at their side, we would like to generate a skeleton of the driver configurations which only contains java configuration settings. This would leave flexibility to the client so that they can deserialize the driver configuration, and set additional parameters and then serialize the result into driver config file again.  
> To make the configuration modularized, we would also like to separate HttpServer configuration and NameServer configuration from driver configuration file when creating the skeletons. They would become building blocks. Client can choose what they want in the driver and merge them as need. This would make Http Server and Name server become optional instead of build-in in a .Net/Java hybrid driver. 
> The driver skeleton configuration creation should be part of the project build process so that we can always get the latest config files on the fly. The config files generated should be also packed inside the jar file for clients to consume. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)