CLI on server part 2

John Mazzitelli mazz at redhat.com
Mon Jan 10 19:21:26 UTC 2011


One thing we have always tried to stress (some times better than other 
times) is to get the install process to not be such a headache. In the 
past, we've had plenty of people complain about the setup.

We already have to get the user to install a database along with the 
server and an agent. Even the database seemed like it was a pita for 
some new users to setup (many who just wanted to try this stuff out and 
see what it looked like). This is why the embedded H2 effort was done - 
it essentially eliminated all third-party server processes that needed 
to be installed, configured and run. No Postgres or Oracle needed - just 
unzip the rhq server distro, run it and point your browser to it. Answer 
a few questions (most can be keep at their defaults) and you are done 
and can play. You could even use the embedded agent (which granted has 
some problems, but its still useful for quick demos/testing) thus 
allowing you to unzip the rhq server and go.

If we introduce a new requirement, that means we have to ask the user to 
install another piece of software, configure it and run it.

Granted, an SCM type system or something like modeshape isn't as 
integral part to the RHQ Server as the DB (that is, without a database, 
RHQ just can't run - without this server-side storage mechanism, you 
only lose this "run a script in the server" feature). But it IS 
something that the user has to know about and install/configure if he 
wants to use that feature.

If we were to do something like this, we'd want to look into some 
technology that we can embed in our RHQ Server (can modeshape, for 
example, be integrated directly in the RHQ Server JBossAS instance?). 
This way, when you install RHQ, you get this stuff for free and its 
auto-configured for you.

BTW: I'm not at all convinced of the arguments against storing the 
scripts in the DB. This is such a small amount of data that is going 
into the database and is rarely going to be even queried/retrieved 
(compared to, say, configuration (RHQ_CONFIG and related tables), 
measurement data (RHQ_MEAS_xxx) and others), that I feel it will have no 
bearing on the performance of the RHQ system as a whole. Geez - just 
think of the load we are putting on things like the resource tables, and 
the measurement tables and the authz joining to do role-based auth - 
then compare that to me wanting to store a few 10K long scripts and 
every now and then when an alert is triggered, to read some 10K scripts 
to run them. It's negligible, IMO.


More information about the rhq-devel mailing list