geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Usability/Tooling - geronimo configuration on a headless server
Date Mon, 20 Jun 2005 14:59:54 GMT
	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?

	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)...  :)

Aaron

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).
> 
> 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.
> 
> 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.
> 
> Comments?
> 
> John
> 
> This e-mail message and any attachments may contain confidential, 
> proprietary or non-public information.  This information is intended 
> solely for the designated recipient(s).  If an addressing or transmission 
> error has misdirected this e-mail, please notify the sender immediately 
> and destroy this e-mail.  Any review, dissemination, use or reliance upon 
> this information by unintended recipients is prohibited.  Any opinions 
> expressed in this e-mail are those of the author personally.

Mime
View raw message