[Hawkular-dev] kettle build

[John Mazzitelli]

> > The "kettle" is that nest distribution with all of our hawkular
> > integration components deployed inside - inventory, alerts,
> > metrics, embedded C*, the UI console, etc.
> 
> I'm still confused about what is kettle and nest. By looking at the
> code, kettle seems to incorporate nest, adding the other modules there
> as well (alerts, inventory, ...). Thus, it sounds to me that, in order
> to integrate hawkular-accounts, I'd need to work on kettle and I could
> ignore nest.


The "nest" consists of the bus infrastructure and a "nest module extension" whose main purposes today is to provide the bus infrastructure and to deploy things it finds in its deployments directory (modules/.../org/hawkular/nest/main/deployments). This WAS going to be the "agent" until it was realized it could be used for both agent-side and server-side components - so it was renamed "nest".

In the future, I have a feeling the nest functionality will expand - but for now, that's what it is.

The kettle, you are right, is nothing more than an "integration build" for lack of a better term. It takes the nest, and deploys all of the hawkular integration components into the nest deployments directory. Running the kettle server means you get all the hawkular components in one single Wildfly container.

So it depends on what you want to do. If you only want to test a single component (say, alerts for example) you can take a nest build and just shove your alerts EAR into the nest deployments location and run it and you would have a running alerts component that has access to the bus infrastructure (which consists of an API and a broker itself).

If you want to test your stuff integrated with everything else, deploy it in the kettle and watch to see how it plays nice (or not :) with the rest of hawkular.


> 
> If that assumption is true, then I'd need to move the data source
> definition to kettle, instead of nest. Is this a problem?
>


We can add custom datasources that we need for all the integration components in the kettle, yes. We have now an XSLT transformation that takes the out of box wildfly standalone.xml and tweaks it for our use. This is not a problem - its how I think it should be done. The kettle is the integration platform for everything, so I think we should be adding things that the components need in there.

If you want to build your own server-side component that runs by itself, you would create your own "kettle-like" mvn module, build on top of the nest like the kettle does, but only deploy things that you would need and only tweak standalone.xml for your component.

But for now, we are building a witch's brew of anything and everything into the one kettle. So that's probably where you want to do it.


> Side question: is there a reason to remove the ExampleDS from
> standalone.xml? As a Wildfly user, I'd expect it to be there (at least
> for dev builds).

I don't think we want something called like "ExampleDS" in our production builds (which is likely what kettle will eventually become). We provide all hawkular integration components with a datasource that they are free to use - it is called HawkularDS. That's what hawkular devs will use.

We also provide java:/HawkularBusConnectionFactory to connect to the bus infrastructure (say, for use to inject via @Resource). You can use hawkular-bus-common and hawkular-bus-mdb jars for convienent API (the nest provides this for free - so long as your WAR/EAR/Whatever has a dependency on the nest module).


> > Also, the kettle is now in the hawkular repo master branch.
> > Everything should be in the nexus snapshot repo, so if you just git
> > clone hawkular and "mvn install", you'll get the kettle distro in
> > hawkular/kettle/target (its a zip file - just unzip it and run
> > standalone.sh like any other wildfly).
> 
> Could I also add a "dir" and "tar.gz" distribution to it? For
> development, I find it easier to deal with the dir (no need to extract
> anything).

You already can have a "dir" - if by that you mean the server exploded so you don't have to unzip it. Just build the kettle with "-Pdev" and in target it will already be exploded for you and no need to extract anything. If you want to add a tar.gz assembly, feel free to do so with a pull request.

Hope that helps.