You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by si...@insession.com on 2005/06/20 13:44:19 UTC
Usability/Tooling - geronimo configuration on a headless server
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.
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Bruce Snyder <br...@gmail.com>.
On 6/24/05, Bruce Snyder <br...@gmail.com> wrote:
> On 6/23/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > On Thu, 23 Jun 2005, Bruce Snyder wrote:
> > > While I respect your quest for simplicity, I disagree with this
> > > approach because I think it's too minimal. I think Geronimo needs to
> > > offer an easy to use, friendly installer/post configurator to the
> > > community. Installation of commercial app servers is usually handled
> > > through a GUI installer but configuration has traditionally meant hand
> > > editing config files. This is not something that I think we can do
> > > much better.
> >
> > We have an installer; I think it's reasonably easy to use. I'm
> > sure it could be improved, but in all honesty, the biggest improvement
> > would be to make it run faster. Right now it deploys the customized plans
> > one by one -- it could use the start - multi deploy - stop routine of the
> > assembly module, or we could just replace the whole mechanism with
> > something to edit the configuration in place.
>
> IMO, installation and configuration are very similar and each can be
> achieved using the same UI, but two different APIs underneath - one
> for installation and the other for configuration. This is why I keep
> talking about an installer and a configurator together. The installer
> API should make use of the configurator API.
>
> We've already agreed that a GUI-only installer does not meet all
> requirements. But many sys admins also want the ability to automate
> installs via scripting.
>
> > (Actually, the biggest improvement would be to have whoever makes
> > the unstable builds actually run the installer -- once you have IzPack
> > installed you only need to run 1 command to do it!)
> >
> > > This is exactly why I'm suggesting that we create a library to handle
> > > the installation and configuration tasks. It will allow any kind of
> > > UI to be developed - GUI, text or web - as well as allow for
> > > scriptable installations. This is extremely powerful and cannot be
> > > undervalued.
> >
> > Sure. I mean, we could create an API that would edit the config
> > info in place. Presumably now, it would deserialize the stored
> > configuration, update it, and then reserialize it back to the config
> > store. I have sample code that does this, and while we'd want some minor
> > changes to the config store interface to support it, it's not at all out
> > of the question.
>
> I agree that editing configurations in this manner is a good idea
> because it suits performing a reconfiguration of existing installs.
>
> > However, it would be 10x easier if we just switch to the
> > Spring-based configuration system. :)
>
> I agree that switching to a Spring-based configuration would be ideal!
> I'm just not sure we want to require Spring.
>
> > In any case, if we define the API, we can change the background
> > however we need to going forward. It could also support David J's
> > suggestion of some kind of "configuration service" that would store the
> > ports and similar info separate from the related GBean configuration. The
> > main question to me is, do we create a static set of configuration
> > information based on the services available in our "standard" J2EE
> > configuration, or do we try to make it dynamic where each configuration
> > lists its own configurable properties (using JSR-88, what else? :) The
> > per-configuration system is much more flexible for general-purpose
> > configuraitons of Geronimo, but will make our job a lot harder for things
> > like sensibly choosing between Tomcat and Jetty (which would just be two
> > generic services in that model).
>
> I think we need to prioritize these requirements to determine how to
> design such an API. But this is exactly why I think an API should be
> put together to handle this correctly rather than just hacking
> together a simple config editor. Let's start a JIRA issue for it and
> begin to list the requirements.
Actually, I just stumbled upon JSR 38 (Application Installation API
Specification) and http://www.openinstallation.org/ which provides an
implementation of this API named JIFI. This is an extensible API for
creating cross platform installers for many environments, including
non-GUI situations.
> > I'm wandering here, but this isn't the first time I've thought of
> > something that would be quite nice for the "J2EE Server Configuration" but
> > not terribly useful outside it. I wonder if we should start a separate
> > subproject/directory tree for J2EE-only stuff that does not need to be
> > compatible with any general Geronimo configuration. Perhaps this will
> > just be an expanded assembly module. I'm sure we'll struggle with this to
> > some degree with the management console.
>
> I think what you speak of here are just many different custom
> assemblies and the installation and configuration APIs need to be able
> to handle them. Using Spring would simplify this tremendously, but I'm
> not yet convinced that we want to require Spring. But doing what James
> did for ServiceMix might nudge me a bit more. He wrote a custom Spring
> bean factory to simplify the Spring configuration. The result is a
> cleaner XML file, while still allowing all of Spring's niceties. This
> would really be the best of both worlds.
>
> 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/
>
--
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/
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 24 Jun 2005, Bruce Snyder wrote:
> We've already agreed that a GUI-only installer does not meet all
> requirements. But many sys admins also want the ability to automate
> installs via scripting.
OK, if I remember right, you can go through the installer in GUI
mode, and then when you finish, save all your selections as a script, and
run the same install without a GUI later. Still not a full non-GUI
installer, but definitely a bridge.
> > Sure. I mean, we could create an API that would edit the config
> > info in place. Presumably now, it would deserialize the stored
> > configuration, update it, and then reserialize it back to the config
> > store. I have sample code that does this, and while we'd want some minor
> > changes to the config store interface to support it, it's not at all out
> > of the question.
>
> I agree that editing configurations in this manner is a good idea
> because it suits performing a reconfiguration of existing installs.
>
> > However, it would be 10x easier if we just switch to the
> > Spring-based configuration system. :)
>
> I agree that switching to a Spring-based configuration would be ideal!
> I'm just not sure we want to require Spring.
>
> I think we need to prioritize these requirements to determine how to
> design such an API. But this is exactly why I think an API should be
> put together to handle this correctly rather than just hacking
> together a simple config editor. Let's start a JIRA issue for it and
> begin to list the requirements.
>
> I think what you speak of here are just many different custom
> assemblies and the installation and configuration APIs need to be able
> to handle them. Using Spring would simplify this tremendously, but I'm
> not yet convinced that we want to require Spring. But doing what James
> did for ServiceMix might nudge me a bit more. He wrote a custom Spring
> bean factory to simplify the Spring configuration. The result is a
> cleaner XML file, while still allowing all of Spring's niceties. This
> would really be the best of both worlds.
But where does code go that only works for one particular
assembly? Does the assembly begin to contain other code or modules in
addition to the raw "assembly" script?
Aaron
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Bruce Snyder <br...@gmail.com>.
On 6/23/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On Thu, 23 Jun 2005, Bruce Snyder wrote:
> > While I respect your quest for simplicity, I disagree with this
> > approach because I think it's too minimal. I think Geronimo needs to
> > offer an easy to use, friendly installer/post configurator to the
> > community. Installation of commercial app servers is usually handled
> > through a GUI installer but configuration has traditionally meant hand
> > editing config files. This is not something that I think we can do
> > much better.
>
> We have an installer; I think it's reasonably easy to use. I'm
> sure it could be improved, but in all honesty, the biggest improvement
> would be to make it run faster. Right now it deploys the customized plans
> one by one -- it could use the start - multi deploy - stop routine of the
> assembly module, or we could just replace the whole mechanism with
> something to edit the configuration in place.
IMO, installation and configuration are very similar and each can be
achieved using the same UI, but two different APIs underneath - one
for installation and the other for configuration. This is why I keep
talking about an installer and a configurator together. The installer
API should make use of the configurator API.
We've already agreed that a GUI-only installer does not meet all
requirements. But many sys admins also want the ability to automate
installs via scripting.
> (Actually, the biggest improvement would be to have whoever makes
> the unstable builds actually run the installer -- once you have IzPack
> installed you only need to run 1 command to do it!)
>
> > This is exactly why I'm suggesting that we create a library to handle
> > the installation and configuration tasks. It will allow any kind of
> > UI to be developed - GUI, text or web - as well as allow for
> > scriptable installations. This is extremely powerful and cannot be
> > undervalued.
>
> Sure. I mean, we could create an API that would edit the config
> info in place. Presumably now, it would deserialize the stored
> configuration, update it, and then reserialize it back to the config
> store. I have sample code that does this, and while we'd want some minor
> changes to the config store interface to support it, it's not at all out
> of the question.
I agree that editing configurations in this manner is a good idea
because it suits performing a reconfiguration of existing installs.
> However, it would be 10x easier if we just switch to the
> Spring-based configuration system. :)
I agree that switching to a Spring-based configuration would be ideal!
I'm just not sure we want to require Spring.
> In any case, if we define the API, we can change the background
> however we need to going forward. It could also support David J's
> suggestion of some kind of "configuration service" that would store the
> ports and similar info separate from the related GBean configuration. The
> main question to me is, do we create a static set of configuration
> information based on the services available in our "standard" J2EE
> configuration, or do we try to make it dynamic where each configuration
> lists its own configurable properties (using JSR-88, what else? :) The
> per-configuration system is much more flexible for general-purpose
> configuraitons of Geronimo, but will make our job a lot harder for things
> like sensibly choosing between Tomcat and Jetty (which would just be two
> generic services in that model).
I think we need to prioritize these requirements to determine how to
design such an API. But this is exactly why I think an API should be
put together to handle this correctly rather than just hacking
together a simple config editor. Let's start a JIRA issue for it and
begin to list the requirements.
> I'm wandering here, but this isn't the first time I've thought of
> something that would be quite nice for the "J2EE Server Configuration" but
> not terribly useful outside it. I wonder if we should start a separate
> subproject/directory tree for J2EE-only stuff that does not need to be
> compatible with any general Geronimo configuration. Perhaps this will
> just be an expanded assembly module. I'm sure we'll struggle with this to
> some degree with the management console.
I think what you speak of here are just many different custom
assemblies and the installation and configuration APIs need to be able
to handle them. Using Spring would simplify this tremendously, but I'm
not yet convinced that we want to require Spring. But doing what James
did for ServiceMix might nudge me a bit more. He wrote a custom Spring
bean factory to simplify the Spring configuration. The result is a
cleaner XML file, while still allowing all of Spring's niceties. This
would really be the best of both worlds.
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/
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Thu, 23 Jun 2005, Bruce Snyder wrote:
> While I respect your quest for simplicity, I disagree with this
> approach because I think it's too minimal. I think Geronimo needs to
> offer an easy to use, friendly installer/post configurator to the
> community. Installation of commercial app servers is usually handled
> through a GUI installer but configuration has traditionally meant hand
> editing config files. This is not something that I think we can do
> much better.
We have an installer; I think it's reasonably easy to use. I'm
sure it could be improved, but in all honesty, the biggest improvement
would be to make it run faster. Right now it deploys the customized plans
one by one -- it could use the start - multi deploy - stop routine of the
assembly module, or we could just replace the whole mechanism with
something to edit the configuration in place.
(Actually, the biggest improvement would be to have whoever makes
the unstable builds actually run the installer -- once you have IzPack
installed you only need to run 1 command to do it!)
> This is exactly why I'm suggesting that we create a library to handle
> the installation and configuration tasks. It will allow any kind of
> UI to be developed - GUI, text or web - as well as allow for
> scriptable installations. This is extremely powerful and cannot be
> undervalued.
Sure. I mean, we could create an API that would edit the config
info in place. Presumably now, it would deserialize the stored
configuration, update it, and then reserialize it back to the config
store. I have sample code that does this, and while we'd want some minor
changes to the config store interface to support it, it's not at all out
of the question. However, it would be 10x easier if we just switch to the
Spring-based configuration system. :)
In any case, if we define the API, we can change the background
however we need to going forward. It could also support David J's
suggestion of some kind of "configuration service" that would store the
ports and similar info separate from the related GBean configuration. The
main question to me is, do we create a static set of configuration
information based on the services available in our "standard" J2EE
configuration, or do we try to make it dynamic where each configuration
lists its own configurable properties (using JSR-88, what else? :) The
per-configuration system is much more flexible for general-purpose
configuraitons of Geronimo, but will make our job a lot harder for things
like sensibly choosing between Tomcat and Jetty (which would just be two
generic services in that model).
I'm wandering here, but this isn't the first time I've thought of
something that would be quite nice for the "J2EE Server Configuration" but
not terribly useful outside it. I wonder if we should start a separate
subproject/directory tree for J2EE-only stuff that does not need to be
compatible with any general Geronimo configuration. Perhaps this will
just be an expanded assembly module. I'm sure we'll struggle with this to
some degree with the management console.
Aaron
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Bruce Snyder <br...@gmail.com>.
On 6/20/05, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> Well, for configuration purposes, I was thinking something like:
>
> 1) Edit XML/text files enough to get ports/security working
> 2) Start Geronimo, use management web app to get other things working
>
> I personally prefer that scenario to Swing/Text configuration
> tools. However, it's a separate issue from upgrade procedures.
While I respect your quest for simplicity, I disagree with this
approach because I think it's too minimal. I think Geronimo needs to
offer an easy to use, friendly installer/post configurator to the
community. Installation of commercial app servers is usually handled
through a GUI installer but configuration has traditionally meant hand
editing config files. This is not something that I think we can do
much better.
> I guess I probably should have clarified that in my original
> response. I'm not that keen on Swing management tools, though our
> installer package is GUI-only AFAIK. But I was trying to get to our
> actual requirements, and it sounds like "no GUI options whatsoever" is a
> desired target platform.
This is exactly why I'm suggesting that we create a library to handle
the installation and configuration tasks. It will allow any kind of
UI to be developed - GUI, text or web - as well as allow for
scriptable installations. This is extremely powerful and cannot be
undervalued.
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/
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Well, for configuration purposes, I was thinking something like:
1) Edit XML/text files enough to get ports/security working
2) Start Geronimo, use management web app to get other things working
I personally prefer that scenario to Swing/Text configuration
tools. However, it's a separate issue from upgrade procedures.
I guess I probably should have clarified that in my original
response. I'm not that keen on Swing management tools, though our
installer package is GUI-only AFAIK. But I was trying to get to our
actual requirements, and it sounds like "no GUI options whatsoever" is a
desired target platform.
Aaron
On Mon, 20 Jun 2005, Bruce Snyder wrote:
> On 6/20/05, Aaron Mulder <am...@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/
>
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Bruce Snyder <br...@gmail.com>.
On 6/20/05, Aaron Mulder <am...@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/
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by si...@insession.com.
Aaron Mulder <am...@alumni.princeton.edu> wrote on 21/06/2005 12:59:54
AM:
> 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?
There are enterprise platforms (in the mainframe class) do not have X
installed and their JVMs are headless (e.g. if you attempt to use the AWT
classes you will get a HeadlessException).
>
> 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 the upgrade capability is isn't needed until the 2nd release, but
it would be nice to have a high level plan on how it could be achieved to
ensure the configuration information in the 1st release doesn't end up
going up a dead end.
John
>
> 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.
Re: Usability/Tooling - geronimo configuration on a headless server
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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.