DeploymentPlanner - Base class

[gianny DAMOUR <gi...@hotmail.com>]

Hello,


This is my third try to implement a base deployment planner.

This shot is still very closed to my previous one, however it adds various 
capabilities showing the advantage of such an approach. For the history, 
this approach has been designed by others and I took over the 
implementation.

The new features are:

* DeploymentContext defines now the following JMX operations:

    public void startDeployment() throws DeploymentException;
    public void stopDeployment() throws DeploymentException;
    public void undeployDeployment() throws DeploymentException;
    public void redeployDeployment() throws DeploymentException;

These operations trigger the expected deployment action on a deployment 
unit. More accurately, it triggers the planning of a deployment context goal 
(package org.apache.geronimo.deployment.goal) and the execution of the 
resulting plan set. The planning is performed by the deployment planner, 
which has mounted this deployment context, and the execution is delegated to 
the DeploymentController.

* A deployment repository has been added in order to track the deployments 
currently mounted. By now, only the "registered" files of deployments are 
tracked. In the future (I need to clean this part), deployment states will 
also be tracked. The goal of this repository is to simplify the 
implementation of ApplicationDeployer.

As I said, "registered" files are tracked. More accurately, a scanner checks 
these files and upon modification executes a command. By now, two files are 
automatically created in order to trigger either the redeployment or the 
undeployment of a deployment. For instance, when an archive module – 
archive.jar in the example - is deployed, the following files are created, 
if required:
archive.jar_REDEPLOY: if one "touch"es this file, then the deployment is 
redeployed; and
archive.jar_UNDEPLOY: if one "touch"es this file, then the deployment is 
undeployed.

These two files are here only as a development convenience.

At the end of the day, I believe that DeploymentController should not be the 
entry point to action a start, stop, redeployment or undeployment. Why? 
Because one knows, which planner has mounted a deployment and hence one can 
bypass DeploymentController.

Hopefully, this approach will simplify the implementation of 
ApplicationDeployer. Indeed, ApplicationDeployer will only leverage the 
above deployment repository in order to perform deployment actions.

Regarding ApplicationDeployer, I am not convinced that we are tackling the 
problem correctly for the distribute operation. It seems that we will always 
distribute and that this is a client push operation. Why always distribute? 
Why a client push? WebLogic has various deployment policies (stage, no 
stage, manual stage), which are more "clever". Moreover, I think that the 
distribute operation, more accurately its "file  transfert" part, should be 
a task. The main advantage is that the call to distribute will not be 
blocking during the "file transfert" execution. In other words, I propose to 
reverse the distribute operation and to opt for a server pull. I will 
implement such a solution in order to show this other approach.

BTW, I tried to refactor ServiceDeploymentPlanner and this is not so simple: 
ServiceDeploymentPlanner is a kernel service. if one wants to align it with 
the proposed approach, then one must re-package a lot of classes from the 
core sub-project to the kernel sub-project. For instance, as the proposed 
approach defines a class which extends AbstractManagedContainer, one needs 
to re-package the Container, Component, AbstractManagedComponent et cetera 
classes.

The new code is referenced by GERONIMO-106: patch-Deployment.jar and 
patch-Deployment.txt.

Cheers,
Gianny

_________________________________________________________________
MSN Search, le moteur de recherche qui pense comme vous !  
http://search.msn.fr

Re: DeploymentPlanner - Base class

[Dain Sundstrom <da...@coredevelopers.net>]

On Tuesday, November 4, 2003, at 09:53 AM, Aaron Mulder wrote:

> On Tue, 4 Nov 2003, Dain Sundstrom wrote:
>> That is what I thought.  We can easily find all deployments with an
>> ObjectName pattern query.
>> ...
>> That won't work.  Dependencies are static and so are notification
>> listeners, so when every you changed states you would have to
>> reestablish all dependencies and any listener would have to 
>> reregister.
>
> 	Well, most of the JSR-88 methods want to get a list of modules in
> a particular state (running, stopped, etc.).  Do you think it's worth
> using an ObjectName query and then individually querying every module 
> for
> its state as opposed to trying to maintain a indexed list of every 
> module
> with its state and type?

