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
Bug 1017961 - JMX Plugin can fail testing for registration
by Elias Ross
Hi, I'm sorry if I'm posting to the wrong place.
But to me it's a somewhat serious bug and I don't really follow the
internal details for the MBean/JMX connection management.
https://bugzilla.redhat.com/show_bug.cgi?id=1017961
What I observe is when restarting, say, Tomcat but not the agent, several
child resources such as the Tomcat Connector are marked as down. The
exception seen is an RMI exception saying connection refused.
What fixes this:
1. Restarting the agent
2. Uninventorying the resources and forcing discovery
What I suspect is happening is something is being cached. Would something
like EmsConnection.refresh fix this?
10 years, 6 months
Storage Node Admin UI Changes - [Bug 1016175]
by Stefan Negrea
Hello Everybody,
We've been working on a redesign of the Cluster Settings tab (Storage Admin UI) in the context of BZ 1016175. The screen turns out to be fairly complex from a user perspective because of the way settings get applied. In the short term only the password will be propagated to the Storage Cluster, while other settings will only be update in the RHQ system settings.
The server-side work for BZ 1016175 is complete, but we need feedback for the UI changes.
Here are the steps we plan on taking today to convey how settings are applied and be prepared for the future:
1) Group the settings into three settings sections: Cluster, New Deployments, Credentials
2) Add extra verbose description to each field and the title of the section
3) Make fields that are not updateable today as read-only
4) The screen has only one Save button
New Cluster settings tab (groups + fields + description):
1) Cluster Settings
Description: On save these setting will not be propagated to existing Storage Nodes. Please review the documentation on how update the CQL and Gossip ports for all Storage Nodes.
- CQL Port - Port on which the Storage Nodes listen for CQL client connections. <b>Warning:</b> if this setting does not match the configured Storage Cluster CQL port, the server will NOT be able to communicate with the Storage Cluster and will go into maintenance mode.
-Gossip Port - The port used for internode communication in the Storage Cluster. <b>Warning:</b> if this setting does not match the configured Storage Cluster Gossip port, any new Storage Nodes will NOT be able to communicate and be part of the existing Storage Cluster.
2) Deployment Settings
Description: Only applies to new installations.
- Automatic Deployment - If this is set, the newly installed storage nodes will be automatically deployed to the storage cluster.
3) Credentials Settings
Description: Password changes are propagated to the Storage Cluster and all HA servers.
- Username (read-only) - Username for Storage Node CQL authentication. This property is read-only because changes are not allowed.
- Password - Password for Storage Node CQL authentication. Change will get propagated to the all deployed Storage Nodes and applied to newly installed nodes. All HA servers will have storage cluster sessions refreshed automatically to use the new password.
- Verify Password - Validation (needs to match Password)
For the future:
1) Updates to the CQL port, Gossip Port, and username will be propagated to the entire storage cluster automatically from the RHQ server.
1) When the feature to propagate port changes is implemented, the warnings and verbose descriptions will be replaced with something similar to the Password field.
2) When the username changes will be allowed, the text for the will be changed to something similar to the password field.
Any feedback is greatly appreciated.
Bug - https://bugzilla.redhat.com/show_bug.cgi?id=1016175
Fix Branch - https://git.fedorahosted.org/cgit/rhq/rhq.git/log/?h=bug/1016175
Thank you,
Stefan Negrea
Software Engineer
10 years, 6 months
what to remove to solve a problem
by jean-frederic clere
Hi,
I have:
+++
2013-10-14 17:15:46,282 DEBUG [InventoryManager.discovery-1]
(rhq.core.pc.inventory.InventoryManager)- Resource has a bad config,
waiting for this to go away: Resource[id=10234,
uuid=f4e433a7-98bd-4438-bf16-893bf1b79084, type={Tomcat}Tomcat
Connector, key=Catalina:port=8011,type=Connector, name=?-8011,
parent=Tomcat (8082)]
+++
What should I remove (in the database) to get ride of that problem?
Cheers
Jean-Frederic
10 years, 6 months
change to runtime jre properties
by Jay Shaughnessy
We had some issues where the runtime JRE being used was not always the
intended JRE. At times we mistakenly fell back to JAVA_HOME, or even
the JRE found on PATH. As part of correcting those issues we've also
simplified our approach to specifying the JRE used for running the RHQ
components.
As of now the RHQ_SERVER_JAVA_XXX and RHQ_AGENT_JAVA_XXX properties are
deprecated (although backward compatility will remain with no end
planned). Also, we had documented the use of embedded JRE's in some of
our script file descriptions/comments. That has been removed as we do
not support/supply any embedded JREs.
We now support, in order of precedence:
RHQ_JAVA_EXE_FILE_PATH
RHQ_JAVA_HOME
JAVA_HOME
We never fall back to PATH settings. The specified JRE will be applied
to all RHQ components for that environment. The new properties will
supersede the use of old properties if both are set.
Please let me know if you encounter any issues, thanks, Jay
10 years, 6 months
Package changes in coregui - CLEAN BUILD recommended
by Jay Shaughnessy
For Windows uncompress we needed to shorten the path lengths in our zip
distro. The main offender was coregui. As such we decided to shorten
the package structure for the coregui classes. We've compressed
org.rhq.enterprise.gui.coregui to org.rhq.coregui.
There have also been changes to portal war and server jar. And to
support the package change, some deployment changes were necessary.
*** I suggest for dev builds that you clean your current dev-container
and then do a CLEAN BUILD FROM THE TOP. ***
Unfortunately, with the renaming the git history gets a little
disconnected. 'git log' will show you only up to the rename. But 'git
log --follow' should show you the older history as well. Please let me
know if you see anything at all you suspect may be related to these
changes. Thanks,
-Jay
10 years, 6 months
AUTO: David A. Webster is on vacation (returning 10/14/2013)
by David A. Webster
I am out of the office until 10/14/2013.
On vacation for the week...
Note: This is an automated response to your message "Re: Package changes
in coregui - CLEAN BUILD recommended" sent on 10/6/2013 8:10:49 PM.
This is the only notification you will receive while this person is away.
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
10 years, 6 months