On 6/20/05, Aaron Mulder <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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)[EMAIL
PROTECTED]&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/
