rhq_availability and purging
by Elias Ross
I have over 20 million rows in rhq_availability.
One reason is I don't purge this data. The purge process for very
large tables (traits for example) usually removes a lot of rows, which
impacts inserts, which in turn impacts the agents through timeouts.
I'd like it if the trait data could move to Cassandra.
But I'd also like to have rhq_availability move as well to Cassandra.
If not, then how about changing the purge process to the following:
1) Select the rows needed for deletion
2) Then in a separate transaction, delete 100 at a time.
9 years, 9 months
RHQ 4.12 is coming ...
by Heiko W.Rupp
Hey,
we are thinking of releasing RHQ 4.12 shortly after the underlying app server
has been rebased onto EAP 6.3, which means around a week from now.
Please try master after the rebase if possible and tell us about fallout
from the rebase. As Mazz wrote yesterday, all the tests are passing so
we are pretty confident, but another pair of eyes will not harm ;->
Thanks
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie Peters
9 years, 9 months
master is now on EAP 6.3.Alpha
by John Mazzitelli
I just squashed commited my feature branch into master - when you pull down master, you need to rebuild the container. Once you do, you will be running the RHQ Server on EAP 6.3.Alpha.
All unit tests and integration tests passed at the time I commited a few minutes ago... therefore, if it is broken on your box, I blame you. :)
9 years, 9 months
major change going into RHQ soon - upgrading to EAP 6.3
by John Mazzitelli
I've been working on getting the RHQ Server to run with EAP 6.3 under the covers (currently, RHQ Server is running with EAP 6.1).
Right now, all of my builds and tests have shown things to be working on EAP 6.3. I am going to do some final checks before I actually do the merge into master (e.g. I'm going to build with a clean/empty local mvn repository to make sure all dependencies are published in, and can be pulled down from, a public mvn repo.).
Once I've confirmed as best I can that the upgrade to the EAP 6.3 application server is working and all tests pass, I'm going to merge this into master. Barring disaster, this probably will happen in the next day or two. I'll send an announcement when it happens, but wanted to give a heads up to let people know this is going to happen soon.
If you want to try it out now and see the RHQ Server running in EAP 6.3, checkout and build the "feature/bz1069606-rebase-eap-63" branch.
That is all.
--John Mazz
9 years, 10 months
remove yum plugins
by John Mazzitelli
I'm thinking we need to start purging some of these old, prototype, and probably non-functional plugins from source.
Specifically, the agent- and server-side "yum" plugins - along with the "yum" related operation found in the platform plugin.
Thoughts?
9 years, 10 months
Bug 1050014 - Cannot deploy bundle to EAP domain mode
by Thomas Segismont
Hi everyone,
I'm writing to talk about a feature request: Bug 1050014 - Cannot deploy
bundle to EAP domain mode [1]
The problem is that the ANT and FileTemplate bundle types are file
based, and domain deployments are only possible through the management
API or the EAP CLI.
The requirements of this RFE are as follows:
* being able to deploy an application archive to a domain controller
* being able to execute EAP CLI scripts
* the implementation should work with standalone servers
The solution should take into account that we are also trying to solve
the EAP patching problem (see Bug 1069547 - Support EAP 6.2/6.3 style
patching [2] and PR39 on GitHub [3]).
We discussed the RFE with Lukas and Jay some time ago but I wasn't able
to write up the conclusions until now. So here it goes.
1. Extend ANT bundle type to communicate with resource components
Resource component would implement a new facet (name to be defined), and
the methods of this facet would let the user pass some content. The
resource component would do whatever it needs to and the bundle agent
plugin wouldn't try to lay down this content on the system.
Here's how an ANT bundle would look like:
<rhq:deployment-unit name="xxxxxx">
<rhq:file name="myapp.war" handover="deploy"/>
<rhq:file name="myscript.cli" handover="executeCLI"/>
</rhq:deployment-unit>
or
<rhq:deployment-unit name="xxxxxx">
<rhq:file name="patch-eap-6.xxx" handover="patch"/>
</rhq:deployment-unit>
See? The key here is the new "handover" attribute that users could add
to rhq:file, rhq:url-file, rhq:archive and rhq:url-archive.
Pros:
* General purpose solution, could be applied to EAP patching as well
Cons:
* For patching, a recipe and bundle file would have to be created
instead of just the patch zip file
2. Create a new bundle type
This is what Lukas started when he wrote his pull request for EAP
patching support
Pros:
* The concept is already proven by PR39
Cons:
* Yet another bundle type, and only applicable to a specific resource type
* Less powerful than an ANT bundle: users will be able to deploy apps
and execute CLI scripts but nothing else
We'd be very happy to hear from you on this topic. Which solution do you
prefer? Hopefully you don't find both solutions ugly...
Regards,
Thomas
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050014
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1069547
[3] https://github.com/rhq-project/rhq/pull/39
9 years, 10 months