Where should integration components live?
by John Sanda
Currently integration components, particularly those that interact with the bus, live in the respective component repos. I have been working with Peter on HAWKULAR-844 to migrate the bus from ActiveMQ to the default messaging subsystem in WildFly 10, which is based on ActiveMQ Artemis. While working on this, I started to wonder if all of the integration components should live in the same repo. Let’s say I make a breaking change in the bus, then we have to update and cut releases for each of the component repos, which is currently five or six. If the integration components live in the same repo as the bus, it is much easier to make the changes and we only have one new release to worry about. Keeping the integration components in the same repo should also help reduce the number of dependencies in each of the component repos which makes development on any one of them easier. I want to know what people think because once HAWKULAR-844 is done, I would like to consider some refactoring in the bus code to utilize JMS 2.0 APIs including support for async sending/receiving messages. This would likely entail breaking changes.
- John
8 years, 4 months
Hawkular Metrics 0.6.0 - Release & Beyond
by Stefan Negrea
Hello Everybody,
I am happy to announce release 0.6.0 of Hawkular Metrics. The release is anchored by enhancements for counter metrics, updates to the container infrastructure, and overall performance and stability enhancements.
Here is a list of major changes in this release:
1) Querying
* Metrics can now be searched with regexp filtering capabilities on tags
* Metrics queries now support logical AND for tags
2) Internal
* TenantId and type were moved to the MetricId instead of Metric class
* Implicit tenants (not manaully created prior to sending first set of metric data) are now created on metrics insertion
3) Container
* Updated to the latest Heapster version (0.17)
* The communication between the Hawkular Metrics and Cassandra containers have now been secured. This means that only Hawkular Metrics can communicate with its Cassandra containers.
4) Counters
* Per-minute rates can be retrieved via the /hawkular/metrics/counters/{id}/rate endpoint.
5) Task scheduling
* The scheduler API and schema has undergone several changes. It is now possible to group related tasks so that order of execution can be controlled when there are interdependencies. There is still ongoing work to support asynchronous job execution and to provide fault tolerance.
6) Ruby Client
* The project has now an official Ruby client, this joins the existing Go and Python clients. One of Hawkular Metrics' objectives is to be easy to integrate with; providing language specific clients is an important component for fulfilling this objective.
Hawkular Metrics Clients
* Ruby: https://github.com/hawkular/hawkular-client-ruby
* Python: https://github.com/hawkular/hawkular-client-python
* Go: https://github.com/hawkular/hawkular-client-go
Github Release:
https://github.com/hawkular/hawkular-metrics/releases/tag/0.6.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/12327689/
Hawkular Metrics 0.7.0 & Beyond
1) Gauge Aggregates - The task scheduling work is now in place to enable server side aggregates at ingestion. The expectation is to release an initial implementation for this feature in 0.7.0.
2) Improved docker and kubernetes support - this is a long term goal for the project
3) Support for counters in Python & Golang clients
A big "Thank you" goes to John Sanda, Thomas Segismont, Mike Thompson, Matt Wringe, Michael Burman, Libor Zoubek, Jirka Kremser, and Heiko Rupp for their project contributions.
Thank you,
Stefan Negrea
Software Engineer
8 years, 4 months
Travis Integration Tests!
by mike thompson
Hey Guys,
So I think you all probably already know what I’m talking about. We have an indeterministic suite of integration tests. So, for every PR you have to submit it X times (2 to 7 is normal) before the PR can be merged and by that time it might already need to be rebased. Is this on anyones radar to look at?
-- Mike
8 years, 4 months
