[Deployment] IM Summary for Directory Issue

[Aaron Mulder <am...@alumni.princeton.edu>]

	Alex and I talked a bit more by IM, and this is what we came up 
with.  Please feel free to send any comments.

1) We will save all distributed files to one directory, and we will set 
that to be the same as the "deploy" directory by default (keeping all 
deployments in the same location, whether by user-copied files or by 
JSR-88).

2) For each application module in the deploy directory, we will save the
Geronimo-specific DD outside the module, with a name based on the module
name ("foo.war" gets the DD "geronimo-deployment-foo.war.xml" or something
along those lines).

3) We will add tags to the DD to hold the deployment state of the module.  
When the module is distributed, started, stopped, etc. we will update the 
DD accordingly.

4)  When the server is started, it will deploy or not according to the
tags in the DDs.  If there is no state tag in the DD, we will assume that 
this is a new module to deploy and we will deploy it (and write in the 
state tag).

5) If no geronimo-specific DD is present, we will write one out to track 
the deployment state, and attempt to use intelligent defaults for the rest 
of the settings.

	This works fairly well for JSR-88, where the DD is maintained
outside of the archive and sent to the server separately, and it shouldn't
be too hard to implement for the directory scanning deployer (either the
user copies the DD along with the archive, or we extract the Geronimo DD
from a default location in the archive).

Aaron

Re: [Deployment] IM Summary for Directory Issue

[Greg Wilkins <gr...@mortbay.com>]

Aaron Mulder wrote:

 > 2) For each application module in the deploy directory, we will save the
 > Geronimo-specific DD outside the module, with a name based on the module
 > name ("foo.war" gets the DD "geronimo-deployment-foo.war.xml" or something
 > along those lines).
 > 3) We will add tags to the DD to hold the deployment state of the module.
 > When the module is distributed, started, stopped, etc. we will update the
 > DD accordingly.

While I like the idea of a flat file descriptors that describe the current
requested state of the system deployment.

HOWEVER!

I really don't like this trend we are developing for copy and modify of
data like deployment descriptors!

Why not simply have a deployment state descriptor for all geronimo services
that is stored in parallel directories to the deploy directories (what
ever they may end up being).

The deployment state descriptor would be common to all services and capture
all the jsr77/jsr88 stuff that it needs to.

I see no value in merging the deployment state with the deployment descriptors
(and I see little value in merging the geronimo deployment  descriptor with the
standard deployment descriptor).   We are going to end up with so many copies of
the standard descriptors - all of which persist of a server restart, that it is
going to be very very confusing.

cheers

RE: [Deployment] IM Summary for Directory Issue

[Jeremy Boynes <je...@coredevelopers.net>]

I think this thread has been superceded, but comments inline...

> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> Sent: Friday, October 03, 2003 2:32 PM
> To: geronimo-dev@incubator.apache.org
> Subject: [Deployment] IM Summary for Directory Issue
> 
> 
> 	Alex and I talked a bit more by IM, and this is what we came up 
> with.  Please feel free to send any comments.
> 
> 1) We will save all distributed files to one directory, and 
> we will set 
> that to be the same as the "deploy" directory by default (keeping all 
> deployments in the same location, whether by user-copied files or by 
> JSR-88).

I think this is confusing and may not even be possible (e.g. the server
may not have permission to write to the "deploy" directory).

> 
> 2) For each application module in the deploy directory, we 
> will save the Geronimo-specific DD outside the module, with a 
> name based on the module name ("foo.war" gets the DD 
> "geronimo-deployment-foo.war.xml" or something along those lines).
> 
> 3) We will add tags to the DD to hold the deployment state of 
> the module.  
> When the module is distributed, started, stopped, etc. we 
> will update the 
> DD accordingly.
> 

Storing this state is the responsibility of the service controller. We
do not need to copy the entire DD just to record the state of the MBean.
Indeed, the state of the MBeans involved is likely to be a superset of
the information in the DD.

> 4)  When the server is started, it will deploy or not 
> according to the tags in the DDs.  If there is no state tag 
> in the DD, we will assume that 
> this is a new module to deploy and we will deploy it (and 
> write in the 
> state tag).
> 
> 5) If no geronimo-specific DD is present, we will write one 
> out to track 
> the deployment state, and attempt to use intelligent defaults 
> for the rest 
> of the settings.
> 
> 	This works fairly well for JSR-88, where the DD is 
> maintained outside of the archive and sent to the server 
> separately, and it shouldn't be too hard to implement for the 
> directory scanning deployer (either the user copies the DD 
> along with the archive, or we extract the Geronimo DD from a 
> default location in the archive).
> 

The geronimo-specific DD is one representation of the vendor-specific
configuration of the archive; there may be others (e.g. some entry in a
config management system). Defining this configuration is the first step
in the deployment process; distribution and start are separate steps and
I don't think we should mix the information they use.

--
Jeremy