[Hawkular-dev] The components, glue and kettle

Gary Brown gbrown at redhat.com
Wed May 13 06:49:05 EDT 2015


Hi Thomas

I agree that Hawkular/Kettle should have the ability to customise the components (e.g. add further percentiles, alert definitions, etc), and how the components communicate. But I still believe the code to support those customisations and communication options should live within the component.

It makes the components more maintainable/testable - with Hawkular/Kettle being responsible for assembly/customisation/end to end testing.

Regards
Gary

----- Original Message -----
> To add to this.
> 
> I think we are trying to put too much into the components, defeating the
> whole purpose of the componentization that I was advocating for in the
> 2014 f2f.
> 
> The components need to do minimum things and do them well. They should
> go to maintenance relatively early, after that all the specifics need to
> be in Hawkular.
> 
> One example, today we have calculation of 95 percentile within Metrics
> [1], IMO this should be in hawkular (and Metrics need to provide a way
> to add that functionality which I think was one thing discussed at f2f).
> If I need 97 or 98 or 99 or 99.99 percentile, I should be able to do
> that without another release of metrics.
> 
> Hawkular (the kettle) should be in charge of "deciding" who (which
> components) receive what information based on Hawkular configuration.
> 
> [1] I understand that this was a shortcut. No finger pointing
> 
> Thomas
> 
> 
> 
> 
> 
> On 05/13/2015 12:25 PM, Thomas Heute wrote:
> > +1
> >
> > On 05/13/2015 11:53 AM, Michael Burman wrote:
> >> Hi,
> >>
> >> I disagree with the fact where the actual bus-integration component
> >> should reside. The components themselves should have the capabilities
> >> of allowing another component to connect to their internal "feeds" but
> >> the actual component -> bus  connector should be in the
> >> Kettle-repository. Why? The bus-connector is highly dependent on the
> >> actual bus implementation. If we would change the bus in any way in
> >> terms of implementation or API, it would require changes to every
> >> Hawkular component (thus, they wouldn't be decoupled by design)
> >> instead of only changing the implementation at the bus-component.
> >>
> >>     - Micke
> >>
> >> ----- Original Message -----
> >> From: "Gary Brown" <gbrown at redhat.com>
> >> To: "Discussions around Hawkular development"
> >> <hawkular-dev at lists.jboss.org>
> >> Sent: Wednesday, May 13, 2015 11:02:31 AM
> >> Subject: [Hawkular-dev] The components, glue and kettle
> >>
> >> Hi
> >>
> >> On yesterday's watercooler discussion the main topic was about how to
> >> package the individual components, with the "glue" code, within kettle.
> >>
> >> There seems to be a general idea to move all bus integration code into
> >> Hawkular/Kettle repo. Although I agree that the kettle is the right
> >> place to bring together the components and glue, not sure whether the
> >> actual code for the glue should reside in that single repo.
> >>
> >> My preference would be for all component related code, including that
> >> component's integration with the bus, to be located in that component
> >> repo - that way there is a clear owner of the code, and any changes to
> >> the core APIs are locally dealt across all integration points that may
> >> be supported.
> >>
> >> Then the kettle repo can be responsible for selecting the relevant
> >> artifacts to build what it requires.
> >>
> >> In terms of how the 'core' artifacts from each component should be
> >> enhanced with the glue - may be the simplest way would be as one
> >> person suggested - use an overlay to build upon the 'core' war
> >> artifact to add the glue artifacts (which in general will probably
> >> just be bus integration). So each component only needs to produce a
> >> single 'core' war, but also manages the integration artifacts locally.
> >>
> >> I think I would prefer this approach over a single ear, as it still
> >> retains the individual component boundaries but enhances them with
> >> whatever they need to communicate in the kettle.
> >>
> >> It would be even more ideal if jboss modules allowed exploded wars, so
> >> that we didn't need to use overlays, but I don't believe this is the
> >> case.
> >>
> >> Regards
> >> Gary
> >>
> >> _______________________________________________
> >> 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
> >>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 


More information about the hawkular-dev mailing list