new hawkular build
by John Mazzitelli
The hawkular/hawkular repo (hawkular-nest branch) is close to being ready for WF9. It builds, and seems to run OK except for an issue in inventory which Jiri has a fix for that he'll push.
The agent is kinda ready - I can't release until inventory 0.1.0 is released, but it should be ready to work with the new inventory other than just waiting for the inventory release. The agent is also ready for the new metrics 0.4.0 that was released.
I don't know the state of the UI, alerts, and accounts with respect to the new hawkular-next branch - but I think they are close if not fully ready.
So we are close to getting a full integration build that runs on WF9.
9 years, 6 months
Tag concept in metrics and alerts
by Gary Brown
Hi
Both metrics and alerts use the term 'tag' - however metrics use a name/value pair for a tag, and alerts uses it as a label. Wondering whether we need consistency?
When I hear the term tag, I usually envisage a label - e.g. as in git. So wondering whether it would be clearer for metrics to rename tags to properties?
Possibly metrics needs the concept of a tag/label as well?
Regards
Gary
9 years, 6 months
JSON: jackson and gson. Can we unify the libraries ?
by Lucas Ponce
Hello,
As an implementation detail, we are using two libraries to serialize/deserialize with JSON.
For REST endpoints we are using mainly jackson library as it's packaged with RESTEasy implementation.
For BUS and other scenarios (like alert engine), we are using gson library.
Does it make sense to unify them ?
I have an scenario where I would like to use a class used as data in REST endpoints as payload of a BUS message, and I need to deal with some duplication on json serialization/deserialization tasks.
Perhaps there are good reason to maintain both and that's the best answer but I'm not sure and I wanted to start a discussion around it.
Thanks,
Lucas
9 years, 6 months
Hawkular Commons 0.1.1.Final (a.k.a. Embedded Cassandra) released
by Peter Palaga
Hi *,
I just released Hawkular Commons 0.1.1.Final.
This release fixes 0.1.0.Final which did not work at all in Hawkular.
Changes: https://github.com/hawkular/hawkular-commons/commits/0.1.1.Final
As agreed with Heiko, this release introduces the tagging scheme with
tags in master, which we find more intuitive and more common than the
scheme used in Metrics which has tags only in maintenance branches thus
making important points of the history invisible in master.
I am personally sorry not to have enough time to discuss the change with
the originators of the original tagging policy before changing the
policy. We needed to release to fix Hawkular and there seemed to exist a
broader consensus that having tags in master is better.
Best,
Peter
9 years, 6 months
Solved in Parent 17: JavaDoc Plugin failing during release:perform
by Peter Palaga
Hi *,
I could finally find why the JavaDoc plugin was failing during
release:perform.
The <additionalparam>${javadoc.doclint}</additionalparam> parameter set
in "release" profile in parent [1] was ignored because the "release"
profile simply was not active during release:perform.
I always thought that release plugin activates the profile with this
name during release:perform by default. Apparently, it is not the case.
The solution was to add an explicit
<releaseProfiles>release</releaseProfiles>
to the <configuration> of release plugin [2]. The change is there in
hawkular-parent 17 that I have just released. I am about to send PRs to
consuming projects.
Sorry for the inconvenience that was caused solely by my ignorance.
BTW, for those, who want to assure the quality their JavaDoc manually,
this will fail if there is any problem in JavaDoc:
mvn clean install -Prelease -Djavadoc.doclint=-Xdoclint:all
The variant without -Djavadoc.doclint=-Xdoclint:all will just output all
warnings and will not fail:
mvn clean install -Prelease
Best,
Peter
[1]
https://github.com/hawkular/hawkular-parent-pom/blob/a0e3a27165b140bbe4b6...
[2]
https://github.com/hawkular/hawkular-parent-pom/commit/6acd616c53d0f1a14a...
9 years, 6 months
Hawkular Metrics 0.4.0 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.4.0 of Hawkular Metrics. The release is anchored by new Counter metric implementation, various stability enhancements, and Grafana integration updates.
Release Updates
There was an email thread on Hawkular Devel List about 1 week ago that announced some minor changes to the release process for Hawkular Metrics. This release is the first to apply the plan. Going forward, the project will follow JBoss Project Versioning (https://developer.jboss.org/wiki/JBossProjectVersioning) guidelines.
To avoid confusion here is an explanation of the release version number. The current release 0.4.0.Final contains the code that was initially planned under 0.3.5. The version bump was required to align the release version with the release mechanics. But there are no surprising commits or changes in functionality that were not expected to be released.
Here is a list of major changes in this release:
1) Documentation
* Added a new, Metrics specific, documentation section on the Hawkular website
* Installation, configuration and Grafana integration are covered
* Link: http://www.hawkular.org/docs/components/metrics/index.html
2) External Integration
* The Grafana graph panel editor is now able to autocomplete the metric name
* Documentation regrading the Grafana integration is now covered by the official Hawkular Metrics documentation (see above)
* Heapster versions 0.14.0 and up can use Hawkular-Metrics as their time series data storage.
3) Updates to core API** (https://issues.jboss.org/browse/HWKMETRICS-113)
* Metric is now a concrete type. GaugeMetric and AvailabilityMetric classes have been removed.
* The new DataPoint class replaces the former GaugeDataPoint and AvailabilityDataPoint classes.
* All of the new model classes are immutable. We will continue refactoring to make model classes immutable.
* Swagger and Jackson dependencies have been removed from core
4) Cassandra
* Cassandra Java driver upgraded to version 2.1.6 (https://issues.jboss.org/browse/HWKMETRICS-109)
* Embedded Cassandra is no longer part of the Hawkular Metrics
* Cassandra is now an integral part of Hawkular Project
* Embedded Cassandra has been moved to Hawkular Commons(https://github.com/hawkular/hawkular-commons) repository
* For now, will keep including the compatible embedded jar distribution as part of the release downloads
* NOTE: the embedded Cassandra should only be used for testing, debugging, or developing Hawkular Metrics. In production environments please use a full Cassandra deployment.
5) Updated Counter Metric (https://issues.jboss.org/browse/HWKMETRICS-53, https://issues.jboss.org/browse/HWKMETRICS-59)
* Core and REST APIs support reading/writing counters
* Core API supports generating and reading rates
* REST API for rates will come in next release
6) Developer tools
* Gatling load testing scenario added
* Source code: https://github.com/hawkular/hawkular-metrics/tree/master/load-tests
* This is part of the on-going effort for testing and performance profiling
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.4.0
JBoss Nexus Maven artifacts:
http://origin-repository.jboss.org/nexus/content/repositories/public/org/...
Jira release tracker:
https://issues.jboss.org/browse/HWKMETRICS/fixforversion/12327451/
Hawkular Metrics 0.5.0 & Beyond
1) Gauge Aggregates - Long-term storage of numeric metrics at the expense of losing some fidelity. With task queue released in 0.3.4, the expectation is to start the actual implementation 0.5.0.
2) Update REST testing - while the current set of tests is a good gauge for regressions, the overall coverage is still low.
3) Improved docker and kubernetes support - this is a long term goal for the project
4) The counters will received improved REST API support
5) Initial support in the Python & Golang clients for counters
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Jirka Kremser, and Heiko Rupp for their project contributions.
Thank you,
Stefan Negrea
Software Engineer
9 years, 6 months
Alerts API
by Artur Dryomov
Hi everyone,
I’m trying to use Hawkular API with AeroGear for Android.
Just to remind everyone, the Hawkular Alerts API uses HTTP PUT requests for actions such as resolve and acknowledge. Affected alert IDs are passed as a HTTP query parameter. As such, if I want to resolve an alert with ID “oops”, I need to do the following request:
http PUT :8080/hawkular/alerts/resolve?alertIds=oops
At the same time, AeroGear uses PUT requests more traditionally, appending model ID to the request URL so it looks something like “hawkular/alerts/resolve/oops”. As a result, I have no ability to use Alert actions using AeroGear, because there is no real way to customise the behaviour the easy way.
The goal of this message is to start the discussion around this topic and maybe decide what is better to do from Hawkular or AeroGear side. I’m adding Daniel and Summers to the discussion as AeroGear Android developers, maybe they can elaborate a little and provide ideas and / or details.
Artur.
[1]: http://www.hawkular.org/docs/rest/rest-alerts.html <http://www.hawkular.org/docs/rest/rest-alerts.html>
9 years, 6 months
WF 9 upgrade
by Thomas Heute
We have to upgrade to WF9 to get more data out of WF9.
there are quite some changes to be made:
- Parent declares the version of WF to use and BOM:
here is my branch:
https://github.com/theute/hawkular-parent-pom/commits/HAWKULAR-244
- Accounts need to upgrade to KC 1.3 (to be released this week)
Juca will work on this
- Bus/Nest needs to adapt
here is my branch
https://github.com/theute/hawkular-bus/tree/HAWKULAR-232 (needs another
patch from Mazz)
- Agent also needs some changes.
WF 9 GA is supposed to go out at any point now, let's try to coordinate
around that, if you have a release pending, think of that.
BTW, I tried to reflect the dependencies between component, would have
been easier if everyone could respect our standards, in particular:
- declare all dependencies at the root pom
- use <version./groupid/> in pom properties.
So please fix this if you do not follow those basic rules.
PS: for the upstream project, it is ok if all dependencies don't fully
align, for instance 2 components could depend on 2 different versions of
the parent.
Thomas
9 years, 6 months
