geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: Usability/Tooling - geronimo configuration on a headless server
Date Mon, 20 Jun 2005 15:19:19 GMT
On 6/20/05, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:

>         When you talk about a headless server...  Is it acceptable to have
> a GUI tool that you run remotely via X-over-ssh, or does the server have
> no X install such that even that wouldn't work?

Actually, there are situations where this won't be possible. In these
situations, a strictly command line tool might be more feasible. The
way I see it, we have three options:

A) Develop the installer/configurator as a command line tool and
simply wrap that with a GUI for local installs, or

B) Develop the main functionality as a library and develop each front
end separately (e.g. a command line front end using Groovy, a GUI
using JGoodies, or even a web UI)

C) Develop two separate tools altogether 

I would much rather choose option B simply because it would best
facilitate many front ends and all would utilize the same core
functionality on the back end.

>         In any case, I think your writeup is sensible.  However, it may be
> difficult to implement the upgrade compatiblity where a new install
> detects and defaults to the settings in an old install.  I'd call this a
> "nice to have", but in any case it doesn't have to be ready until our
> second release (so you have something to upgrade from)...  :)

I agree. Let's get the base install functionality working first. Only
after that is working should we begin to consider refactoring to
facilitate upgrades.

> On Mon, 20 Jun 2005 sissonj@insession.com wrote:
> > The following are my thoughts regarding requirements for
> > running/configuring geronimo on a headless server in a production
> > environment..
> >
> > Whatever solution we come up with for changing the configuration settings
> > (e.g. port numbers) it needs to be 'usable' in a headless environment.  By
> > that I mean that it should be 'easy' to change the configuration settings
> > on a headless machine, e.g. not having to regenerate the configuration
> > from scratch via a GUI on another machine and transfer the configuration
> > over manually (e.g. ftp) etc.  The solution could be a command line
> > interface, or it could be a GUI solution that allows one to run a
> > configuration server component on a specified port (consider that more
> > than one instance of geronimo could be running on the server and each
> > instance could be running at a different version) and connect to it from a
> > client machine (with minimal steps required by the user).

This is *exactly* why I think a base library for the
installer/configurator should be developed first. Then we can develop
any kind of front end necessary.

> > We should allow GBean attributes to be changed whilst geronimo isn't
> > running without requiring the configuration be rebuilt from scratch
> > because whilst geronimo is in production, people may have tinkered with
> > Gbean attribute values (e.g. via a JMX console) e.g. to tune it, but those
> > people may have forgotten to make the same changes to the files (XML
> > plans) that are used to generate configurations the next time around.  The
> > only time I think it should be necessary to rebuild a configuration from
> > scratch is when you are installing a new version of geronimo.  When a
> > configuration is built for a new release, the user shouldn't have to
> > re-enter all the settings in the GUI again (this would be prone to user
> > error), they should be able to import the existing configuration into the
> > configuration tool, with a validation step identifying screens/fields
> > where new mandatory fields need to be entered in the configuration.

My thought process has been that the base installer/configurator
library should have the ability to write out plans. This would
certainly address the issues above, but will make our job a bit more
complex because we'll need a manner in which to slurp up the XML plans
and the the serialized config into a set of beans that can be diffed
somehow and the present the differences to the user.

> > Consider the following scenario..  Geronimo has been running for months in
> > a production environment, where months ago, GBeans attribute values that
> > configured the locations of files (e.g. transaction logs and database
> > files) were changed from the default location to point to a different
> > disk.  At present, Geronimo has been shut down during a hardware
> > maintenance window where a newer high speed disk has been installed.  The
> > operations staff now want to change the configuration of the file
> > locations in some GBean attributes to point to that new disk (they have
> > moved the files), without touching any other Gbean attribute values that
> > may have been previously customised (months ago) to minimise risk.

This is a good example of why I feel that the this application we're
discussing should not only be an installer, but should also be a
post-installation configurator (i.e. for existing installations).

Bruce 
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message