Webdav users?
by Heiko W.Rupp
Hi,
are there any users of the webdav module out there?
This got removed from the build in December last year.
If there are no objections, I would completely remove that from the sources
for RHQ 4.5
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
resource component start/stop operations
by John Sanda
I have implemented start and shutdown operations for a top-level server type. For the shutdown, I am just doing,
ResourceContext.getNativeProcess().kill("KILL")
For the start operation I am invoking a shell script that does the work. Here's my question. When I restart the resource, it will get a new pid. I have been relying on ResourceContext.getNativeProcess().getPid() to get the pid. In a restart situation though, that won't work until discovery has run again. Is there a way to force update the stored ProcessInfo immediately after I execute the resource's start operation?
- John
11 years, 7 months
Re: Sigar & glibc
by Stefan Negrea
Hello Everybody,
The change has landed in master on Friday and will be part of RHQ 4.5 release. Here is the commit that updates Sigar to version 1.6.5.132-3:
http://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=2b1a462a41684da0c...
And here is the associated Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=857441
Thank you,
Stefan Negrea
Software Engineer
----- Original Message -----
> From: "Charles Crouch" <ccrouch(a)redhat.com>
> To: rhq-users(a)lists.fedorahosted.org
> Sent: Wednesday, September 12, 2012 2:04:23 PM
> Subject: Fwd: Sigar & glibc
>
> Making sure users get notified of this change too...
>
> ----- Forwarded Message -----
> From: "Stefan Negrea" <snegrea(a)redhat.com>
> To: rhq-devel(a)lists.fedorahosted.org
> Sent: Tuesday, September 11, 2012 10:07:44 AM
> Subject: Re: Sigar & glibc
>
>
>
> ----- Original Message -----
> > From: "John Sanda" <jsanda(a)redhat.com>
> > To: rhq-devel(a)lists.fedorahosted.org
> > Sent: Tuesday, September 11, 2012 9:20:00 AM
> > Subject: Re: Sigar & glibc
> >
> > Do we need to test with different versions of gclib (>= 2.5) ?
>
> No, glibc is backwards compatible. Today it works more or less the
> same way. Sigar links against and older glibc version but it works
> on Linux distros with newer versions. The linking part is what is
> going to change.
>
> Here is the ldd output for the Linux x86 native library distributed
> with RHQ 4.4:
>
> linux-gate.so.1 => (0x00f6d000)
> libc.so.6 => /lib/libc.so.6 (0x0034c000)
> /lib/ld-linux.so.2 (0x4261e000)
>
> Version information:
> ./libsigar-x86-linux.so:
> libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
>
>
> And here is the ldd output for the Linux x86 native library to be
> distributed with RHQ 4.5:
> linux-gate.so.1 => (0x00236000)
> libc.so.6 => /lib/libc.so.6 (0x003e0000)
> /lib/ld-linux.so.2 (0x4261e000)
>
> Version information:
> ./libsigar-x86-linux.so:
> libc.so.6 (GLIBC_2.1.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.3.4) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.3) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1.2) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.2) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.1) => /lib/libc.so.6
> libc.so.6 (GLIBC_2.0) => /lib/libc.so.6
>
> If I interpret this output correctly, the newer binary requires a
> minimum glibc version of 2.3.4 (even though it was built against
> glibc 2.5) while the old one links against 2.1. So with this change
> support would be dropped for all distros that use glibc versions
> prior to 2.3.4.
>
>
> Maybe somebody with more experience can shed more light into this
> library linking ...
>
>
>
> Thank you,
> Stefan Negrea
>
>
>
> >
> > On Sep 11, 2012, at 9:57 AM, Stefan Negrea <snegrea(a)redhat.com>
> > wrote:
> >
> > > Hello Everybody,
> > >
> > > For RHQ 4.5, I plan on updating some Sigar native libraries with
> > > new ones built from the same source as the current 1.6.5.132. The
> > > native libraries will change only for x86 and x86_64
> > > architectures
> > > for Windows, Solaris (x84_64 only) and Linux. And again, these
> > > new
> > > binary bits are built from the same source as the current
> > > 1.6.5.132 version distributed with RHQ 4.4. I do not see any
> > > issue
> > > with this update for Solaris and Windows.
> > >
> > > However, Linux is a little different because of glibc library
> > > linking. The version to be released with RHQ 4.5 is built against
> > > glibc 2.5. Since glibc is backwards compatible, this update
> > > should
> > > not impact any Linux deployments that use glibc 2.5 or newer
> > > versions. Glibc 2.5 was released in September 2006, which is
> > > quite
> > > a while back; the most recent glibc version is 2.16. From my
> > > investigation, most Linux distros should be on glibc 2.7 or newer
> > > versions.
> > >
> > >
> > > Does anybody see any problems with regards to linking Linux Sigar
> > > native libraries against glibc 2.5?
> > >
> > >
> > > Thank you,
> > > Stefan Negrea
> > >
> > > Software Engineer
> > >
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel(a)lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> >
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
>
> _______________________________________________
> rhq-users mailing list
> rhq-users(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-users
>
11 years, 7 months
Fwd: client's time for obtaining the data?
by Jiri Kremser
forwarding...
----- Forwarded Message -----
From: "Charles Crouch" <ccrouch(a)redhat.com>
To: "mike thompson" <mithomps(a)redhat.com>
Cc: jboss-on-team(a)redhat.com, "Jiri Kremser" <jkremser(a)redhat.com>
Sent: Wednesday, September 12, 2012 11:04:23 PM
Subject: Re: client's time for obtaining the data?
Lets keep the tech discussions on rhq-devel
Cheers
Charles
----- Original Message -----
> Good catch. Sounds like we need a current time service on the server
> side that should be used instead of System.currentTimeMillis() on
> the client.
>
> -- Mike
>
>
> On Sep 12, 2012, at 9:12 AM, Jiri Kremser <jkremser(a)redhat.com>
> wrote:
>
> > Hi,
> > while I was working on
> > https://bugzilla.redhat.com/show_bug.cgi?id=848494 I found out
> > there are many places in our coregui client side, where
> > System.currentTimeMillis() is used. The problem with this is that
> > a user (browser) accessing the UI from different timezone or from
> > a computer with bad time setting generates the wrong "now" and
> > pass it to the various server side methods. Here I've found the
> > possible risks:
> >
> > AbstractMeasurementRangeEditor:
> > MeasurementDataGWTService
> > * findDataForResource (used by ResourceMetricGraphView,
> > GraphListView (causing 848494))
> > * findDataForCompatibleGroup (used by GroupMetricsPortlet,
> > ResourceGroupMetricGraphView (848494 probably as well))
> > * findCallTimeDataForResource (not used at all)
> >
> > MeasurementChartsGWTService
> > * getMetricDisplaySummariesForCompatibleGroup (used by
> > GroupMeasurementTableDataSource, here the times are taken from
> > user prefs or from MeasurementUtility.calculateTimeFrame, where
> > System.currentTimeMillis() can be used on the client side)
> > * getMetricDisplaySummariesForAutoGroup (not used at all (=>
> > candidate for removal))
> > * getMetricDisplaySummariesForResource (used by
> > MeasurementTableDataSource, the same holds as for
> > getMetricDisplaySummariesForCompatibleGroup)
> >
> > In fact, the concept of (long begin, long end) is present on the
> > server-side in many methods, so it is kind of natural to preserve
> > these method signatures to the client-side, but we should keep
> > this fact/risk in mind. That time returned from
> > System.currentTimeMillis() called on the client-side could be
> > pretty arbitrary. Easy workaround could be instead of GWTService
> > methods with params getMeData(long from, long to) to use
> > getMeDataOldAtMost(int number, unit unit) or something like that
> > and the System.currentTimeMillis() call on the server-side.
> >
> > What do you think about it?
> >
> > JK
> >
>
>
>
11 years, 7 months
viagra, enlarge your penis, viagra :]
by Jiri Kremser
Sry, I didn't know that. Hopefully, nobody will notice.
----- Original Message -----
From: "John Mazzitelli" <mazz(a)redhat.com>
To: "ON Team" <jboss-on-team(a)redhat.com>
Sent: Thursday, September 13, 2012 2:28:05 PM
Subject: Fwd: client's time for obtaining the data?
Let's hope the whole of the RHQ community (and spammers?) don't realize we've now published the address to our internal mailing list:
> Cc: jboss-on-team(a)redhat.com
Does anyone know if outside people can email internal RedHat mailing lists or does our mail server block that? If its blocked, it may not be an issue. If not, prepare to be spammed :)
----- Forwarded Message -----
From: "Jiri Kremser" <jkremser(a)redhat.com>
To: rhq-devel(a)lists.fedorahosted.org
Sent: Thursday, September 13, 2012 8:21:54 AM
Subject: Fwd: client's time for obtaining the data?
forwarding...
----- Forwarded Message -----
From: "Charles Crouch" <ccrouch(a)redhat.com>
To: "mike thompson" <mithomps(a)redhat.com>
Cc: jboss-on-team(a)redhat.com, "Jiri Kremser" <jkremser(a)redhat.com>
Sent: Wednesday, September 12, 2012 11:04:23 PM
Subject: Re: client's time for obtaining the data?
Lets keep the tech discussions on rhq-devel
Cheers
Charles
----- Original Message -----
> Good catch. Sounds like we need a current time service on the server
> side that should be used instead of System.currentTimeMillis() on
> the client.
>
> -- Mike
>
>
> On Sep 12, 2012, at 9:12 AM, Jiri Kremser <jkremser(a)redhat.com>
> wrote:
>
> > Hi,
> > while I was working on
> > https://bugzilla.redhat.com/show_bug.cgi?id=848494 I found out
> > there are many places in our coregui client side, where
> > System.currentTimeMillis() is used. The problem with this is that
> > a user (browser) accessing the UI from different timezone or from
> > a computer with bad time setting generates the wrong "now" and
> > pass it to the various server side methods. Here I've found the
> > possible risks:
> >
> > AbstractMeasurementRangeEditor:
> > MeasurementDataGWTService
> > * findDataForResource (used by ResourceMetricGraphView,
> > GraphListView (causing 848494))
> > * findDataForCompatibleGroup (used by GroupMetricsPortlet,
> > ResourceGroupMetricGraphView (848494 probably as well))
> > * findCallTimeDataForResource (not used at all)
> >
> > MeasurementChartsGWTService
> > * getMetricDisplaySummariesForCompatibleGroup (used by
> > GroupMeasurementTableDataSource, here the times are taken from
> > user prefs or from MeasurementUtility.calculateTimeFrame, where
> > System.currentTimeMillis() can be used on the client side)
> > * getMetricDisplaySummariesForAutoGroup (not used at all (=>
> > candidate for removal))
> > * getMetricDisplaySummariesForResource (used by
> > MeasurementTableDataSource, the same holds as for
> > getMetricDisplaySummariesForCompatibleGroup)
> >
> > In fact, the concept of (long begin, long end) is present on the
> > server-side in many methods, so it is kind of natural to preserve
> > these method signatures to the client-side, but we should keep
> > this fact/risk in mind. That time returned from
> > System.currentTimeMillis() called on the client-side could be
> > pretty arbitrary. Easy workaround could be instead of GWTService
> > methods with params getMeData(long from, long to) to use
> > getMeDataOldAtMost(int number, unit unit) or something like that
> > and the System.currentTimeMillis() call on the server-side.
> >
> > What do you think about it?
> >
> > JK
> >
>
>
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
11 years, 7 months
Re: Oracle ASM Disk Groups
by Richard Hensman
Have added patch to Bug 855980 with code formatted correctly
On 12 September 2012 22:08, Richard Hensman
<richard.hensman(a)onevisionconsulting.co.uk> wrote:
> Have added patch to Bug 855980 with code formatted correctly
>
> On 11 September 2012 17:54, mike thompson <mithomps(a)redhat.com> wrote:
>> Also, IntelliJ Idea folks should use the eclipse code formatter for intellij
>> to provide consistent formatting across the IDEs:
>> https://docs.jboss.org/author/display/RHQ/IntelliJ+IDEA+Tips
>>
>>
>>
>> On Sep 11, 2012, at 6:52 AM, John Mazzitelli <mazz(a)redhat.com> wrote:
>>
>> ----- Original Message -----
>>
>> So is the configuration found in etc/eclipse-tools/templates no
>> longer
>> relevant? If not, can we remove it?
>>
>>
>> These exist so you can import them into Eclipse without loading the entire
>> project into eclipse. They also have some things that aren't possible to
>> store in a project-level config - like license-editor-templates.xml and
>> code-templates.xml.
>>
>> We should probably go through all of this and make sure everything is still
>> in sync.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel(a)lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>
>
>
> --
> RICHARD HENSMAN
> One Vision Consulting Limited
> Office: +44 845 519 5917 | Mobile: +44 774 0374751 |
> richard.hensman(a)onevisionconsulting.co.uk |
> www.onevisionconsulting.co.uk
11 years, 7 months
Change location of CLI samples
by Lukas Krejci
With the introduction of scripting modularity in RHQ 4.5.0, it has become
possible to load scripts from various (non-local) locations.
Our samples are currently distributed in the CLI distribution in the "samples"
directory. But we also have a counterpart of samples on the server-side -
Administration-Downloads section contains an example alert script that users
can download, modify and use. This server-side script uses 3 of the scripts
that are otherwise in the CLI samples. It has no other option but to have
these scripts copy-pasted into the contents of the alert script.
You can see the script here in its entirety of 484 lines of code:
http://git.fedorahosted.org/cgit/rhq/rhq.git/tree/modules/enterprise/serv...
resources/cli-alert-scripts/fix-bundle-deployment.js
Now if we were to distribute the CLI samples in a location that would also be
reachable from the serverside alert scripts, it would reduce to mere 2 lines
of functional code:
var bundles = require("rhq://downloads/bundles");
bundles.deployBundle(...);
Therefore, I would like to propose the following:
1) Put the scripts currently contained in $CLI_HOME/samples in a location on
the RHQ server so that it is reachable both by server-side and client-side
scripts.
2) Leave the samples in the CLI distribution, too, to a) keep the backwards
compatibility and b) enable their offline usage (even though that wouldn't
probably be of too much use to users).
For 1) we'd of course need to also provide UI section in the downloads.
Additionaly, the sample scripts as they are now would have to be "modularized"
- they currently assume they are loaded into the interactive CLI in certain
order before they can be used. But this is a rather simple if laborious
change.
The above is captured by http://bugzilla.redhat.com/show_bug.cgi?id=852169
(which also has a patch attached that implements the necessary changes ;) ).
What do you think? Do you have any objections against or ideas about the
above?
Thanks,
Lukas
11 years, 8 months
Unset - Configuration Editor
by Stefan Negrea
Hello Everybody,
Yesterday I applied a fix to the configuration editor that on the surface looks harmless but changes across the board the way default values are applied to fields on unset updates.
The original behaviour was very confusing and unintuitive. Here is the behaviour and what was confusing to me:
1) On initial configuration editor load
a) if a field was unset, then the default value was loaded the form field but the actual field was disabled.
The problem: the field was disabled and unset checked, however there is a value in thr form field that cannot edited or cleared. This can give the wrong impression that unset fields automatically get the default value when saved. If a user really gets confused about that value being there but greyed out then there is no way for a user clear that value without changing the value of unset twice, see 3) and 4) below.
2) When the user changes the unset state from true to false for the first time:
a) the form field was enabled for editing
b) since the default value was already there from the initial load, that default value would still be selected
c) the form could not be saved because the changed event was not fired by the code
The problem: the default value is there (and selected for properties with options) but the user will need to update the field before the configuration can be saved. As an example, for fields with options, the user will have to select another value and then reselect the default value before they can save the configuration with the default value for property with options. This is all because internally the code does not fire the event that the form changed.
3) When the user changed the unset state from false to true:
a) the value of the field was cleared
b) the field was disabled
No problem! This is the only case where the behaviour is intuitive.
4) When the user changed the unset state from true to false for third, fourth, fifth, ... time on the same field:
a) the form field was enabled for editing
b) the form field would be empty or no value selected for fields with options, since the value was cleared in 3)
c) the user would need to read the field description and type or select the default value, if the default value is even mentioned in the field description.
The problem: This contradicts 2) where the default value was in the field. So, the user will see the default value for the first time but not for subsequent times. If the default value is set for the field but not in the description, the user will have absolutely no way to find that out after the initial unset change since the default value is not displayed in the UI.
To fix this, I changed the way default values are applied to properties to give a natural user experience. As you can see even explaining this new behaviour is more concise. Here is how this works after the update:
1) On load, if the field is unset then disable field and set value to null.
2) On load, if the field is set then enable field and load saved value.
3) On unset change from true to false, enable field and load default value if not null. Enable save button.
4) On unset change from false to true, disable field and set value to null. Enable save button.
All this work was triggered by BZ 851186 which was reported against the AS7 plugin. However this problem was applicable to every single screen with a configuration editor. As you can see from the bug description, the original behaviour was very confusing even to the reporter. Here is the BZ for reference:
https://bugzilla.redhat.com/show_bug.cgi?id=851186
Any thoughts? Is the new behaviour intuitive enough?
Thank you,
Stefan Negrea
Software Engineer
11 years, 8 months
deploying metrics db during RHQ installation
by John Sanda
Below is a summary of my thoughts thus far on what will be involved with deploying the new metrics database during RHQ installation. This information is available on the wiki at https://docs.jboss.org/author/display/RHQ/Acceptance+Criteria.
Let's start with the simple case involving a single node. During the RHQ installation process, the user will have to provide several pieces of information so that we can install and configure the node. For basic configuration settings that require values this includes:
* The host name of the machine on which Cassandra will be installed
* A writable directory where Cassandra will store the commit log and data files
* User credentials (more on this in the security section)
* Location for backups (more on this in the backup section)
For advanced settings for which we will supply default values, this includes:
* The various ports including rcp_port which is the port Cassandra listens on for Thrift clients
* key and row cache settings like the cache sizes and retention periods for cache entries
* Settings for the commit log which control when writes are acked and how frequently it is flushed to disk
* The JMX port which is the port on which Cassandra listens for JMX connections
Nearly all of the user-supplied configuration values will go into cassandra.yaml. The JMX port will be written into cassandra-env.sh. We will need to generate these files with the values supplied by the user. The location of backups is unique in that it pertains to how RHQ will manage the Cassandra node. That information will need to be stored in the RHQ database.
Users are not required to install and run an agent on the same machine on which the RHQ server runs. The user will however have to install an agent onto the machine on which the Cassandra node is installed so that we can fully manage it. This brings up the order of installation with respect to the Cassandra node, the RHQ server, and the RHQ agent. The key thing is that when the RHQ installer finishes, the Cassandra node should be running and fully configured for management. By that I mean that the Cassandra node should already be imported into the server's inventory, maintenance operations should already be scheduled, alert definitions should already be created, event logging configured, and so on.
If deploying multiple nodes, there are two additional properties that must be set - seeds and initial_token. seeds is a list of host names or IP addresses where nodes will be running. This list is used at start up so that a node can learn the topology of the cluster. initial_token specifies the range of the token ring for which the node is responsible. There is a simple function to use for calculating tokens. It is possible to run multiple nodes on a single machine for production use, but each node has to have its own IP address.
- John
11 years, 8 months
Oracle ASM Disk Groups
by Richard Hensman
Hi
I have been doing some more work on the RHQ Oracle Plugin. It now
collect metrics for Oracle ASM Diskgroups. I have opened Bug 855980
to cover this and attached my patch.
If everyone is happy with my changes, could this be included in the
next version of RHQ?
thanks
Richard
11 years, 8 months