geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject online and offline deployment
Date Sun, 07 Nov 2004 05:51:42 GMT
As promised Thursday, here are the details of my concerns about mixing
offline and online deployment.

My concerns on this issue stem from how we package GBeans together for
use by the kernel. Rather than handling them one-by-one, Geronimo uses
the notion of a pre-canned Configuration which contains a number of
GBean instances and the classpath information needed to load them.
Configurations can be loaded by the kernel and when started bring all
the GBeans they contain online together.

A key feature of Configurations is they are portable between different
Geronimo installations - specifically a Configuration can run in any
Geronimo kernel that can resolve its dependencies. This is less critical
for the single-server mode we have now but is very important as Geronimo
scales to clustered or grid configurations - it allows us to efficiently
move applications between the servers on demand.

This also has benefits where change management is important, such as
business critical installations. For example, a Configuration can be
built and signed in a test or integration environment and moved
*provably unchanged* though the test, stage and release to production
process. Alternatively, an OEM can release an application to channel as
a signed Configuration, end-users can have the assurance it has not been
tampered with, and the OEM can reduce costs by reducing problems caused
by variations in the end-user environment.

In the kernel, the process of loading and unloading Configuration is
handled by a ConfigurationManager that uses ConfigurationStores to store
them. The store exposes a simple API for installing and uninstalling
Configurations and for retrieving them so they can be loaded. We have a
simple LocalConfigStore implementation that uses the local filesystem to
store them; other implementations are possible using different
persistence approaches such as databases, LDAP or proprietary
configuration management systems.

The deployment system in Geronimo is the interface between user-domain
artifacts such as J2EE modules (EARs, WARs, etc.) or deployment plans
and the configuration management system described above. It essentially
combines modules with plans and generates Configurations.

It comprises three parts:
* External interfaces such as the command line tool, console or JSR-88
   provider that get the modules and plans from the user
* ConfigurationBuilders such as EARConfigBuilder and
   ServiceConfigBuilder that do the combination and produce the target
* Back-end interfaces that store the Configuration either in a
   ConfigurationStore or as an output file

The ConfigurationBuilders are GBeans and run inside a Geronimo kernel.
Apart from ease of implementation, they also have access to the
resources provided by that system - for example, they can use the
Repository to load classes during processing, and they can use the
ConfigurationManager to load other Configurations that the target may be
dependent on.

To support online deployment, we run a deployment system inside the same
kernel as the J2EE server - it is actually part of the
org/apache/geronimo/Server Configuration although work is progress to
allow it to be run as a separate dependent configuation.

The JSR-88 provider interacts with this deployment system to fulfill the
spec requirements for distribute, start, stop, undeploy etc. For
example, during a distribute operation the module and plan are passed to
the deployment system, it uses an EARConfigBuilder to produce the output
Configuration, which it then installs in the target ConfigurationStore.
A JSR-88 start operation causes the Configuration to be loaded from the
store and then started.

However, this leaves us with a chicken-and-egg problem. The online
deployment system above is itself part of a configuration - how do we
build that configuation?

To solve this, and because it seemed generally useful, we built a
standalone offline deployment system. Run from the command line, this
would take module + plan and produce a Configuration. To reuse as much 
of the configuration building infrastructure as possible, it boots an
embedded Geronimo kernel and loads a Configuration containing just the
deployment system. As a running kernel, it also provides access to a
Repository and ConfigurationStore that the ConfigurationBuilders can use
to resolve dependencies (including dependencies on other
Configurations). However, these are *its* Repository and
ConfigurationStores and *not* those from the target server.

To cheat our way around the chicken-and-egg problem we took the simple
but expedient solution of having the standalone deployer and the default
server use the same type and location of store and repository. Then, by
simply telling the standalone deployer to install a configuration into
its own store it would also be available to the default server
configuration. This is a hack, pure, simple and effective.

When we introduce any additional complexity into the situation, then
this hack starts to break down. For example, if the user adds a
database-based ConfigurationStore to the server (for example, to make
GBean state persistence more reliable) then the standalone deployer
would not be able to install the generated Configuration into that store.

All things considered, I think having options in the standalone deployer
that rely on it sharing the same type and location of Repository and
ConfigurationStore will lead to obscure behaviour and strange behaviour
as soon as we progress beyond the most basic default configuration. That
is why I voted at the start for "2 simple tools rather than one complex
one."  Going further as has been proposed and coupling the standalone
deployer to the internal implementation of the
PersistentConfigurationList seems like pouring gasoline on the fire.

I have been portrayed on this list as being alone in my opinion but I
will point out that in the initial vote Eric LeGoff, Aaron Mulder and
David Jencks also voted for 2 tools (as opposed to Peter Lynch, Davanum
Srinivas, Hiram Chirino and Bruce Snyder who voted for one); Dain
Sundstrom voted for one tool, but wanted another to support the
functionality we have to output Configurations as jars ("that is another
tool for another day" but we need it now to build the server) which
sounds like two tools to me.

After that vote, Aaron proposed and attained consensus for a single
tool. The syntax is simple enough and mirrors the JSR-88 API making it
ideal for online deployment (which is all JSR-88 supports).

However, during implementation Aaron ran into the issues described above
and on the thread from 11/4/04 when trying to support the offline mode
not covered by JSR-88. These are clearly technical issues which we need
to resolve. To facilitate that, Aaron proposed to commit his work so
that all could see and discuss; he and I were promptly and unjustifiably
  flamed by some members of the community.

Since Thursday he has committed this code and I think we need to review 
where we are. My belief is that the online side is fully implemented, 
that the standalone deployer works as before (package option), and the 
big remaining issue is the one described above where someone is trying 
to "deploy" applications to an offline server.

In this message

I wrote that you could distribute to your heart's content; this was
wrong. The discussion with Aaron highlighted that the problem about
store type and location applies to distribute as well as the other
operations. It looks like the only thing you can reliably do offline is
package a Configuration for later use.

I would suggest then, rather than the --add option I proposed for the
server we instead have a --install option which boots the server,
restarts all previously running configs and installs the new one. The
offline usage would then be:

java -jar deployer.jar package foo.war foo-plan.xml
java -jar server.jar --install

This also provides a simple mechanism for deploying once and running 
everywhere: the output configuration can be installed in multiple places 
as easily as one.

The issue with this is that it fits the admin's view better than the
developer's. However, I continue to believe the:

   start server
      write code
      build (with distribute/start to online server)
   until app works or it's time to go home

cycle is what most developers use and that Aaron's changes (in
conjunction with the existing Maven plugin) have made it easy for them
to work that way. They are not really interested in fancy offline
deployment tricks.

To support carrier-grade configuration management, clustered and grid
environments and OEMs, I believe we need an effective way of generating
pre-packaged configurations using requires Maven/Ant plugins
that can be used in the release process, tools like Aaron's that an
administrator can use from the command line, and mechanisms for
installing them in and for transporting them between between servers.

I think we are very close to achieving this and if we can address these
last issues then Geronimo will be acceptable to both the developer
community and to serious IT decision makers.


View raw message