I think this is a reasonable direction for Metron. It probably makes sense to make sure that your services can accept identity propagation from Knox so that they can also be proxied along with Hadoop APIs.
FWIW - discussing whether a JAXRS programming model is something wanted by the community wouldn't be a difficult thing to do. It hasn't been discussed to this point which is why it isn't documented - this is primarily because there hasn't been any explicit demand for it. On Mon, Oct 24, 2016 at 10:51 AM, zeo...@gmail.com <zeo...@gmail.com> wrote: > Ok, that sounds good to me, I primarily wanted to see whether or not it was > attempted and if it hit a technical roadblock. Thanks, > > Jon > > On Mon, Oct 24, 2016 at 10:11 AM Ryan Merriman <merrim...@gmail.com> > wrote: > > > There is also this comment in that Jira: > > > > "Adding the JAXRS services to knox is really easy but we haven't really > > discussed whether it should be a programming model aspect of Knox in the > > community" > > > > I think that would need to be worked out before we move services into > Knox, > > if we decide we should do that. > > > > > > > > On Mon, Oct 24, 2016 at 9:06 AM, Ryan Merriman <merrim...@gmail.com> > > wrote: > > > > > I spent some time researching the Knox documentation and building > custom > > > services (hosted in Knox) was not well-documented. Spring is a great > > > choice for that and I didn't really get any other feedback on which > > > application development framework to use. So that's what I went with. > > > > > > I think we should plan on adding Knox in front to leverage all the nice > > > security features and integrations. That is how most Knox integrations > > > (HFDS, Storm, etc) are architected. > > > > > > Ryan > > > > > > On Mon, Oct 24, 2016 at 8:37 AM, zeo...@gmail.com <zeo...@gmail.com> > > > wrote: > > > > > >> So it looks like, for now, you are not pursuing Knox (per comments in > > >> METRON-503 and then PR 316). Is there a reason for that? > > >> > > >> Jon > > >> > > >> On Fri, Oct 14, 2016 at 5:59 PM zeo...@gmail.com <zeo...@gmail.com> > > >> wrote: > > >> > > >> > Good question :) > > >> > > > >> > On Fri, Oct 14, 2016, 17:07 Ryan Merriman <merrim...@gmail.com> > > wrote: > > >> > > > >> > Jon, > > >> > > > >> > It wasn't intentional, I ran out of time and wanted to get something > > out > > >> > there. I think it certainly could be open ended though. Where > should > > >> the > > >> > REST API project be located? > > >> > > > >> > Ryan > > >> > > > >> > On Thu, Oct 13, 2016 at 7:32 PM, zeo...@gmail.com <zeo...@gmail.com > > > > >> > wrote: > > >> > > > >> > > Along the lines of: > > >> > > • Must be deployed to a machine with adequate resources so that > > >> resource > > >> > > contention is avoided. > > >> > > • Will need network access to all other services within Metron > > >> > > > > >> > > Has there been any consideration of a "Metron Manager" node? In > the > > >> old > > >> > > TP2 > > >> > > bare metal install guide > > >> > > <https://cwiki.apache.org/confluence/display/METRON/ > > >> > > Metron+Installation+on+an+Ambari-Managed+Cluster> > > >> > > it mentions a "Metron Installer," but I could see the needs for > that > > >> sort > > >> > > of a system expanding to have the following roles: > > >> > > - API > > >> > > - Metron UI > > >> > > - Metron Installer/upgrades > > >> > > - Edge/Gateway Node for data loading > > >> > > - Clients > > >> > > > > >> > > Also, at the end it ends mid-sentence under "Organization within > > >> Metron," > > >> > > was that intended to be open ended? > > >> > > > > >> > > Jon > > >> > > > > >> > > On Thu, Oct 13, 2016 at 6:10 PM Ryan Merriman < > merrim...@gmail.com> > > >> > wrote: > > >> > > > > >> > > > I created a Jira to track this new feature at > > >> > > > https://issues.apache.org/jira/browse/METRON-503. I also > started > > >> and > > >> > > > attached an architecture doc to that Jira with some of my ideas > > >> about > > >> > how > > >> > > > we should implement it. Please feel free to review and comment > or > > >> add > > >> > to > > >> > > > it. Looking forward to everyone's ideas and feedback. > > >> > > > > > >> > > > Ryan Merriman > > >> > > > > > >> > > -- > > >> > > > > >> > > Jon > > >> > > > > >> > > > >> > -- > > >> > > > >> > Jon > > >> > > > >> -- > > >> > > >> Jon > > >> > > > > > > > > > -- > > Jon >
