[giving my unrequested 2cents as a spectator on this. :) ]
On 2017-07-25 14:06 (-0700), Bill Graham <[email protected]> wrote: > +1 for more upfront clarification of the authentication model. You can easily add mutual TLS authentication in Jetty, just by setting the appropriate configuration. Jetty will ensure that only clients with valid certificates have access to the APIs. In addition to that, from the API handlers it's possible to access the "common name" or "principal" of the client and perform some role-based authorization and restrict a user to only access his own topologies. https://www.eclipse.org/jetty/documentation/9.4.x/configuring-ssl.html > - You can't make updates to and redeploy tracker (which is a non-critical > service) without redeploying the submit/kill/update service (which is more > critical). Both now have their lifecycles coupled. It would be easy to have flags to enable/disable tracker or api server components individually. This would give the flexibility to run it separately or in a single service. > - A critical bug or outage of one service now effects the other. > - The performance/demand characteristics of one impacts the other. Being both the tracker and the API server pure stateless REST services, it's trivial to scale them by adding more instances and relying on VIP or any other load balancer mechanism. It's not the same thing as the Storm Nimbus service. > - Cross-cutting API concerns like authentication or caching gets more > complicated to support. The API service is a read/write service with the > need for auth, while the tracker service is read-only. There might be scenarios in which is also desirable to have authentication & authorization on the read-only tracker as well, to restrict what a particular user can view. In any case, it's easy to configure different authentication policies, for different path prefixes, on the servlet context in Jetty. Matteo
