Need advice about agent plugin design
by Steven North
I am trying to design an RHQ/JON agent plugin to manage a software
resource with the following characteristics:
- there is the software itself (the installation);
- there are a variable number of "bundles" of configuration information
about 250KB in size each which need to be read from and written to the
agent; and
- there are "log" files which can 10-50MB in size each which need to be
read from the agent.
I think I am pretty clear on how to handle the software itself--just
like any number of other agents.
I am not sure how to handle the configuration bundles and the large log
files.
We might want to have the RHQ/JON server manage different versions of
these configuration files and distribute them to multiple remote agents.
Is there some existing domain object that would handle the read/write
aspect of the configuration bundles (zip files)? Could the "package"
concept be used for these? Would we need to create a new domain object
on the server side for these bundles? If so, is there an example of
this kind of thing?
For the log files, I see some mention of the SupportFacet. Would this
be appropriate for retrieving large log files? Is there an example of this?
We expect to access the configuration bundles and the log files using
remote client operations because we have a separate GUI tool to
build/edit the configuration bundles and to correlate and analyze the
log files. Is there an example of using a remote client to pull files
from and push files to remote agents?
Thanks in advance for any advice you can give or examples you can point to.
Steve
10 years, 1 month
MeasurementUnits (EPOCH_MILLISECONDS, EPOCH_SECONDS)
by Jiri Kremser
Hi,
in plugin descriptor, there can be a metric definition with unit type "epoch_milliseconds" or "epoch_seconds" (rhq-configuration.xsd allows it). What kind of metric should could be represented by epoch_milliseconds? Shouldn't the exact time moments (what values epoch_milliseconds represent) be addressed rather by traits?
I am asking because the values of this type are not formatted (https://bugzilla.redhat.com/show_bug.cgi?id=857144).
I think these two unit types should be removed from MeasurementUnits and xml schema, however there might be some plugins out there using it, so what about deprecation? Are there any edge cases, when these unit types do make sense?
JK
10 years, 2 months
Please run the api-checker before committing / submitting code
by Heiko W.Rupp
Hey,
when changing the signatures of existing non-private methods,
please run the api-checker job locally before committing / pushing the
change or submitting a patch. You can do that via
$ mvn -Psignature-check -DskipTests clean install
If the change is intentional, it needs to be recorded in the respective
file until the above check succeeds.
I had in EventSource. java for demonstration purposes changed the return type
for a getter from int to Integer.
The build now fails and the api checker shows:
[INFO] --- clirr-maven-plugin:2.5:check (signature-check) @ rhq-core-domain ---
[ERROR] org.rhq.core.domain.event.EventSource: Rückgabetyp der Methode 'public int getResourceId()' wurde zu java.lang.Integer geändert
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera
10 years, 8 months
RHQ Server Properties - Updates
by Stefan Negrea
Hello Everybody,
I just pushed an update that changes rhq.cassandra.* properties to rhq.storage.* in rhq-server.properties. This will not impact anybody doing full workspace rebuilds or using any packaged builds. Also, there is code in place that does the upgrade from RHQ 4.8 to RHQ 4.9.
If you are doing just partial dev-container rebuilds, you will need to manually update rhq-server.properties and run db upgrade.
Here are the changes to the rhq-server.properties:
1) rhq.cassandra.username to be replaced with rhq.storage.username
2) rhq.cassandra.password to be replaced with rhq.storage.password
3) rhq.cassandra.seeds to be split in two properties
a) rhq.storage.nodes to contain only ip addresses of storage nodes
b) rhq.storage-cql-port to contain the third sub-property of the pipe delimited string of the rhq.cassandra.seeds.
c) the jmx port from the pipe delimited properties (second sub-property) is no longer in use and should be dropped
Thank you,
Stefan Negrea
Software Engineer
10 years, 8 months
Request for code-review : bug/855674 branch
by Lukas Krejci
Hi all,
I just pushed a proposed fix for BZ 855674 (http://bugzilla.redhat.com/show_bug.cgi?id=855674) which should rid us of the "PageList was passed an empty collection but 'totalSize' was X" exception.
It is a single commit:
https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=1d42a95908a01c09...
The fix, while not that complex, has far-reaching consequences - instances at which the exception would previously be thrown are now considered legal and a method is added to see if indeed there was something more serious to worry about in the results (the states we now claim a problem actually intersect with the set of problems that the exception was thrown for, because the testing is more rigorous now than it was).
I'd like you to take a look at the (heavily commented) changes to see if a) the implementation itself is correct, but also to spot some problems with the changed behavior in the gazillion places that (indirectly) use page lists and criteria queries.
I'd like this to be part of RHQ 4.9.0, so let's hope I did my job well and we iron out all issues in time.. :)
Thanks,
Lukas
10 years, 8 months
Improving recent alerts porlet - recovering question
by Michael Burman
Hi,
While improving the recent alerts portlet with some filtering options (no,
I haven't created a BZ for this yet), I've come up with some questions.
What I've initially done is to add filtering options for not displaying
acknowledged alerts, nor recovery type (as these didn't require any complex
changes). I also wanted to filter "recovered" alerts and include a column
in the recent alerts view that indicates the alert has recovered. The
use-case for us has been some BAM alerts that quite often fix themselves
(we send these events to RHQ), and also our automatic processes that try to
patch some issues. That's when I ran into an issue.
Considering the following SQL query to find out if alerts have recovered:
SELECT id, alert_definition_id, ctime, recovery_id, will_recover, ack_time,
ack_subject,
(CASE WHEN will_recover = 't' THEN
(SELECT MAX(ra2.id) FROM rhq_alert AS ra2
WHERE ra.ctime < ra2.ctime AND ra.alert_definition_id =
ra2.recovery_id) END) AS recovered_by
FROM rhq_alert AS ra
ORDER BY ctime DESC
I then hit my head against the CriteriaQueryBuilder and related data source
stuff, and could use some hints how to get this sort of things working with
the JPA implementation in this case. Then I read the BZs and noticed there
are already issues with performance with large number of alerts (this would
require new index to be efficient), and also assuming RHQ might some day
store alerts on something else than relational store, and wondered should I
instead process this on the write-path?
Adding new field to the alert table, indicating which alert recovered it,
or just a boolean like the "will_recover"-column. This creates one update
clause on the alert writing process, but saves I/O on the reading-path.
Opinions? This would also make the "recovered_by" id a real one, not the
latest one like in my SQL query (a small shortcut).
These also bring me to an UI question. Two of these filters are "status"
filters, (acknowledged & recovered) while one is "type" filter (recovery
alerts). Should these be in a same dropdown menu? Will the UI run out of
space soon if recent alerts has a lot of options in the upper part?
And continuing this, while I can do view -> dynagroups -> alerts and view
only those alerts, I can't do this to a dashboard. Any reason why? I know
the dashboard is very static and could use a lot of work, but I'd really
hope for usability reasons, that any view I can find in the RHQ, I could
also apply to my dashboard. I don't know if this is technically possible in
current GWT/SmartGWT structure, but I'd like to know. It would be seriously
.. useful.
- Micke
10 years, 8 months
Cassandra user group presentation
by John Sanda
Some one posted a presentation[1] by Jonathan Ellis from the August user group in Austin, TX. For those unfamiliar with him, Jonathan Ellis is the Cassandra project lead and CTO of DataStax. It runs for about 1.5 hours but is really informative. He covers things introduced in 1.2.x as well as new features in 2.0 like triggers and light weight transactions.
[1] http://youtu.be/sJJzDB9RhzA
10 years, 8 months
Storage Cluster Password Obfuscation
by Stefan Negrea
Hello Everybody,
I just pushed an update that introduces password obfuscation for storage node credentials [1]. The obfuscation mechanism is identical to the one used for SQL credentials. The update requires rhq-server.properties to have an obfuscated password for "rhq.casssandra.password" property.
The password will be automatically set to the default obfuscated version on a full dev-container rebuilt. However, if you do not plan on doing a full dev-container rebuild anytime soon but you rebuild the server/jar module you will need to manually update the server properties file with an obfuscated version of the storage node password. Here are the steps to manually update a dev-container:
1) Run rhq-installer.sh with --dbpassword argument (or the new addition --encodepassword if you've rebuilt the installer) and note the obfuscated version of the password.
2) Update rhq.cassandra.password property in the rhq-server.properties file with the obfuscated password.
Please let me know if you need any help with updating the dev-container or have any issues with the password obfuscation.
[1] https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=7371e80747cbf082...
Thank you,
Stefan Negrea
Software Engineer
10 years, 8 months
dbsetup goof
by Heiko W.Rupp
Hey,
I've checked in a change to dbsetup this morning (v2.136/137), and made an error with respect to
the case of expressions in 2.136 (and I meanwhile found another issue in the original code).
If the server complains about an unknown word "unlimited" for PropertyOptionsSource,
and/or fails to deploy the AS7 plugin,
you should run:
ALTER TABLE rhq_config_pd_osrc
ALTER COLUMN expression_scope TYPE character varying(15);
UPDATE RHQ_CONFIG_PD_OSRC
SET EXPRESSION_SCOPE = 'UNLIMITED'
WHERE EXPRESSION_SCOPE = 'unlimited';
in a SQL editor of your choice
If you have are still running db version 2.135 , you should hopefully be fine (keep fingers crossed).
10 years, 8 months
New expressionScope attribute for option-source node in RHQ configuration schema
by Thomas Segismont
Hi everyone,
I just pushed some changes which introduce a new expressionScope
attribute for option-source node in RHQ configuration schema. It will
allow plugin developers to narrow down expression search results. Its
value must be one of 'none' or 'root'.
'none' means that search results may include any resource in inventory.
'root' narrows down results to resources under the same top level server
or service.
This change was necessary to fix Bug 956329 - Create new Managed Server
using EAP 6 plug-in exposes server groups and socket binding groups from
other resources.
The changeset is here:
https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=bug/956329&id=920...
Any comments?
Thanks and regards,
Thomas
10 years, 8 months