[Hawkular-dev] RfC: Layered Hawkular-services vs packaged one

[Matt Wringe]

----- Original Message -----
> From: "Heiko W.Rupp" <hrupp at redhat.com>
> To: "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Thursday, 4 May, 2017 5:29:30 AM
> Subject: [Hawkular-dev] RfC: Layered Hawkular-services vs packaged one
> 
> Hey,
> 
> right now when we deploy Hawkular-services (H-S) on OpenShift, we run
> into a situation where the user may already have deployed
> Hawkular-Metrics (HAM) in OpenShift[1] and thus by deploying H-S will
> end up in a situation where HAM is deployed twice - once for the
> platform and once for H-S.
> 
> One solution could be to 'just' deploy H-S in OpenShift instead of HAM,
> but this has some drawbacks
> - larger deployment
> - inclusion of parts that are not needed in 'classic' OpenShift
> - different security model for OS-HAM than for H-Services
> 
> Another option could be to logically split and layer H-S:
> - Have a H-S container (H-S-2) , that does not contain HAM
> - This container would provide everything of H-S without HAM
> - Calls to H-S-2 HAM are forwarded to OS-HAM
> 
> Of course there is no such thing as a free lunch:
> 
> - need to reserve the 'hawkular' tenant in OS-Metrics

Sorry for my ignorance, is this just a special tenant that Hawkular Services uses? Is this just used for internal information that Hawkular Services?

Is it really hard coded to this? or could be change it to something else which would not conflict with other tenants? eg something like '_hawkular' or '_hawkular-services'?

> - OS-Metrics has a different security concept
>        H-S-2 could act as a proxy that receives calls to HAM from agents
> and clients, but 'translates' credentials and then forwards the calls to
> OS-HAM
> 
> Does the above idea make any sense?
> I am sure I am missing a ton of items in the above list

For me, the bigger issue is around do we want to open up the HAM version we have in OpenShift to just anything?

Right now we are in control of what goes in here. Its only Heapster and HOSA which can write metrics, and those are managed by an admin. This allows for the control of how often metrics and how many metrics are written. Knowing this information, an admin can factor in how much diskspace they may require.

If we start to open this up to other users to write their own metrics, then I think we start to run into issues. We don't have an mechanism to only accept so many metric writes from going into Hawkular Metrics, so it might open things up to using more disk space than an admin would have originally allocated.

If I am running my own OpenShift cluster, then sure, I might want to allow my own projects to reuse the internal Hawkular Metrics instance. Its my cluster here running my components.

But for something like OpenShift Online, where there are separate users all running the same cluster, I think we would probably want to have checks in place to prevent users from using up too many of the resources used by the infrastructure components.