Aggregated Hawkular REST api
by Jiri Kremser
Good news everyone,
I was finally able to open the pull request [1] with first shot of the new rest api module for Hawkular. It's goal is to simplify the overall api, in which each component/microservice has very fine-grained api.
Currently it can't do much. All it does is manipulation with URls, but if you look into our current UI code here: http://git.io/v0I9p the addUrl function takes 248 LoC. It's creating a resource, computing md5 hash, creating 2 metrics, creating bunch of triggers with dampenings and conditions. Quite a lot.
The drawback with this approach, where UI layer works as an integration layer, was visible during the android client creation. Artur had no idea why he needs to mimic all the logic that was already there in JavaScript.
Module uses the Hystrix library, because it seems to be a great fit for api aggregation. It's heavily rx-java based and it supports the Circuit Breaker pattern that can help if the components are under heavy load. Similarly, like rx-java it takes quite a while to wrap your head around the concepts of reactive streams, though. Hopefully, it's not an overkill. Perhaps we can even closer integrate with their metric features [2].
[1]: https://github.com/hawkular/hawkular/pull/704
[2]: https://github.com/Netflix/Hystrix/wiki/Metrics-and-Monitoring
jk
8 years, 11 months
Hawkular Alpha 8 still on WF 9 !
by Heiko W.Rupp
Hey,
as this may be unclear:
We will do the Hawkular 1 alpha 8 release on WF 9 (as before)
and only move to WF 10 after the release - no matter if WF 10
will be released until then.
Heiko
8 years, 11 months
agent can now periodically perform discovery scans
by John Mazzitelli
FYI.
The Hawkular WildFly Agent can now be configured to perform automatic discovery scans periodically. By default, the agent will perform auto-discovery every hour. You can make this more frequent or less frequent by adding the "autoDiscoveryScanPeriodSecs" to the agent's top level <subsystem> element in standalone.xml. It is specified in seconds as the name implies (again, default is 3600 == 1 hour). If you set this value to 0, auto-discovery will be disabled and the agent will act just like it acts now (performs an initial scan at startup to get the inventory, but that's it).
That is all.
8 years, 11 months
Cancelled: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1
by Michael Foley
A single instance of the following meeting has been cancelled:
Subject: Discussion, Planning, and status on Testing Openshift & Hawk-Metrics Integration for Openshift 3.1
Organizer: "Michael Foley" <mfoley(a)redhat.com>
Location: Bluejeans http://www.bluejeans.com/mfoley51
Time: Wednesday, December 9, 2015, 3:00:00 PM - 3:30:00 PM GMT -05:00 US/Canada Eastern
Required: pruan(a)redhat.com; mmahoney(a)redhat.com; vnguyen(a)redhat.com; snegrea(a)redhat.com; jsanda(a)redhat.com; mwringe(a)redhat.com
Optional: jon-qa-list(a)redhat.com; jboss-on-team(a)redhat.com; hawkular-dev(a)lists.jboss.org
*~*~*~*~*~*~*~*~*~*
Hi,
Let's have a discussion and planning session on testing Openshift & Hawkular Integration!
Let's use this etherpad to coordinate the discussion -->> http://pad.engineering.redhat.com/Management-nextAndOpenshiftTestPlanning
5 Point Plan for Openshift 3.1 GA
* Unit tests .... owned by Hawk-Metrics developers
* Integration tests ... owned by Hawk-Metrics developers and Hawk-Metrics QE
* Performance CI on Hawk-Metrics (this one is actually new and was not discussed on Wednesday , but I now see it makes sense)
* Functional Integration tests on Hawk-Metrics latest + Openshift Origin latest
*
Funtional/UI .... Cucumber/Ruby tests ...owned by Openshift QE * Functional/Rest ... Cucumber/Ruby tests ... owned by Openshift QE
* Performance & Scalability .... owned by Openshift QE
Regards,
Michael Foley
QE Supervisor, Middleware BU
8 years, 11 months
Fwd: [hawkular-ui-services] Slash hell: Preserving the encoded slashes in the resource ids. (#71)
by Heiko W.Rupp
Before we implement this - should we finally
go and ban characters that are not valid in URIs
in a literal way (see RFC 2396)?
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
Also:
2.4.3. Excluded US-ASCII Characters
control = <US-ASCII coded characters 00-1F and 7F hexadecimal>
delims = "<" | ">" | "#" | "%" | <">
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
Data corresponding to excluded characters must be escaped in order to
be properly represented within a URI.
> From: Jirka Kremser <notifications(a)github.com>
> To: hawkular/hawkular-ui-services
> <hawkular-ui-services(a)noreply.github.com>
> Subject: [hawkular-ui-services] Slash hell: Preserving the encoded
> slashes in the resource ids. (#71)
> Date: Fri, 04 Dec 2015 06:53:17 -0800
>
> Currently the interceptor replaces all the encoded slashes to the
> simple ones, but we need to have the way to pass the encoded slash in
> the resource id. If the resource id is manually encoded with
> window.encodeURI() and then angular does it once more for the
> 'percent' symbol, it ends up as '%252F' here we turn it back to simple
> '%2F' for which the inventory backend is prepared. In short: '/' are
> allowed as resource separators: r1/r2/r3 and '%2F' are allowed in the
> resource ids: r%2F1/r%2F2
>
> @ammendonca could you please check?
> You can view, comment on, or merge this pull request online at:
>
> https://github.com/hawkular/hawkular-ui-services/pull/71
>
> -- Commit Summary --
>
> * Preserving the encoded slashes in the resource ids. Currently the
> interceptor replaces all the encoded slashes to the simple ones, but
> we need to have the way to pass the encoded slash in the resource id.
> If the resource id is manually encoded with window.encodeURI() and
> then angular does it once more for the 'percent' symbol, it ends up as
> '%252F' here we turn it back to simple '%2F' for which the inventory
> backend is prepared. In short: '/' are allowed as resource separators:
> r1/r2/r3 and '%2F' are allowed in the resource ids: r%2F1/r%2F2
>
> -- File Changes --
>
> M src/rest/hawkRest-inventory-provider.ts (10)
>
> -- Patch Links --
>
> https://github.com/hawkular/hawkular-ui-services/pull/71.patch
> https://github.com/hawkular/hawkular-ui-services/pull/71.diff
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/hawkular/hawkular-ui-services/pull/71
8 years, 11 months
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, 11 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, 11 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, 12 months
