----- Original Message ----- One issue may be patching the product - if each component has its own deployment (with glue added using overlay), then if a component needs to be patched, it is just a case of replacing that one module. I don't see this as a burden, I think it makes the boundaries between components much cleaner - each component with its integration points can be tested locally before being assembled/configured within hawkular. I believe the correct separation of tests should be: Component - unit and component related integration tests - to minimise unnecessary dependencies being introduced and therefore impacting the component tests. Hawkular - end to end integration and UI tests. We also need to consider component reuse. If all of the integration glue code is in hawkular, then any other projects that want to reuse just one component has to depend on artifacts from two repos. If all of the glue code was also in component, then (as with hawkular) the other components simply assemble the required components and configure as required. Regards Gary

----- Original Message ----- I guess first point to clear up is where the ear/wars would go. Based on using the nest, my assumption was that hawkular (in whatever form) would be deployed in the modules folder - in which case they would not be exploded, which would make patching more difficult. However if we are going to be placing the archive(s) in standalone/deployment, then it is not an issue. So we need to clarify which location we are talking about. One possibility is apiman - I could see them using metrics initially but then wanting alerts to help detect situations and notify users. I guess they would have two options, use hawkular as a complete solution, or metrics+alerts - but then if each component had no bus integration available, they would need to provide that glue themselves. So maybe it comes down to whether, even though used internally, is the bus considered to be one of the reusable components of the hawkular project? Regards Gary

That was the recommendation from Brian Stansberry. Brian explicitly told me that Red Hat products should not be shipping deployments in the scanner directory (e.g. standalone/deployments) specifically because they will not be patchable. This is why the nest supports the deployments/ directory - its under modules/ and therefore will be patchable using the WildFly patch mechanism.

Which is why we agreed at the F2F to have REST endpoints as the component interface that clients would use, but have a "hawkular" assembly that would include extra bus listeners/producers that would talk to other hawkular components when deployed in a Hawkular environment. This was the dual assembly idea (one with just core pieces, for standalone deployments, and another one that included hawkular glue code that allowed it to run in a hawkular environment). ----- Original Message -----

At the F2F breakout session we had, we had talked about doing the following (though I've since heard that this might not be what we are going to do - instead, perhaps use something like war overlays - so take this with a grain of salt): Each component should have two assemblies - one is a "core" assembly and the other is a "hawkular" assembly The "core" assembly is the standalone product - for example, this would be H-Metrics that can be deployed on its own, standalone. This is to support our requirement that things like Hawkualr-Metrics must be able to run standalone outside of a full blown Hawkular environment. The "hawkular" assembly is nothing more than the "core" assembly with an addition jar (or multiple jars, whatever they want to do) that contains the hawkular "glue" code. The "glue" code would be things like CDI listeners, bus listeners, bus producers. We had come up with a design to allow the "core" assembly to run standalone but if in "hawkular" deployment, that glue code would be the way it hooks into the hawkular environment (e.g. a CDI listener would listen for the component to start up, and install a bus listener to listen for hawkular messages over the bus). The assembly plugin would merely just add the glue code artifacts (the jar files) to the core build. So I envision something like this (as a maven layout) - this is a "psuedo" layout: hawkular-metrics/parent | |----- core API (jar artifact) | |----- webapp (war artifact) | |----- glue code (jar artifact) | |----- dist The "dist" maven module would build two assemblies - one that has the webapp+coreAPI ("core") and the other would be "core" + the glue code artifact jar shoved in, say, WEB-INF/lib (this jar is the thing that contains the CDI listeners, bus listeners, bus products, whatever). Now, if you don't want to put the glue code in each component's repo, just put them wherever and just have a dependency on that glue code artifact in the "dist" maven module for the component that pulls it in. This is similar to Heiko's idea of taking the Metrics WAR and in the kettle build just crack it open, put the glue code jar in the WEB-INF/lib, and re-archive the war. This design I mention above is just a formalization of that - its just how you would do it without messing with artifacts that come from the maven repo. I personally have a problem with us taking an artifact from the maven repo, cracking it open and modifying it, zipping it back up and THEN using that in the product. I much prefer that we put into the maven repository what we plan on actually deploying and running with. Just seems like there is a risk if our build processes modify artifacts before using them. There was a concern about classloading issues and that perhaps we need an "uber" ear that wraps all the components. We need someone to experiment with that idea. That is a question we need to answer ("do we need a uber ear in kettle?"). Anyway, that's what we talked about (among other things) in that F2F break out session (which I thought was one of the most productive sessions we had :) ----- Original Message -----

OK, that's good to know. Even as recent as the F2F we were talking about deploying components (like alerts) standalone. Which was the whole reason behind the "CDI listener" stuff. But if Metrics is the only standalone component, they can figure out how they want to do that, but all our other components can be assumed to only be running in a full Hawkular environment. That makes some decisions easy. No need to play all these games to get components "pluggable" into the hawkular ecosystem - dual assemblies, or cracking open artifacts and injecting glue code. We can just assume we have dependencies on all the other components and be done with it.

At F2F I got the impression that alerts will most likely be necessary to run with just metrics also - without rest of Hawkular? I'd say it's a good combo to keep those two as "standalone", as there are other alerting components available also (such as Bosun) - which we would probably like to 'compete' with. - Micke ----- Original Message ----- From: "John Mazzitelli" <mazz(a)redhat.com&gt; To: "Discussions around Hawkular development" <hawkular-dev(a)lists.jboss.org&gt; Sent: Thursday, May 21, 2015 1:43:41 PM Subject: Re: [Hawkular-dev] Hawkular integration OK, that's good to know. Even as recent as the F2F we were talking about deploying components (like alerts) standalone. Which was the whole reason behind the "CDI listener" stuff. But if Metrics is the only standalone component, they can figure out how they want to do that, but all our other components can be assumed to only be running in a full Hawkular environment. That makes some decisions easy. No need to play all these games to get components "pluggable" into the hawkular ecosystem - dual assemblies, or cracking open artifacts and injecting glue code. We can just assume we have dependencies on all the other components and be done with it. _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

Yeah, I was under the impression that metrics needs to be handled in a special manner since we need to run it differently in OpenShift. Which means when we also add in Alerting to OpenShift, it will also need to be handled in a special manner. But I guess we can figure that part out when we actually need to add in Alerting. I think the discussion was also thinking about doing things in a modular manner, where we could have the different components running as individual containers in kubernetes, and then spin up (or down) more containers as needed. But it looks like the decision is to not to go with that approach for scaling the main Hawkular server. ----- Original Message -----

On Thursday, May 21, 2015 16:20:01 Thomas Heute wrote: I apologize if I don't remember that correctly, but a set of docker containers was not an option. "A" docker container was. That is a big difference because a zip and a docker container are conceptually almost identical. Not so a set of containers that would assume the distributed deployment.

On 05/21/2015 04:38 PM, Heiko W.Rupp wrote: Indeed.

On 05/21/2015 04:40 PM, Heiko W.Rupp wrote: +1

----- Original Message ----- I guess this is the reason for the difference in opinion - you see bus as a component, where as I see it as plumbing :) Regards Gary