[GSoC] Hawkular Android Client: Weekly Report #5
by Artur Dryomov
Hi everyone,
This year I am working on the Hawkular Android application as part of the
Google Summer of Code 2015 program.
I’ve spent the last week mostly on combining things together and little
polishing.
The authorization screen was tweaked a bit to include better information
about requirements to run the application. The navigation drawer is fully
working at this point. I’ve prepared a PR with proper state saving between
orientation changes, helpful error and empty layouts and more [1]. At this
point I finally can say that the application is kind of usable. Well, more
or less. You can take a look at screenshots yourself [2].
I have several things in plans to work on, including fixing some
authorization issues (the server side suddenly decides to return Not
Authorized sometimes, I suspect it is related to OAuth token expiration),
adding some abilities such as logging out, sorting and ranging alerts and
metric data. I’m open to other suggestions, feel free to contact me or just
file an issue!
Have a nice week!
Artur.
[1]: https://github.com/hawkular/hawkular-android-client/pull/25
[2]: https://github.com/hawkular/hawkular-android-client/wiki/Design
10 years, 5 months
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.
10 years, 5 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
10 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
10 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
10 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...
10 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
10 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>
10 years, 6 months
