RHQ 4.13 release notes
by Heiko W.Rupp
Hey,
please go though https://docs.jboss.org/author/display/RHQ/Release+Notes+4.13 and edit as you see fit.
I will add the list of changes since 4.12 later, as editing becomes harder with more stuff on the page.
--
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, 5 months
[rhq.next][inventory] Kickoff meeting minutes
by Lukas Krejci
Hey,
in the name of doing stuff in public I'm sharing the meeting minutes from the
first, non-public by my mistake, meeting about the inventory of the yet to be
named RHQ.next.
We mainly discussed the proposed design document
https://docs.google.com/document/d/1GNsKZvCebauYFg1ML3FUXZhXF3BPOip9fJiE5...
and came to the following conclusions (which will be incorporated into the
document):
* as of now we are going to keep the nomenclature as it existed in the RHQ but
we will be renaming stuff where we see fit and find a better alternative.
* we're introducing some new names already though:
- feed: anything that is able to send data to RHQ. The classical RHQ agent is
an instance of a feed but feeds are a more generic term and we anticipate
there being many types of them.
- proxy feed: is able to collect data from other feeds and transform, enrich
or pre-process them before sending them on up to the server (or another proxy
feed).
* inline with rhq-metrics, we'll be supporting tenants. Most likely tenants
will be completely separate without any sharing of data possible between them.
* Feeds will have to authenticate to prevent spoofing. How are they going to
do it is yet to be defined. The authentication will not be used as a means of
identification, meaning that multiple feeds will be able to share the
credentials.
* Feeds will have to be able to remember their server-assigned unique ID. This
does not mean that EVERY feed needs to be able to do that. This just means
that the feeds that directly communicate with the serve will have to be able
to do it. It is conceivable that a simple in-app monitoring code will not be
able to do this, but it is then assumed that this code sends the data to a
proxy feed that is able to do so.
* we need to work on the definition of and workflows involving a resource type
or data type. This is a crucial piece of metadata that adds value to the raw
"numbers" sent up by the feeds.
* The feeds will have different set of capabilities and we will define
appropriate workflow and feature sets ranging from a "dumb feed" sending only
monitoring name=value,timestamp triplets to a full-blown agent that is able to
perform all kinds of functions supported by RHQ including operation
executions, configuration and monitoring.
* We are unsure about the provisioning aspect of RHQ. While we clearly see the
utility of it, we're not sure whether it is in the scope of RHQ itself or
whether it is complex enough to deserve a dedicated solution with which RHQ
would integrate in some way.
Thanks,
Lukas
9 years, 5 months
[rhq.next] Using assert-j in tests
by Thomas Segismont
Hi,
Last week I submitted a PR "Rest test: don't rebuild rest war over and
over again when Arquillian @Deployment method is executed" [1]
As part of the changes, I added a new test dependency to assertj [2]
Before the PR can be merged, do you all agree to use this? It's only a
test dependency.
Here's what I like:
* write assertThat(testedObject) and then use code completion to find
the method you need
* nice fluent API
```
WebArchive[] webArchives = ...;
assertThat(webArchives).isNotNull().isNotEmpty().hasSize(1);
```
This reads much better IMO that the equivalent with base
assertNull/assertFalse/assertEquals
There's a good descriptions of features on the project site [2].
Regards,
Thomas
[1] https://github.com/rhq-project/rhq-metrics/pull/72
[2]
http://joel-costigliola.github.io/assertj/assertj-core-features-highlight...
9 years, 5 months
[checkstyle] what I do not like
by John Sanda
I am not opposed to using checkstyle, but I am not as keen on it as I may have been in the past for reasons like this,
[INFO] Starting audit...
/Users/jsanda/Development/redhat/rhq-metrics/metrics-core/src/test/java/org/rhq/metrics/impl/cassandra/MetricsServiceCassandraTest.java:170: Line has trailing spaces.
Audit done.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ————————————————————————————————————
And what is line 170 in my working copy of MetricsServiceCassandraTest.java? It is a comment that I just added to make more clear the intent of the next couple lines in the test. I hope we keep the checkstyle rules liberal, i.e., not too specific, in order to minimize stuff like this.
9 years, 5 months