geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@4quarters.com>
Subject Re: deployment (oh, how I hate to go here...)
Date Mon, 07 Feb 2005 18:38:45 GMT

On Feb 7, 2005, at 1:04 PM, Dain Sundstrom wrote:

> On Feb 7, 2005, at 7:34 AM, Geir Magnusson Jr. wrote:
>
>> It seems I can "deploy" to a running server and "distribute" to a 
>> non-running server. I understand the technical difference, but I 
>> don't grok why we need this difference, and more importantly, why I 
>> can't "undistribute" in the event of a mistake...
>
> This has bugged me for a while

I've come to the conclusion that we have, from a users POV

a) live server deployment - can deploy to a running server somewhere, 
local or remote

b) local stopped server installation - seems to add files and update an 
index in the local servers config-store

and what I was thinking of as 'offline deployment' doesn't exist.

That's fine.  We can just add it at some point when we have time.

>
>> I was perusing JSR88, and it seems to indicate that distribute, 
>> start, stop, undeploy and redeploy are the "verbs", all applying to a 
>> running server.  There seems to be no concept of offline for JSR88 
>> that's useful.
>
> Just because spec choose to ignore offline deployment doesn't mean 
> that the "verbs" applied to a stopped server don't have meaning to the 
> average joe.

What does "stop", applied to a stopped server, mean to the average joe? 
  Or undeploy?  Right now, we can't undeploy from a stopped server. (Nor 
do I think we should...  the only thing I would suggest to do this to 
avoid having to dork w/ the servers private files is some sort of 
'command object' that one could leave around for the server to pick up 
that gets it to undeploy or -ish when it wakes up.

And lets distinguish between what seems to be the definition of 
"offline" here, meaning "I can do stuff locally to the file system 
because if have access and know the layout" and what I think 
"disconnected" means in 88 (since "offline" doesn't appear to be a 
defined concept).  I think that "disconnected" is a limited functional 
set, described as

"A DeploymentManager running disconnected from its J2EE
product can only configure modules but not perform administrative 
operations.
It might not have access to any product resources. If any of the 
administrative
operations, distribute, start, stop, undeploy, or redeploy are called,
an IllegalStateException must be thrown."

(JSR-88, 4.1, bullet # 3)

Maybe Aaron can shed more light on this.

>
>> 1) A JSR-88 compliant tool that is strict in it's support of the 
>> spec, asymmetry and all.
>>
>> 2) A Geronimo-specific tool that lets me have the nifty things you 
>> guys designed into this, like a redistributable configuration 
>> archive.  I'll go re-read the threads...
>
> I an definitely against having more then one deploy tool.

To me, the issue isn't the number of them, because we're talking about 
two different functional requirements.  The JSR-88 tool is designed for 
J2EE specifically, and can't by definition do things that are 
Geronimo's "value add" to the J2EE specification.  I'm all for having a 
generic JSR-88 tool, but I don't see why the existence of that would 
prohibit us from having our own Geronimo-specific tool.

>  It is like having a mail reader to read internet mail and a separate 
> mail tool to read corporate mail.  Mail is mail and deployment is 
> deployment.

That's reasonable if you are talking about /usr/bin/mail on a unix 
system, reading the local mbox file,  but for any modern mail client, 
there are separate handlers for the protocols.  For example, reading 
the local mbox, accessing POP3, accessing IMAP are all different, 
handled by subsystems.  I don't care if we have only one Official 
Deployment Tool, but it can easily be a wrapper around handlers for the 
different kinds of deployment.  I assume that would be ok, unless you 
require there be only one deployer Class or something, but i don't 
think that's what you mean.

I knew I didn't want to go here :)

geir


>
>
> On Feb 7, 2005, at 8:22 AM, Aaron Mulder wrote:
>
>> 	As we left ApacheCon, there was a strategy established for the
>> best way to handle deployment, and specifically offline deployment -- 
>> I
>> think David J understood it best.  I assume it was a procedure for 
>> loading
>> "just enough" of the server to get the correct config store, etc., 
>> but I'd
>> have to look at the mail trail myself.
>
> I remember everyone liking the strategy, but I can't remember it 
> myself anymore :)  Maybe David, can jog our memories.
>
> On Feb 7, 2005, at 8:28 AM, Geir Magnusson Jr. wrote:
>
>> IOW, I should be able to, in a parallel universe where no Geronimo 
>> server exists, run the deployer and produce a instance-independent 
>> artifact (I think they have been called 'configuration archives') 
>> that I can then transport through a rift in the time-space continuum 
>> and give to you to deploy on your machine.
>>
>> Now, if you don't buy the parallel universe schtick, imagine a 
>> regular production environment where developers have absolutely zero 
>> access to the production machine, and are probably separated by 1-2 
>> layers of QA and testing, either something like
>>
>>   dev ->   QA  ->  prod
>>
>> or
>>
>>   dev -> QA -> stage/client eval -> prod
>>
>> In my past, deployment to QA systems came from tagged CVS.  After 
>> passing QA, it was deployed to staging system from a tag in CVS... 
>> same w/ prod.   Ops didn't get to modify things, like where to find 
>> the database and ish.
>
> The parallel universe scenario doesn't work anyway.  The generated CAR 
> files are basically keyed to the server that generated them.  Maybe 
> with a ton of work one day we will be able to do that, but for the 
> foreseeable future it is not possible.
>
> -dain
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com


Mime
View raw message