[Hawkular-dev] Should the components depend on the bus ?

[Thomas Heute]

On 01/20/2015 11:14 AM, Lukas Krejci wrote:
> IMHO, the communication should be built into the components precisely because
> they are meant to be components - parts of a bigger picture.
>
> In that scenario, you will rarely encounter usecases where no communication
> between the components is needed. Fabric1 have zookeeper for similar purpose,
> kubernetes have etcd similarly, too.
I am not saying that they would not need to communicate, they don't 
necessarily have to communicate directly together
> I am a little bit nervous about using a bespoke solution for that though - but
> as long as it is made such that clients NOT using our bus implementation can
> still communicate with "us" over the actual channel, I'm ok with that (which
> from the little I have read seems to be the case).
How ?
> Granted, we could abstract the communication out into the glue code as you
> suggest and it would work but I think the potential problems with that
> approach outweigh the requirement for the components to publish events onto
> the bus. Any change in the component API (or behavior!) would have to be
> reflected in the glue, too.
Component API should not change, that's the contract. And this is what 
needs to be properly tested and hammered.  Behavior would unlikely need 
to change as well if the scope is well defined (HWK Metrics store 
metrics, there is not a lot of behavior to change, behavior would likely 
change at the glue level).
> The glue would become the bottleneck or would be
> massively harder to deploy in a distributed manner.
Why ? It doesn't necessarily have to change how it works but more how it 
is decomposed.

> >From the POV of purity of the API and functionality, you are absolutely right
> that we should strive for separation of concerns as much as possible. But
> given the fact that our components are meant to work together, I think that
> communication over bus is one of the core requirements for each of them. Maybe
> there should be a config flag to switch such communication off for the times
> where the components will be used outside of hawkular. But I don't think it is
> worth the effort to suppose that the components will primarily be used and
> deployed on their own - I think the opposite is true.

Also what are the plans to apply security uniformly across components ? 
We need to make sure that we don't duplicate efforts (and increase 
security issues), today there is keycloak integration in RHQ Metrics, I 
hope we can extract this into the "glue" and share with others.

Thomas



>
> On Tuesday, January 20, 2015 10:28:30 Thomas Heute wrote:
>> When we started the hawkular efforts, I had in mind that the components
>> would do minimum tasks as a library with REST/Java APIs and do them well.
>>
>> Inventory would manage resources (user defined (an "application", a
>> cluster) or architecture defined (an EAP server, a VM, a Kube pod...)),
>> assign ids...
>> Metrics would store/aggregate/compact metrics (like it is today)
>> Alerts would define some alert definition "model" and run an engine to
>> define when to trigger an alert.
>> ...
>>
>> Hawkular project would then be a firm/comprehensive solution that are
>> using all those components, would proxy the APIs, add security there
>> (instead of in each component),...
>>
>> But now I start to see that client aspect of the communication bus is
>> part of those components I think I understand the motivation for that
>> but not sure that this is what we really need. Am I the only one
>> thinking that the communication aspect should be left out of the
>> components ?
>>
>> For instance in http://docs.hawkularinventory.apiary.io/ for the
>> DumbFeed, I don't think it's the role of the Metrics to send
>> notification to the bus, if we need more than collecting metrics then it
>> is a job for Hawkular IMO (who may proxy the metrics request and send
>> notification to the bus).
>>
> Note that in the DumbFeed example, things would work even without the
> notification. Things would just not be that friendly - basically stuff would
> not automagically appear in the "discovery queue". The user would still be
> able to set up the resource with the metric. They would just have to "remember
> to do so" and use manual look-up to stitch things together.
>
>> Thomas
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev