[Deployment] IM #2 Summary for Directory Issue

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

	Okay, had another IM conversation with Jeremy, and some new things
came to light, and I'll present this as an alternative to the previous
option.  As before, please feel free to chime in with feedback.

1) There will be some way of saving the current MBean state of the server
and reloading it later.  That way when you start the server, instead of
reprocessing all the config files, it will just "deserialize" the MBeans
into their previous state.  Then the deployment scanner will update that
state according to the current deploy directory (redeploying a service if
the config file changed, for example).  (Apparently this saving and
loading is a work in progress at the moment.)

2) There will be a "service controller" that manages the JSR-77 state of
various objects in the server.  I need to get more information about this
from Dain.  But the relevant part is that based on the above, all the
applications that were previously deployed have MBeans, and those MBeans
would brought back in the "stopped" state when the server is started.  
Then with the service controller in place, the service controller can go
try to start the ones that were formerly running.  Thus it is the service
controller (or if not, then the MBeans), not the individual app DDs, which
remember what state the different components are in.

2a) A possible corollary of "2" is that if the service controller knows
what should be running or not at any given time, that solves the problem
of what to do when something in the "deploy" directory is stopped.  The
service controller knows it was stopped, so we won't try to redeploy it
immediately.

3) Jeremy feels strongly that if you deploy an app via JSR-88, we should
just save it in a "working" directory and unpack it there, and not mix and
match JSR-88 deployment actions with "deploy directory" deployment
actions.  On the whole, I think we should focus on the larger differences
between this proposal and the last, and we can figure out whether to save 
downloads to the "working" directory or the "deploy" directory later.

Aaron

Re: [Deployment] IM #2 Summary for Directory Issue

["n. alex rupp" <ru...@umn.edu>]

I wish Richard and David B. would chime in on this subject.  The stuff below
makes sense to me, and I'm sure Jeremy has very good reasons for wanting to
keep the JSR 88 stuff separate (maybe he wrote them already and I missed
that post?)  Any details would be well appreciated (but I have faith, as
well--do as thou wilt)

Richard and some others spoke earlier about keeping the application archives
100% non-proprietary and having geronimo-specific information in its own
deployment descriptor outside of the archives, which can be easily adjusted
through the management console.  I like the simplicity of that approach from
the perspective of the user, so I'd like to press strongly for that.  If we
bog down the archives with geronimo specific deployment descriptors it won't
be the end of the world, but we won't exactly be putting the mints on the
pillows, either.

Night,
--
N. Alex Rupp (n_alex_rupp@users.sf.net)

----- Original Message ----- 
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Friday, October 03, 2003 5:38 PM
Subject: [Deployment] IM #2 Summary for Directory Issue


> Okay, had another IM conversation with Jeremy, and some new things
> came to light, and I'll present this as an alternative to the previous
> option.  As before, please feel free to chime in with feedback.
>
> 1) There will be some way of saving the current MBean state of the server
> and reloading it later.  That way when you start the server, instead of
> reprocessing all the config files, it will just "deserialize" the MBeans
> into their previous state.  Then the deployment scanner will update that
> state according to the current deploy directory (redeploying a service if
> the config file changed, for example).  (Apparently this saving and
> loading is a work in progress at the moment.)
>
> 2) There will be a "service controller" that manages the JSR-77 state of
> various objects in the server.  I need to get more information about this
> from Dain.  But the relevant part is that based on the above, all the
> applications that were previously deployed have MBeans, and those MBeans
> would brought back in the "stopped" state when the server is started.
> Then with the service controller in place, the service controller can go
> try to start the ones that were formerly running.  Thus it is the service
> controller (or if not, then the MBeans), not the individual app DDs, which
> remember what state the different components are in.
>
> 2a) A possible corollary of "2" is that if the service controller knows
> what should be running or not at any given time, that solves the problem
> of what to do when something in the "deploy" directory is stopped.  The
> service controller knows it was stopped, so we won't try to redeploy it
> immediately.
>
> 3) Jeremy feels strongly that if you deploy an app via JSR-88, we should
> just save it in a "working" directory and unpack it there, and not mix and
> match JSR-88 deployment actions with "deploy directory" deployment
> actions.  On the whole, I think we should focus on the larger differences
> between this proposal and the last, and we can figure out whether to save
> downloads to the "working" directory or the "deploy" directory later.
>
> Aaron
>
>

RE: [Deployment] IM #2 Summary for Directory Issue

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

> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu] 
> Sent: Friday, October 03, 2003 3:38 PM
> 
> 1) There will be some way of saving the current MBean state 
> of the server and reloading it later.  That way when you 
> start the server, instead of reprocessing all the config 
> files, it will just "deserialize" the MBeans into their 
> previous state.  Then the deployment scanner will update that 
> state according to the current deploy directory (redeploying 
> a service if the config file changed, for example).  
> (Apparently this saving and loading is a work in progress at 
> the moment.)
> 
> 2) There will be a "service controller" that manages the 
> JSR-77 state of various objects in the server.  I need to get 
> more information about this from Dain.  But the relevant part 
> is that based on the above, all the applications that were 
> previously deployed have MBeans, and those MBeans would 
> brought back in the "stopped" state when the server is started.  
> Then with the service controller in place, the service 
> controller can go try to start the ones that were formerly 
> running.  Thus it is the service controller (or if not, then 
> the MBeans), not the individual app DDs, which remember what 
> state the different components are in.
> 
> 2a) A possible corollary of "2" is that if the service 
> controller knows what should be running or not at any given 
> time, that solves the problem of what to do when something in 
> the "deploy" directory is stopped.  The service controller 
> knows it was stopped, so we won't try to redeploy it immediately.
> 
We should not confuse the different states here :-)

Firstly, there is configuration state - the values of MBean attributes
that can be persisted.

Secondly, there is operational state - the started/stopped/failed state
as define in JSR77. This is a transient attribute of the MBean
defaulting to stopped, so after a restore the MBean is initialized but
not started. One role of the service controller is to ensure all MBeans
get started in an order that satisfies their dependencies.

So the server startup is basically two phase:
1) "Cold start" where the MBeans are recreated from persistent
    store. When this has completed, all MBeans are present and
    in the JSR77 STOPPED state.

2) "Warm start" where the service controller starts each MBean 
    in the correct order.

The service controller persists the JSR77 state of each MBean and
listens to JSR77 state change events to ensure its persistent version
matches the running state of the server.


> 3) Jeremy feels strongly that if you deploy an app via 
> JSR-88, we should just save it in a "working" directory and 
> unpack it there, and not mix and match JSR-88 deployment 
> actions with "deploy directory" deployment actions.  On the 
> whole, I think we should focus on the larger differences 
> between this proposal and the last, and we can figure out 
> whether to save 
> downloads to the "working" directory or the "deploy" directory later.
> 

The key thing there is nothing magic about the "deploy" directory. It is
simply a URL monitored by a DeploymentScanner to support the
"drop-the-archive-in-the-directory" style of deployment used today. The
scanner watches that directory and supplies a list of archive URLs to
the DeploymentPlanner which orchestrates their deployment.

The actual deployment process may require that an archive gets copied
locally and/or unpacked - for example, a WAR located at an http: URL
will need to be expanded to local files before TC/Jetty can use it. We
will need a separate "working" directory so hold these copies, but it
does not matter if the content was created from a source URL supplied by
the user or from a URL found by a DeploymentScanner.

The reasons that I don't think things should be stored in the "deploy"
directory are:
1) Its role as input to the scanner means that access to it is
read-only.
   I would not anticipate having write access to it - e.g. if it is
   located on a WebDAV server, the ability to write may only be
   exposed to local users and not the server (which is the WebDAV
client).
   Or, the user the server is running as just doesn't have permission to
   write to the directory.

2) The confusion between deployment using an API (via 88) and by
   dropping a file in a directory.

--
Jeremy