Self-referencing Option Sources
by Stefan Negrea
Hello Everybody,
I enabled yesterday self-referencing option sources. That means only the configuration of the current resource will be queried for possible options. The initial implementation only allowed options sources that take options from all resources of a certain type. So all resources of the referenced type were scanned, and property values were extracted and aggregated into a single set of options.
Options sources can be used in three places:
1) Resource Configuration
2) Parameters for Operations
3) Connection Settings on import or creation of new resources
With the original implementation, it was easy to compute the options in all three cases since types were referenced. In the AS7 plugin, the referenced resource type was different than the current type in all the cases. Also, for compatible groups, getting these options made sense since again all the resources of a type were scanned; so all these options would have been identical regardless of actual resource that was using it.
Things get complicated with self-referencing option sources. In some cases computing the options does not make sense. The current implementation presents users with a text box if the option source does not return anything. With self-referenced option sources, users will see a text field in cases where computing the options does not make sense.
Here are the cases where it no longer makes sense (user will see a blank text box):
1) Create or import a new resource - impossible to self-reference something that is not yet created.
2) Group operations with option sources for parameters - each resource would have a different set of options
3) Group updates for resource configuration - each resource would have a different set of options
Original - option source with type reference:
<c:simple-property name="myProperty">
<c:option-source target="configuration" expression="listProperty/socketBinding=name:type=SocketBindingGroup"/>
</c:simple-property>
New - self-referencing option source:
<c:simple-property name="myProperty">
<c:option-source target="configuration" expression="listProperty/socketBinding=name"/>
</c:simple-property>
Rather than using a keyword (eg. "this"), the omission of type will imply an option source is referencing the resource where it is located.
Right now the change is only in the Cassandra plugin branch but it will be merged soon in master. Here is the code commit:
http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=jsanda/cassandra-p...
I would really appreciate a code review.
Thank you,
Stefan Negrea
Software Engineer
11 years, 6 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
Additional Platform Fields
by Richard Hensman
Hi
I have a requirement to display some a additional on the platform in RHQ.
- Make
- Model
- Asset Tag
- Function
- Notes
Would it be ok to add these as additional fields to the Resource so that
users can manually enter the values?
I have investigated populating Make and Model from the BIOS. This can be
done on Linux using dmidecode. This does mean the agent would need to run
as root though.
regards
Richard
11 years, 6 months
Git freeze over -- check your branches
by Heiko W.Rupp
Ok,
I have accidentally removed the modules/plugins/ directory in many branches
that alphabetically start with A and go to the middle of r
(rhq-on-as7 is the first one not affected).
On all the affected branches I have now issued a
git revert HEAD
to revert the deletion.
I have checked in a few places and this looks good again.
Nevertheless: please check that after an update the stuff
looks like expected.
Sorry
Heiko
11 years, 6 months
GIT TEMPORARY FREEZE !!!
by Heiko W.Rupp
Hi,
I've messed up with git. Please refrain from doing anything until I have solved this.
I will send another message.
Heiko
11 years, 6 months
RHQ Charting Replacement
by mike thompson
Hi All,
Although the RHQ charting rewrite is underway, we decided to take a step back and look holistically at the changes and explicitly bring to light exactly what we have in the current system and what steps we are proposing to implement.
Attached are two documents. The first is the 'RHQ Charting Assessment' that is an inventory of what charts we have where and what they represent. Additionally in the document are the immediate future steps of things we are trying to resolve with the chart replacement. The second document is the 'RHQ Charting Gallery' which is just a visual supplement for first document showing the actual charts.
-- Mike
11 years, 6 months
Usage of implicitResources in ClusterManagerBean#buildQuery
by Andreas Veithen
ClusterManagerBean#buildQuery contains the following code:
// this is an authorization-related query, so use
implicitResource (not explicitResources)
if (1 == size) {
query
.append("SELECT rgir FROM ResourceGroup rg JOIN
rg.implicitResources rgir WHERE rgir.inventoryStatus = 'COMMITTED' AND
rg = "
+ clusterKey.getClusterGroupId());
} else {
buildQuery(query, params, clusterKey, nodes.subList(0, size - 1));
}
We have a situation where the usage of implicitResources instead of
explicitResources appears to cause a performance issue. This occurs
for depth 3 resources related to the JVM (e.g. as JVM > Memory
Subsystem > MarkSweepCompact) in a compatible group. When trying to
open the summary for such a resource, the request times out because
the database takes too much time to complete the query. Note that
other resources at depth 3 are not affected by this problem. My guess
is that this is related to the fact that the keys of the resources in
the hierarchy ('JVM', 'java.lang:type=Memory' and
'java.lang:name=MarkSweepCompact,type=GarbageCollector' in the
example) for these resources are "less unique" than for other
resources (we have 39 JVMs in the inventory).
I tested the problematic database query, and if I replace
RHQ_RESOURCE_GROUP_RES_IMP_MAP by RHQ_RESOURCE_GROUP_RES_EXP_MAP, then
it returns the same results, but much faster. Therefore I would like
to understand the meaning of the comment "this is an
authorization-related query, so use implicitResource (not
explicitResources)". Can somebody explain that to me?
Andreas
PS: I've investigated this with RHQ 4.5.1, but 3.0.0 had the same problem.
11 years, 7 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
Post request for jopr-tomcat-plugin
by Ken Rumer
I have updated the jopr-tomcat-plugin plugin to work with Tomcat 7 along
with RHQ 4.4.0 and 4.5.1. I have tested all of the features I could and I
would like to push the code to GIT. Please let me know what steps are
necessary.
Thanks,
Ken Rumer
11 years, 7 months