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, 2 months
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, 5 months
About Github migration
by Heiko W.Rupp
Hi,
to get some experience I tried how some migration to github might look like.
I did that with my personal GitHb account, so this is not available in
github/rhq-project (yet)
** First I basically followed the answer to this question on stack overflow
to pull stuff from FH and pushed to GH
http://stackoverflow.com/questions/5181845/git-push-existing-repo-to-a-ne...
I think for a real migration we would first do a
git fetch --all
git remote add github <github url>
and then a
git push --mirror github
This should copy the whole repository inc. all branches and tags.
We may consider pruning old tags and branches here - especially as
the FH repo is not going away.
** Then I went and cloned the repo locally and followed
http://stackoverflow.com/a/359759/100957
to separate out the modules/plugins directory into its own repo.
Created a new repo on github rhq-plugins and pushed the
plugins to this new repo
** In the third step I cloned the github rhq repository and
followed the first comment to http://stackoverflow.com/a/955793/100957
to clean out the plugins from above rhq repository and tried to push the result to github.
This whole locally cleaning "took ages"
The push failed, as the local repo and the remote have diverged.
One can use -f here to forcibly push (which I've done)
Or in an earlier step not push the rhq repo until after the split-off of the plugins.
Or in the main repo just rm -r && git rm on the plugins and have the removal
recorded in the history. This may even be faster than pruning that directory hierarchy out.
Results are now at
https://github.com/pilhuhn/rhq
and
https://github.com/pilhuhn/rhq-plugins
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
11 years, 6 months
Server side Event bus
by Heiko W.Rupp
Hi,
so the other day we were talking about agents forwarding some information out-of-band to the server
so that the messages can be shown in the message center.
We should perhaps pick that idea up and extend it in a way that the server can push
information into the UI without requiring the user to select a different tab or clicking some
refresh button.
There are many use cases for this:
- out-of band messages from agents to be shown in the message center : mark the message center button accordingly
- updating of the tree when a new child resource has been added
- updating of history pages when an entry has changed
- updating of metrics pages when new data was received
...
The general idea here is to make the UI more responsive in the sense that the
user gets actively informed and does not have to remember to manually check
here and there (and to remember to do it in case X while it is not needed in case Y).
While the above is a nice use case of Errai, I think we don't necessarily use it
for implementation; it could server as example on how to do it though.
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
11 years, 7 months
Issues in RHQ 4.5.0 identified - please don't upgrade from 4.4 yet
by Heiko W.Rupp
Hello,
we have identified two issues in the RHQ 4.5.0 release
1) on upgrade from a previous version some properties may cause Hibernate errors
2) some resources do not show child resources in their inventory tab (but in the left tree).
As 1) is serious if you don't plan to do a fresh install, we ask you to not update from
any earlier version to RHQ 4.5.0
We are currently working on fixes and will re-spin the release soon.
Heiko on behalf of the team.
--
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
11 years, 7 months
AS7 work - what should be do before merging into master?
by John Mazzitelli
I would like to ask for a consensus on what needs to be accomplished or "checked off the list" in order to consider merging the AS7 branch into master. What do you want to make sure is done/working before we move over to AS7 in master?
For example:
1) Make sure the installer sets up the app server such that you can unzip and run the server
2) Make sure the application successfully deployed with no AS7 deployment errors
3) Make sure an agent can talk to the server (that is, make sure inventory can be committed and agent/server comm works)
4) Make sure the UI loads and you can log in
We can cross off those items. This is not to say there are not still bugs in, say, the UI or elsewhere, but those basic things are done. But what about:
5) Be able to run all unit tests via "mvn test"
6) Make sure QA has run through all of their integration tests and all pass
7) Make sure the entire UI/server works just like the old app based on AS 4.2.3
8) Make sure the CLI runs and can execute everything that could execute before (Jay is working on this now)
9) Run performance testing
10) Make sure db upgrade and agent updating works
... etc...
Those items are not done. Do those items need to be done before we start asking the entire team/community to start working with the new app server infrastructure? What other items should be on this list of "must do these first before we switch everyone over to AS7".
11 years, 7 months
RHQ 4.5 released
by Heiko W.Rupp
I am pleased to announce the immediate availabilty of RHQ 4.5
Version 4.5 is another notable milestone in the development of RHQ, the
This is the first version that has been developed and tested with a Java7 JRE.
Other notable changes are
- modular CLI scripts, that allow you to import other cli scripts
- Python as CLI scripting language
- many improvements in the AS7 plugin
- support for Postgres 9.2 as backend database
- Czech translations of the UI
- Updated Sigar version
- Further improved REST-api
You can find the full list of changes in the release notes [1], which also contain the link to the downloads
and the full list of changes.
Maven artifacts for RHQ 4.5 will today be pushed to the JBoss Nexus repository and should today or tomorrow
also show up on maven central.
A special thanks goes to Elias Ross and Richard Hensman for their contributions to this release.
Heiko on behalf of the whole RHQ team.
[1] https://docs.jboss.org/author/display/RHQ/Release+Notes+4.5.0
--
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
11 years, 7 months
IE8 Charting Next steps
by mike thompson
Soliciting input for next steps:
I spent yesterday messing with various combinations of excanvas.js with aight.js and sizzle.js (also packaged in jQuery). This was precipitated by the discovery that GFlot (the gwt packaging of flot.js) renders canvas elements in IE8 via excanvas. So, knowing that some form of canvas elements can be rendered in IE8 via a polyfill (excanvas), I tried to add the extra functionality that was needed in addition to excanvas (that I tested alone before) for the d3.js charts to be rendered. This was NOT successful. I have not seen anything in the forums saying there has been success with d3 on IE8. And my three cross postings of this questions in the forums (Quora, StackOverflow, d3 google groups) has gone unanswered.
The most probable solutions I see for next steps are (in order of worst to best for IE8 users):
A) The current situation is that I have charting turned off for IE8 users in the Monitor Tab. I'm assuming that this means we would leave the dashboard GFlot charts in for IE8 -- unless we want to turn those off as well
B) Pursue server-side solution via Batik. This would give us a single codebase, however, it is not proven yet (still a couple days work) and IE8 users would get a static bitmapped rendering of the charts.
C) Use d3.js but use html bar charts (via divs) for IE8. The IE8 experience would be marginally worse but the codebase would be fairly similiar as both chart types would use d3.js technology but just different graph library solutions (html vs canvas/svg).
D) Leave the current GFlot charts in place and render them for IE8 giving IE8 users usable interactive charts. This would come at the price of two sets of charting codebase. We would also need to replace the iframe (portal.war) charts in monitor tab to GFlot as well to be free of portal.war.
The solutions choice varies depending on where the priorities lie -- with IE8 users experience versus a cleaner codebase.
11 years, 7 months
bootstrapping/deploying metrics db
by John Sanda
I have started thinking about how we will deploy our new metrics back end. So far I have been operating under the assumption that we will deploy Cassandra nodes with our provisioning system. The problem of bootstrapping ourselves in this fashion is that it introduces circular dependencies. Deploying a Cassandra node requires a running agent. A running agent implies MeasurementManager is initialized and is collecting metrics. The agent needs a back end to store metric data.
One possibility is to not fully initialize MeasurementManager until we have Cassandra up and running. This would require either the server to send notification to all agents so the each MeasurementManager instance can start up and start collecting metrics. Or the agent/MeasurementManager could poll the server to see when it can start collecting metrics. Neither of these is particularly appealing to me.
Anyone have thoughts on an alternative bootstrapping approach?
- John
11 years, 7 months