[rhq.next] Java 8
by John Sanda
There was some discussion yesterday on IRC about Java 8. Since we are starting new with the rhq.next projects, I think it is worth asking/considering. Can/should we use Java 8? Is there anything that would prevent us from doing so?
9 years, 4 months
[checkstyle] extending checkstyle to xml files
by Peter Palaga
Hi *,
(I have just got accepted a PR [1] that makes checkstyle cover also test
classes which is a topic independent from the present one.)
Although checkstyle is primarily focused on Java, it is possible to let
it perform some basic checks (no tabs, no trailing whitespace) also on
other file types, such as XML.
Question #1:
Is anybody against checking no tabs and trailing whitespace in xml files?
I have a working solution [2][3] for this, but it requires a change in
the wildfly-checkstyle-config [4] artifact - an introduction of a
default empty suppressions.xml file that will allow for overriding it in
metrics submodules, e.g. in [5] and [6].
Question #2:
How do we want to introduce the change?
(a) fork wildfly-checkstyle-config or
(b) send a PR to wildfly-checkstyle-config
I vote for (a) because I find it very likely that we will want to
diverge from wildfly-checkstyle-config in more things in the future.
And finally, if (a), then
Question #3:
How should our artifact be named?
The present name in my repo is rhq-checkstyle-config. But I guess, it
should be used throughout the new alohomora family, hence a compatible
name should be taken?
Thanks,
Peter
[1] https://github.com/rhq-project/rhq-metrics/pull/71
[2]
https://github.com/ppalaga/rhq-checkstyle-config/tree/master/src/main/res...
[3]
https://github.com/ppalaga/rhq-metrics/commit/135bb9e0e6c2f09700c3dcf944d...
[4] https://github.com/wildfly/wildfly-checkstyle-config
[5]
https://github.com/ppalaga/rhq-metrics/commit/135bb9e0e6c2f09700c3dcf944d...
[6]
https://github.com/ppalaga/rhq-metrics/commit/135bb9e0e6c2f09700c3dcf944d...
9 years, 4 months
RHQ 4.13 coming and future releases
by Heiko W.Rupp
Hello,
we are thinking of releasing RHQ 4.13 pretty soonish
Two questions:
- shall we rather name it 4.14?
- what is left / needs to go in?
After that release we will concentrate more on (code name) "RHQ.next", where you have probably seen some activity already. RHQ.next will most likely to use a lot of new code and may or may not be compatible to current RHQ.
Therefor we very much value your input into current RHQ and RHQ.next to get a even better RHQ.next and also
still RHQ current.
The above does not imply that 4.13 will be the last RHQ release, but development will for sure slow down from the side of the core team, which also leaves an opportunity for the greater community to take more responsibilities and to bring RHQ forward.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
9 years, 4 months
[rhq.metrics] travis-ci build
by John Sanda
We are experiencing multiple environmental issues with the travis-ci build that is making it unstable. The last few failures were due to the DataStax driver failing to connect to Cassandra in the rest-tests module. The interesting thing though is that the driver had already established a connection. I know this because I saw log statements about schema creation. While I was going through the logs, I realized that that the rhq-metrics-rest war is deployed for each test method. That deployment also including recreating the Cassandra schema. I do not know whether or not this might be in some way contributing to the driver connection problems in the recent build failures, but it is inefficient and will only get worse. Is there a way to only deploy the web app once for the whole test suite? I thought that we did that with our server integration tests in RHQ, but I do not recall the details.
- John
9 years, 4 months
Alerts don't fire when REST is used to post data collections composed of multiple metric types to RHQ
by Van Dillon
Hi,
This is a follow up to a question I posted on 9/12 that involved using a
plugin that depends on the No-op plugin along with REST to push metrics to
RHQ. The answer to that question was that resources have to be created as
children of an agent backed platform for alerts to work.
I'm running into a different problem with alerts that involves using REST
to post data collections to RHQ. In summary, alerts don't fire when they
should when the data collection is composed of data of multiple metric
types. I've tried both of the following methods on RHQ 4.10.0 and RHQ
4.12.0:
POST /metric/data/raw
POST /metric/data/raw/{resourceId}
Both these methods almost immediately call the same code in
MetricHandlerBean on the server side, so I'll just use test results for the
schedule id based method in my examples.
Let's say I have the following metric types and alert definitions:
Metric: CPU Util (percent) Alert: CPU Util > 50%
Metric: Disk Reads Bytes Alert: none
Here are the results from a test series of randomly generated data posted
at one minute intervals:
cpu util:0.49, disk read bytes:700.0
cpu util:0.87, disk read bytes:1180.0
cpu util:0.72, disk read bytes:1210.0
cpu util:0.38, disk read bytes:969.0
cpu util:0.10, disk read bytes:806.0
+cpu util:0.52, disk read bytes:456.0
cpu util:0.09, disk read bytes:696.0
cpu util:0.75, disk read bytes:950.0
+cpu util:0.74, disk read bytes:297.0
cpu util:0.13, disk read bytes:555.0
The '+' indicates data points that triggered alerts. For the data points:
0.87, 0.72, and 0.75 no alert was triggered.
Another interesting thing happens if you add an alert for the "Disk Read
Bytes" metric: "Disk Read Bytes > 500". In this case I posted the same
test series (composed of data points that all exceed the alert threshold
for both metrics) at one minute intervals:
cpu util:0.65, +disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
+cpu util:0.65, disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
+cpu util:0.65, disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
cpu util:0.65, +disk read bytes:700.0
+cpu util:0.65, disk read bytes:700.0
Again, the '+' indicates data points that triggered alerts. As you can
see, each post causes one alert to trigger. I wanted to see if this
pattern holds up when more types of metrics are added, and indeed it does.
I added another metric called "Disk Read Ops" to the test series with an
alert defined as: "Disk Read Ops > 1000" and posted the following data at
one minute intervals:
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
+cpu util:0.75, disk read bytes:800.0, disk read ops:1200.0
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
cpu util:0.75, +disk read bytes:800.0, disk read ops:1200.0
+cpu util:0.75, disk read bytes:800.0, disk read ops:1200.0
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
cpu util:0.75, disk read bytes:800.0, +disk read ops:1200.0
cpu util:0.75, +disk read bytes:800.0, disk read ops:1200.0
The only workaround I've been able to find for this problem is to only send
a single metric type per post when using the REST methods for raw data
collections. When I do this, alerts always trigger when they should.
Thanks,
Van Dillon
9 years, 4 months
[rhq.metrics] Development Release Schedules
by mike thompson
What is going to be our strategy around development release schedules?
1) Release around features
2) Release every X weeks
3) Other
If option #2 then how many weeks?
My preference would be to release every 2 weeks so other projects can get stable releases as quickly as possible.
I was asking this question specifically in relation to rhq-metrics but this would probably apply to all the rhq.next suite.
9 years, 4 months
[rhq.next] Integration/bom project
by Heiko W.Rupp
Hello,
RHQ.next is / will be split and developed in several sub-projects on their own like rhq-metrics, rhq-msg, rhq-audit and so on.
This also means that we need a "central place" to integrate all the pieces into one.
In addition we need to make sure that the sub-projects use "compatible" versions of dependencies.
So I propose that we introduce a rhq.next project (*) that servers those two purposes
- integration of individual project
- master pom/bom for versions of dependencies
During the initial development cycle, we may need to publish that bom more often in order to
make dependency definitions available, but should be better off in the long run.
I don't know if there is a way to enforce that the individual projects don't just override the settings from the bom.
I know there are people on the list, that have done that before and can probably help with the setup.
Heiko
*) or branch inside "rhq" project if we want to keep that name
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
9 years, 4 months
[rhq.metrics] Keycloak vs. external client requests
by Juraci Paixão Kröhling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
TL;DR: is Google's "offline" token acceptable as a solution for an
external client to send data to the Metrics REST API?
https://developers.google.com/accounts/docs/OAuth2WebServer#offline
Long version:
During the presentation of the PoC for Keycloak integration, one of
the questions was about an external client sending requests to the
backend. As of now, there's no good solution for that.
I have started a discussion on keycloak-user mailing list, asking if
it would be interesting for the KC project to have some sort of
"key/secret" support for external clients, à la Amazon AWS. What
*seems* to be acceptable is the usage of "offline" tokens, as
implemented by Google:
https://developers.google.com/accounts/docs/OAuth2WebServer#offline
This would effectively mean that a client would need to perform these
steps to contact the backend:
- - read a refresh token from a permanent storage
- - request an access token to the KC server based on this refresh token
- - send the request to the backend using the access token
On the first run, these steps would also be required:
- - a client[*] would build an URL for the user to visit
- - user would authenticate against the KC server, and would see a code
as the outcome
- - this code would be entered on the client
- - client would do a first request, exchanging this code for the
refresh token
Once a refresh token is obtained, it can be reused by all nodes in a
farm/setup, so, it can be propagated to all nodes via the appropriate
methods (push from the server, puppet/chef, kickstart, ...)
My concern is that this approach would require either a good amount of
work on the external client's side to cache the access tokens or would
require 2x requests than a simple backend call (one to obtain the
access token, one to the backend itself).
So, is this "offline token" something that would be acceptable for RHQ
Metrics? Note that we could perhaps build a native CLI tool that would
do all of the above, as this is very generic. But the overhead would
still be there somewhere :-)
* this client could be anything. I imagine that we could provide this
as a bash script or java installer or something similar.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCgAGBQJUb2X1AAoJECKM1e+fkPrX8/sH/0aWMsw1IIoKw8CLe3/VnKaO
eSGukl4/dIHWXcJCG0tEJRZtIaTI7Ho4UlBrGMSuIubE4gQCf43Jv4UKz+Htex7d
2QbX0wY2A5cb3gOBU+5mF57inlbV+clrjyoOSwIm8j3pNfcz0mUcJ5rmgWIhmQHk
kHDX4b204zm9B7YtNKcs+K5gfDBXZfyOC8IpgfogRqqoqUSpE2CMuPugknHmWwCa
sRFdjgJ4qOFRbUU25o6miSOepaZiMP6kZxUW3yehg4xoB5DLyM9vO118OP1spIJg
ysxzjsIOdJfle+SSDUZoUHR1DfvCZdsb2gGEanIjg/V+6Q75a8lp5hWBnHALvac=
=n35C
-----END PGP SIGNATURE-----
9 years, 5 months