It depends on how often it happens.  My guess is the deployment stuff 
will not be heavily used (non-critical path) so it doesn't matter if it 
is a bit inefficient.  The safest and simplest method is the query and 
poll approach, but if it proves to be too slow, we can keep an indexed 
list by watching for registration and state change events.  I prefer 
these solutions to avoid having to be plumbed into every deployment 
planner and to avoid missing deployments that did not use a planner.

-dain

Re: DeploymentPlanner - Base class

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

On Tue, 4 Nov 2003, Dain Sundstrom wrote:
> That is what I thought.  We can easily find all deployments with an 
> ObjectName pattern query.
> ...
> That won't work.  Dependencies are static and so are notification 
> listeners, so when every you changed states you would have to 
> reestablish all dependencies and any listener would have to reregister.

	Well, most of the JSR-88 methods want to get a list of modules in
a particular state (running, stopped, etc.).  Do you think it's worth
using an ObjectName query and then individually querying every module for
its state as opposed to trying to maintain a indexed list of every module
with its state and type?

Aaron

Re: DeploymentPlanner - Base class

[Dain Sundstrom <da...@coredevelopers.net>]

On Tuesday, November 4, 2003, at 07:34 AM, Aaron Mulder wrote:

> 	I thought we were going to use the JMX ObjectNames to identify
> deployments, rather than keeping an actual repository somewhere?

That is what I thought.  We can easily find all deployments with an 
ObjectName pattern query.

>  I guess
> one of the questions to answer on that score is whether we could put 
> the
> status as a property in the ObjectName and change it as the module is
> started, stopped, etc.  If so, then it's almost a no-brainer to do it 
> that
> way.  If not, then it would be more work to pull out the right subset 
> of
> deployed modules.

That won't work.  Dependencies are static and so are notification 
listeners, so when every you changed states you would have to 
reestablish all dependencies and any listener would have to reregister.

> 	I disagree with your assertion that the server should pull code on
> a distribute -- among other things, that assumes that the server can
> freely contact that client, which I don't think is necessarily true, 
> or a
> good idea.  However I do agree that the distribute call shouldn't 
> block --
> I asked earlier if there was a way to stream data to the server over 
> JMX
> and got no answer, so I think we need to set up a standard servlet to
> receive the data or something.

Agree.  We need some sort of bulk file transfer system.  I think we 
should really look at using WebDav for this.

>> As I said, "registered" files are tracked. More accurately, a scanner 
>> checks
>> these files and upon modification executes a command. By now, two 
>> files are
>> automatically created in order to trigger either the redeployment or 
>> the
>> undeployment of a deployment. For instance, when an archive module –
>> archive.jar in the example - is deployed, the following files are 
>> created,
>> if required:
>> archive.jar_REDEPLOY: if one "touch"es this file, then the deployment 
>> is
>> redeployed; and
>> archive.jar_UNDEPLOY: if one "touch"es this file, then the deployment 
>> is
>> undeployed.
>>
>> These two files are here only as a development convenience.

-1  I really dislike this idea.  The biggest problem is this code 
assumes that it can write to the hot deploy directory, but the real 
reason I dislike it is it removes the normal file semantics we are all 
use to.  If you want to redeploy, you simply touch the main deployment 
file, and if you want to undeploy, you remove the file.

>> At the end of the day, I believe that DeploymentController should not 
>> be the
>> entry point to action a start, stop, redeployment or undeployment. 
>> Why?
>> Because one knows, which planner has mounted a deployment and hence 
>> one can
>> bypass DeploymentController.

You are assuming that only one planner was involved in the deployment.  
What about ear and other meta deployments.

>> BTW, I tried to refactor ServiceDeploymentPlanner and this is not so 
>> simple:
>> ServiceDeploymentPlanner is a kernel service. if one wants to align 
>> it with
>> the proposed approach, then one must re-package a lot of classes from 
>> the
>> core sub-project to the kernel sub-project. For instance, as the 
>> proposed
>> approach defines a class which extends AbstractManagedContainer, one 
>> needs
>> to re-package the Container, Component, AbstractManagedComponent et 
>> cetera
>> classes.

Why is ServiceDeploymentPlanner a Container now?  I dislike the idea of 
pulling this stuff into kernel unless it is absolutely necessary.

-dain

Re: DeploymentPlanner - Base class

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

	I thought we were going to use the JMX ObjectNames to identify 
deployments, rather than keeping an actual repository somewhere?  I guess 
one of the questions to answer on that score is whether we could put the 
status as a property in the ObjectName and change it as the module is 
started, stopped, etc.  If so, then it's almost a no-brainer to do it that 
way.  If not, then it would be more work to pull out the right subset of 
deployed modules.

	I disagree with your assertion that the server should pull code on
a distribute -- among other things, that assumes that the server can
freely contact that client, which I don't think is necessarily true, or a
good idea.  However I do agree that the distribute call shouldn't block --
I asked earlier if there was a way to stream data to the server over JMX
and got no answer, so I think we need to set up a standard servlet to
receive the data or something.

Aaron

On Tue, 4 Nov 2003, gianny DAMOUR wrote:
> Hello,
> 
> 
> This is my third try to implement a base deployment planner.
> 
> This shot is still very closed to my previous one, however it adds various 
> capabilities showing the advantage of such an approach. For the history, 
> this approach has been designed by others and I took over the 
> implementation.
> 
> The new features are:
> 
> * DeploymentContext defines now the following JMX operations:
> 
>     public void startDeployment() throws DeploymentException;
>     public void stopDeployment() throws DeploymentException;
>     public void undeployDeployment() throws DeploymentException;
>     public void redeployDeployment() throws DeploymentException;
> 
> These operations trigger the expected deployment action on a deployment 
> unit. More accurately, it triggers the planning of a deployment context goal 
> (package org.apache.geronimo.deployment.goal) and the execution of the 
> resulting plan set. The planning is performed by the deployment planner, 
> which has mounted this deployment context, and the execution is delegated to 
> the DeploymentController.
> 
> * A deployment repository has been added in order to track the deployments 
> currently mounted. By now, only the "registered" files of deployments are 
> tracked. In the future (I need to clean this part), deployment states will 
> also be tracked. The goal of this repository is to simplify the 
> implementation of ApplicationDeployer.
> 
> As I said, "registered" files are tracked. More accurately, a scanner checks 
> these files and upon modification executes a command. By now, two files are 
> automatically created in order to trigger either the redeployment or the 
> undeployment of a deployment. For instance, when an archive module – 
> archive.jar in the example - is deployed, the following files are created, 
> if required:
> archive.jar_REDEPLOY: if one "touch"es this file, then the deployment is 
> redeployed; and
> archive.jar_UNDEPLOY: if one "touch"es this file, then the deployment is 
> undeployed.
> 
> These two files are here only as a development convenience.
> 
> At the end of the day, I believe that DeploymentController should not be the 
> entry point to action a start, stop, redeployment or undeployment. Why? 
> Because one knows, which planner has mounted a deployment and hence one can 
> bypass DeploymentController.
> 
> Hopefully, this approach will simplify the implementation of 
> ApplicationDeployer. Indeed, ApplicationDeployer will only leverage the 
> above deployment repository in order to perform deployment actions.
> 
> Regarding ApplicationDeployer, I am not convinced that we are tackling the 
> problem correctly for the distribute operation. It seems that we will always 
> distribute and that this is a client push operation. Why always distribute? 
> Why a client push? WebLogic has various deployment policies (stage, no 
> stage, manual stage), which are more "clever". Moreover, I think that the 
> distribute operation, more accurately its "file  transfert" part, should be 
> a task. The main advantage is that the call to distribute will not be 
> blocking during the "file transfert" execution. In other words, I propose to 
> reverse the distribute operation and to opt for a server pull. I will 
> implement such a solution in order to show this other approach.
> 
> BTW, I tried to refactor ServiceDeploymentPlanner and this is not so simple: 
> ServiceDeploymentPlanner is a kernel service. if one wants to align it with 
> the proposed approach, then one must re-package a lot of classes from the 
> core sub-project to the kernel sub-project. For instance, as the proposed 
> approach defines a class which extends AbstractManagedContainer, one needs 
> to re-package the Container, Component, AbstractManagedComponent et cetera 
> classes.
> 
> The new code is referenced by GERONIMO-106: patch-Deployment.jar and 
> patch-Deployment.txt.
> 
> Cheers,
> Gianny
> 
> _________________________________________________________________
> MSN Search, le moteur de recherche qui pense comme vous !  
> http://search.msn.fr
>