This sounds like an excellent step forward for the deployment machinery of Knox - good work! It will also provide even greater compatibility with Hadoop platform deployments.
We should continue this work to define collections of versioned services as a single Hadoop platform definition - composites. I would also like to see providers referenced as reusable configurations of security policy as we have discussed offline. I will spend some time reviewing this work tomorrow. Is there a single patch available for the review? On Tue, Feb 17, 2015 at 10:33 PM, Sumit Gupta <[email protected]> wrote: > I'm looking for comments, feedback and essentially a review of the branch > KNOX-481. It contains work related to the jira of the same name. > > At the highest level, the changes involve removing boiler plate code for > adding a service that involved deployment and dispatch contributors and > replacing it by writing an xml file. The file needs to be called > 'service.xml' (in this initial version) and be placed alongside the > corresponding rewrite.xml file if there is one. > > The existing service 'definitions' have been converted to use this format > and can be found in a new maven module called gateway-service-definitions. > Just to recap, these services are: > > 1. Hbase > 2. Hive > 3. Oozie > 4. Webhcat > 5. Webhdfs > 6. Yarn > > The structure of the files (and the files themselves) also make their way > into in the knox assembly under the 'data' directory. > > Without delving into the xml file too much, I am hoping that the existing > service files provide enough of an example as does the fake service for the > test case. > > Other than that, some minor things of note are: > > 1. The httpclient is now shared a bit more than it was previously (it > was created for each request before) > 2. The service definitions can now be versioned and the topology can > specify a version. If none is specified, the latest should be picked. > 3. The dispatch class can still be customized either by specifying a > contributor or a class name. > 4. To make the writing of a custom dispatch easier, there is a > configuration injection framework (thanks to Kevin Minder) that will inject > objects onto the dispatch instance from FilterConfig or ServletContext. > > Sumit >
