Thoughts on how to represent the AS7 resources in RHQ
by Heiko W.Rupp
Hi,
I'Ve posted a draft on how AS7 resources could be represented in RHQ.
This is not yet complete.
The first part talks about what you can find on AS7, the second talks about
how to translate to RHQ.
Two things are still missing:
- Concept of a Domain
- Listing of Profiles of that domain
http://www.rhq-project.org/display/RHQ/RHQ_AS7_mapping
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 3 months
Distribute developer tools with rhq?
by Heiko W.Rupp
Hi,
we have developer tools
- standalone plugin container (see e.g. http://community.jboss.org/community/jopr/blog/2011/01/20/using-the-stand... )
- plugin generator
- ??
I think those should be delivered with a RHQ release - perhaps in a new top level directory, so that developers have
easier access to them.
WDYT?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 3 months
A heads up about maven 3 and -T...
by spinder
Hi all,
This is a heads up to anyone running maven3 and using the -T N "threading" functionality to get greater performance out of their maven builds. It is admittedly an experimental feature and I was using it to shave serial build times down from 15 mins to as low as 6 minutes while running multiple build threads on multi-core boxes. Yeah .. if you build a lot it's quite tempting. With that being said, things were fine for the last two months until last Thursday when builds of master started completing without errors, but on start up you'd get
i)an empty Dashboard (due to some hidden and non-descript NPE SmartGWT javascript error)
or on a second multi-core box
ii)random metadata issues for missing Bundle components at startup.
See here for more details: https://bugzilla.redhat.com/show_bug.cgi?id=669729
These issues spontaneously appeared and disappeared after countless hours debugging with no source code changes. It took quite a bit before I had eliminated most other options and finally started running maven3 in serial build mode again. After which I have not seen any further strangeness.
In the hopes of saving anyone else this difficulty I'd suggest you avoid -T until all the associated plugins come out with 'Thread safe' versions or at the very least if you begin to see strangeness to remember to drop down to serial mode when things look too strange.
-Simeon
13 years, 3 months
RHQ git central repo scheduled maintenance
by John Sanda
Due to some ongoing issues with cloning the repo on fedorahosted.org the
central repo will be closed for maintenance this evening around 2200 UTC
or 17 EST so that it can be repacked. This should resolve the cloning
issues that some users have been experiencing over the past weekend. I
am not sure how long the maintenance will take, but the repo will likely
unavailable throughout the night. I will send an update when the repo is
back online.
- John
13 years, 3 months
Java sources in jar artifacts?
by Heiko W.Rupp
HI,
it looks like we are also putting the java sources into the jar artifacts that
we create - is that on purpose?
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 3 months
CLI on server part 2
by Lukas Krejci
Hi team,
here's a short summary of Filip's and my discussion about the custom CLI
scripts on the server and their possible usage.
The basic idea is that the CLI scripts on the server should not only be
defined as alert notifications but we should also enable users to execute
scripts (or create schedules for executing them) on the server at any time.
The scripts should be "attachable" to almost any entity in the system:
-- resource type - the scripts could be used to mass create dynagroups,
alerts, whatever
-- resources - collect some non-trivial information from the inventory and act
upon it accordingly
-- groups - the same as for resources
-- global scripts - not attached to anything, could be used as general purpose
CLI scripts as they exist today remotely.
The advantage of having the scripts stored on the server is that the users
will thus have a common repository of scripts (reviewed by the admins) to use.
An interesting twist to this could be a script exchange forum on the rhq-
project.org where users could upload their scripts and discuss their usage.
Such forum could provide us very useful information about the real-life usage
scenarios and common problems our users face which we could use to further
improve our product. Also, by having such an easy way of extending the
functionality by simple javascript scripts, we could attract much wider range
of contributors that wouldn't have to know java (which isn't the most popular
language choice among our main target audience - the sysadmins).
An interesting problem is how to render the outputs of such scripts. Obviously
the script could write out a file to the server or we could just redirect the
System.out somewhere (the browser?) but a richer UI would be ideal. We'd have
to define a standard set of "renderers" that would display the results in a
rich manner in the GWT UI (the good starting point here could just be able to
render a list of resources, list of groups and a configuration, all of which
we currently are able to display in GWT already).
Obviously for all this to work, we need to come up with a store for scripts.
Your thoughts?
Thanks,
Lukas
13 years, 3 months
core test jars missing to build the server
by Heiko W.Rupp
Hi,
I guess that is not new to some of us ...
------snip------
[INFO] ------------------------------------------------------------------------
[INFO] Building RHQ Enterprise Server JAR
[INFO] task-segment: [install]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Failed to resolve artifact.
Missing:
----------
1) org.rhq:rhq-core-domain:test-jar:tests:4.0.0-SNAPSHOT
2) org.rhq:rhq-core-client-api:test-jar:tests:4.0.0-SNAPSHOT
------snip------
Workaround is to do a "mvn install" in modules/core/domain and modules/core/client-api (without -Pdev for me, YMMV)
and especially without -Dmaven.test.skip
First I think this should not ever happen
And then, I am puzzled that the server jar depends on tests
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 3 months
Using the standalone plugin-container video
by Heiko W.Rupp
Hi,
this video shows how to use the standalone plugin-container feature of RHQ
to quickly test plugin functionality during the development cycle.
http://vimeo.com/18624567
Share and enjoy :-)
Heiko
--
Reg. Adresse: Red Hat GmbH, Otto-Hahn-Strasse 20, 85609 Dornach bei München
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Charles Cachera
13 years, 3 months
CLI scripts on the server
by Lukas Krejci
Hi all,
I'm writing this to turn your attention to a new feature that is (hopefully)
going to appear in RHQ 4 and that I think can have a large potential for
further improvements in the future (or maybe even in scope of RHQ 4).
The feature is described in the BZ
https://bugzilla.redhat.com/show_bug.cgi?id=667290 and is about adding the
ability to execute a CLI script on the server side as a reaction on an alert
(i.e. this is going to become a new alert plugin).
But thinking about this some more, I think that this could become a way of
providing custom functionality to the RHQ server UI by the users themselves.
Actually, this is something me and Filip talked about at the time the CLI
concept was being developed but we never got round to even formulate the ideas
and bring them forward to the team. I'm sure most of us have had similar ideas
but the backlog of the tasks was just too big for them to bubble up to the
attention :)
Obviously, we'd need to flesh out the security implications but at the same
time I don't think there's much more to decide security wise than what user
will the script run as and whether the CLI will have only access to remote
interfaces even if running on the server or if we are going to let it use the
full local interface.
Anyways, having the ability to run custom CLI directly on the server would
enable us to do things like:
1) execute CLI script as an alert notification (huh? ;) ) - what user would
this script run as?
2) Have CLI UI - a commandline interface in the browser for people that don't
click
3) Let the user create their own custom scripts and expose them somewhere in
the UI as single click actions. These could be global or maybe even per
resource/group, where the resource/group object could be injected in the scope
of the script automatically.
4) ...
Wrt. 3), to an extent we kind of did something like that already with the GWT
user interface I guess. But I don't know GWT enough to guess whether there is
even a remote chance of writing a "user-friendly" API that would interface
with our GWT services and if there is a possibility to later execute such
scripts client-side using something like eval("The user wrote this script;");
What are your thoughts? What aspects of the server should be scriptable?
Cheers,
Lukas
13 years, 3 months