geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: deployment (oh, how I hate to go here...)
Date Mon, 07 Feb 2005 17:10:24 GMT
	Ah, right.  I guess we need to start every conversation by
clarifying the terminology.  :)  I think your scenario makes sense.  As
far as I know, we don't have robust handling for CAR files (fully baked
content, configuration, etc.) right now.  There are also some issues such
as if you create it based on one server environment (map resource refs,
etc.), what happens if you deploy to a different server with different
stuff running?

	I think JSR-88 envisioned that the code + deployment plan was the
abstract instance-independent module that you could later deploy,
undeploy, move, etc.  You seem to be envisioning a processed
instance-specific module that you could later deploy, undeploy, move, 
etc.  The advantage of yours is that more validation and pre-processing is 
done up front.  The advantage of JSR-88 is that it isn't assuming that the 
server you delpoy to is the same as the server you packaged for.  In other 
words, if you have to repeat all the validation and code generation and 
stuff just to ensure that the server you deploy to won't barf on the 
assumptions made by the pre-packaging tool, what's the advantage of the 

	In any case, it would be great if you could make a list of the 
features that you're looking for (e.g. the requirements) so we can talk 
about what is or should be implemented.


On Mon, 7 Feb 2005, Geir Magnusson Jr. wrote:
> 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
> 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.
> >
> > 	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?
> geir
> >
> > 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