heron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Merli <mme...@apache.org>
Subject Re: Proposal for Heron API Server
Date Fri, 28 Jul 2017 18:19:53 GMT
[giving my unrequested 2cents as a spectator on this. :) ]

On 2017-07-25 14:06 (-0700), Bill Graham <billgraham@gmail.com> 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.


> - 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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message