geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <>
Subject Re: deployment (oh, how I hate to go here...)
Date Mon, 07 Feb 2005 16:28:24 GMT

On Feb 7, 2005, at 11:22 AM, Aaron Mulder wrote:

> 	If I can try to summarize briefly, here's the main problem with
> featureful offline support:
> 	The deployer doesn't know where the server is storing things it
> deploys, and doesn't know what configuration engine the server is 
> using to
> decide where it is storing things and what should be loaded at startup 
> and
> so on.  To get this information, the deployer would need to load a
> non-trivial amount of the server, at which point this practically *is* 
> an
> online deployment.  (Also: how would it work remotely?)

Ok - I understand what you are saying, but we're talking about 
"offline", and I have a slightly different POV of what that means.

To me, it doesn't mean the server that I have access to is just simply 
turned off.  I don't need to know anything about where the server 
stores anything.  I should have no clue where the server is.

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


   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.

> 	For a default setup, these things are well-known and we could
> solve the most common case by simply supporting the default.  It would,
> however, totally break for a non-default server configuration (e.g.
> storing deployments in database), and someone strongly objected to 
> this.
> There was some talk of "if you change your config store you must 
> rebuild
> your deploy tool" but that never really went anywhere.

I think that the config store should be indep of the deployment.  The 
deploy tool spits out a config_archive.jar, and that is given to a 
server for 'internal deployment'.  IOW, I shouldn't care one bit about 
the internals of the server.

I think of this in the 'unix way' - simple toolchain to create a 
thingy, and then another tool to send the thingy where it needs to go.

Maybe this is what was intended, that the module+plan is config-store 
agnostic, and we just lost the plot somewhere such that deployment can 
happen w/o any server nearby.  or maybe I just don't grok how to deploy 
w/o a server, and it's just a matter of documentation.

> 	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.
> Aaron
> P.S. I think JSR-88 is a red herring.  It has offline and online modes.

I know you're an 88 expert, and I know that I'm not.  I just got the 
sense glancing over the spec that the offline mode was fairly useless 
for the kind of thing we're talking about here.

> If we solve both problems, we can support them both in JSR-88.  The 
> main
> problem with JSR-88 and Geronimo is that JSR-88 doesn't have a facility
> for building "CAR" files or the executable JARs used to start the 
> server,
> deploy tool, client container, etc.  So our "deploy" tool, if it will 
> be
> used for those purposes, must support more than JSR-88 does, and thus
> cannot restrict itself to using only the JSR-88 API to talk to the 
> server.

Right.  But the 88 language is somewhat confusing, given the lack of 
symmetry (distribute/undeploy) and lack of a viable offline mode.  I 
don't think of the offline problem as a weakness in 88 as much as we're 
applying the wrong tool for the job - we're looking at doing something 
beyond the scope of 88, right?


> On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote:
>> I'm missing some important clue about deployment.
>> 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...
>> I'd hate to distribute the ImmediatelyScramNuclearReactorGBean and 
>> have
>> to start the server to remove it.
>> 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.
>> I remember the "Deployment Semantics Wars" of 2004 with much dread, 
>> and
>> don't wish to rekindle especially now as we're focused on J2EE
>> functionality, but can we revisit this?  I would imagine it would be
>> nice to have :
>> 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...
>> geir
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
Geir Magnusson Jr                                  +1-203-665-6437

View raw message