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
RHQ usage of SEAM and AS7 integration
by John Mazzitelli
OK, after looking at this, it appears the first major stumbling block for the AS7 work is our usage of SEAM and how we can run in AS7.
Here's the issue - it appears we are using an older version of SEAM that does not work on AS7. We simply can't use the SEAM we were using. This is not surprising at all (see example threads of similar issues we have or will have: https://community.jboss.org/message/608573#608573 - https://community.jboss.org/blogs/marek-novotny/2011/12/16/dvdstore-migra... ).
What I think we need to consider is one of the following:
a) rip out SEAM entirely and all code in RHQ using it/depending on it (this includes mainly core/gui and enterprise/gui/portal-war modules but also this content_http thing that i dont think we need/should have/is used)
or
b) refactor our GUI code (portal war) to either not use SEAM or to make use of a newer SEAM that can be deployed inside of AS7
Now - if we do b) it means there will be a lot of effort wasted for very little gain. Most of portal-war isn't even used anymore - our GWT UI handles the vast majority of UI features now. So if we do b) its merely work that isn't even going to be used - it will be just so we can successfully deploy the RHQ ear only to later rip out portal war at some point anyway. Now, I can't say how much effort it will take to do b), but clearly, the new SEAM isn't backward compatible with the old - I'm seeing missing classes and things like that at startup. We'd have to integrate with the latest SEAM libraries and all that would entail (e.g. refactoring code perhaps)
But we can't blindly do a) either - all of portal-war is not obsolete - there still are small portions still used (graphing and the content UI are the two main areas that I know still use portal-war - there is also that old content_http servlet thing). Graphing pages, IIRC, are actually still on the old struts stuff - so I'm not even sure if JSF is even used, let alone SEAM. We'd have to investigate that. The content UI I think does use code that relies on SEAM. So ripping out portal-war isn't going to be like ripping off a band-aid - it will still require some delicate maneuvering.
The third option I would like to discuss is porting the rest of portal-war to GWT. Rather than waste time doing b), I think we can take that time and do more useful things that have to get done anyway - that is, port over the final pages in portal war to GWT. Thus, when we do that, I think we can do a) more quickly and without worrying about doing too much damage. The only thing that I think we'd have to look out for are simple things like StartupServlet (which we can easily port into a startup servlet in the GWT app or make a singleton EJB, which is new in EJB 3.1 and is now supported because we'd be on AS7)
Thoughts?
11 years, 4 months
Content vs Bundles
by Lukas Krejci
The following is a new meeting request:
Subject: Content vs Bundles
Organizer: "Lukas Krejci" <lkrejci(a)redhat.com>
Time: Monday, December 3, 2012, 4:00:00 PM - 5:00:00 PM GMT +01:00 Belgrade, Bratislava, Budapest, Ljubljana, Prague
Invitees: rhq-devel(a)lists.fedorahosted.org
*~*~*~*~*~*~*~*~*~*
A meeting to summarize the state of our content and bundle subsystems, compare and contrast them and hint at the changes we need to make to bundles if we want to make them usable for the patching of the next version of JBoss AS.
https://docs.jboss.org/author/display/RHQ/Bundles+vs+Content
The meeting will be held on Google+ hangout. If you want to attend, watch the #rhq irc channel on freenode, where I'll put the invite and/or the youtube link shortly before we start, or follow +Lukas Krejci on G+.
11 years, 4 months
Eclipse users: is hot swap working for your when debugging?
by Thomas Segismont
Hi,
I have a question for Eclipse users.
I am able to remotely debug the agent and the server. But Hot Swapping
code is not working: I always get this error message: "Scheme change not
implemented".
The only explanation I can find is that the classes were initially built
by Maven (with javac from my JDK7) and for Hot Swap Eclipse builds the
classes with its internal incremental compiler. Hence the scheme change.
Any idea? <- this is not a joke with Intellij ;)
Thanks
Thomas
11 years, 4 months
Maven Versions Plugin Issue
by Stefan Negrea
Hello Everybody,
This is a followup to the errors I recently ran into with the maven versions plugin. The project release script relies on this plugin to change the version of all project modules. This issue only exists in versions 2.0, which was just released this month. I opened JIRA MVERSIONS-201 [1] and submitted a minimal test case to the plugin community. If for some reason the issue does not get fixed, we will need to replace ${rhq.groupId} variable with ${project.groupId} or org.rhq in all project poms.
The workaround for now is to use the more stable versions 1.3.1. I already updated master to force 1.3.1 usage. Because 2.0 was just released we do not necessarily need to start using it right away.
[1] http://jira.codehaus.org/browse/MVERSIONS-201
Thank you,
Stefan Negrea
Software Engineer
11 years, 5 months
Availability check problem in OpenSSHDComponent
by Thomas Segismont
Hi,
When I filed a bug about ProcessComponent availability check
(BZ-879583), Heiko suggested I'd review other components to see if the
same problem could appear elsewhere.
I think it is also present in OpenSSHDComponent (see line 73). Once the
SSHD server is reported down, it is never reported up again (after
restart of SSHD of course).
Could someone please confirm that? Then I'll create a new BZ.
Thanks
Thomas
11 years, 5 months
Availability schedules updates don't impact agent immediately
by Thomas Segismont
Hi,
I think there is a bug in availability schedules update. When you set a
new availability schedule in the monitoring tab of a resource, the agent
keeps checking availability at the previous rate.
The agent is actually contacted by the server after the update
(MeasurementManager.updateCollection).
But in this method only measurement schedules get taken into account
(the availabilitySchedule is separated from measurementSchedules in
ResourceMeasurementScheduleRequest, see comment lines 40-43 of the class)
When the inventory is synchronized (agent restart AFAIK, but there is
maybe a job to do that regularly ?) then the availability schedule is
properly set.
If it's really a bug (I mean if it's expected to get availability
schedules sent to agent just as measurement schedules do) I will file a
bug in BZ and propose a fix.
What do you think?
Thanks
Thomas
11 years, 5 months
!Important! Master updated to AS7.1.1.Final
by Jay Shaughnessy
RHQ Developers,
Today we merged the rhq-on-as7 branch into master. With this change we
make a big leap from having RHQ run on AS4.2.3 to AS7.1.1.Final. Many
details about this migration can be found here:
https://docs.jboss.org/author/display/RHQ/Hosting+RHQ+Server+in+AS7
There are also important child pages discussing testing impact and
further changes to installation.
To make the change as painless as possible I'd suggest the following,
starting ** PRIOR TO PULLING **:
* Clean your existing environment.
1. Perform an mvn clean -Pdev,enterprise
2. (Optional) Delete your current M2 repo. I know this is painful,
but this would be a good time to start fresh as many versions
are changing.
* If necessary install Java7 and make any adjustments to make it the
version with which you build RHQ.
o RHQ now builds only on Java7
o It still supports a Java6 runtime
* If necessary, install Maven 3.0.4 and make any adjustments to make
it the version with which you build RHQ.
o RHQ should be built on Maven3, and this is the version we've
been using in the branch.
* Git pull and Build
o Use -Ddbsetup as schema specs may be confused in a dev environment
o Note, dbupgrade from RHQ 4.5 should be fine
If you have any issues please contact me (jshaughn) or mazz in #RHQ.
As for running the new RHQ Server, the scripts that you run have the
same names as before - rhq-server.sh on UNIX/Linux and rhq-server.bat on
Windows. Note that the latest code has a new installer that is GWT
based, however, now if you perform a dev build, the auto-installer is
preconfigured and will run for you the first time you start the server.
Also note that the intention is that the GWT installer will be going
away - it was a stop-gap measure until we get a new installation
procedure put in place. If you do a production/release build, you will
need to go to the GWT installer and finish the installation prior to
being able to use the new server - the GWT installer is at
http://localhost:8080/rhq-gwt-installer once you have the server running
for the first time.
Jay and Mazz
11 years, 5 months