How do we plan on distributing the Hawkular WildFly Agent now? Before, we had a WAR
deployed in the server that had a single servlet running that would take an HTTP GET or
POST request and based on the request would package up the agent installer with the latest
agent extension and properly config the installer so when the agent was installed it could
talk to that server where it came from. It would also allow the installer to give the
agent the proper token credentials so it could talk to the server.
Is that WAR/servlet still going to be in the headless version? Just curious what the plans
were for that.
----- Original Message -----
Hello Everybody,
With a growing community and an increasingly large number of sub-projects, it
is the perfect time to rethink the packaging of Hawkular. This email is a
blueprint for changes to come to Hawkular as well as establish some patterns
for futures decisions.
Motivation
So far we have created Hawkular "All - in - one" releases that contain
everything , Hawkular server components, UI, the agent and also embedded
versions of Cassandra and KeyCloak. It's certainly the case that for
community we w ill still deliver a fully featured all-in-one package . We
also need to consider separate distributions for other projects that
integrate with Hawkular.
The recent effort to integrate with ManageIQ comes with its own set of
requirements for services . Not all of the Hawkular components are needed
and required components may be configured differently . For example the UI
is supplied from within ManageIQ side and Hawkular is to be run headless.
Other components like Cassandra will not run embedded, so there is no need
to supply it in an embedded package . KeyCloak will probably not be need ed
because we only have one technical user that will access Hawkular services.
Components / Services
Here a list of projects that are part of the Hawkular organization:
* Metrics - scalable, asynchronous, multi tenant, long term metrics
storage engine
* Inventory - registry of "things" that contains info about your
applications, servers, etc. and also keeps track of their relationships
with each other
* Alerts - alerting engine that allows trigger definitions to evaluate
incoming data, generate alerts (or events), and react with flexible
actions ond lifecycle management
* CommandGW - messaging framework for communicating between components
* Bus - messaging framework for communicating between components
* BTM - provide capabilities to monitor the flow of a business
transaction instance and enable performance analysis of the individual
components that make up an application
* Agent - used to monitor WildFly and related projects
* Accounts - is the user/organization module that provides
authentication, authorization and configuration for accounts
* Data Mining - alert predictions based on time series data
* Hawkular UI
* Hawkular Charts - Angular Directives for Metrics Visualization
* Embedded Cassandra - embedded Cassandra server specifically configured
for project use
T here are also various clients like the Ruby Gem or the Android client and
supporting infrastructure projects. Those are not part of this discussion.
Options for P ackages
The distribution packages need to follow product integrations with a special
distribution for community. The community package could potentially include
every single package from the Hawkular organization. However, the rest of
the packages need to be created along the lines of product use and include
only the minimal amount of components, services and third-party libraries to
satisfy integration requirements.
The distributions should be seen as funnels, the Hawkular community creates a
set of sub-projects that then get combined into few distributions that in
turn get consumed. Following this analogy, the number of packaged
distributions should also be kept to a minimum possible. For now we settled
on 3 packages detailed below, all will be available for download on
JBoss.org.
With the exception of the community distribution:
1) the QA team will be engaged in testing the package
2) the sub-components wil l strive to be aligned in terms of tech stack and
maturity
3) an automated test suite is required for packages that combine more than
one project
1. Hawkular - Community Distribution
Will include every single service listed above. The UI is a requirement
because some services are very hard to understand or use without a friendly
interface. The UI will be a community only effort at this point since there
are no plans for productization.
The current Hawkular repository will be adjusted to reflect this new mission;
the current UI will be moved to a separate repository. This package builds
on Hawkular Core S ervices as described next .
2. Hawkular Core S ervices
Geared towards MiQ integration, it will include only components needed for
the MiQ provider. This package uses the Metrics Distribution as described
below.
Components included: Metrics, Alerts, Inventory, CommandGW, and Bus
Reasons for some exclusions: K eycloak (different security model), E mbedded
Cassandra (only full C* deployments will be supported), and no Hawkular UI
because it will use a special purpose UI for MiQ.
3. Metrics D istribution
Geared towards usage as a pure Time Series D atabase (TSDB) and will be
exclusively made of Hawkular Metrics service.
Expansion and Contraction
Since its inception Hawkular has been growing by all metrics: projects, lines
of code, binary downloads, contributors, etc. But uncontrolled increase in
some metrics can be detrimental to the organization. This is especially true
for the number of projects. We will always need new projects to experiment,
but the reverse might be true for mature and established projects. As the
packaging and requirements for each distribution mature we need to consider
the reverse, merging separate sub-projects.
Packaging Format
This email did not touch on the physical packaging formats (rpm, zip, war,
jar) for the 3 distributions. We will follow-up with additional details in
the coming weeks.
All feedback is more than welcomed so feel free to reach us (Heiko and
Stefan) directly or reply to this thread.
Heiko & Stefan
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev