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