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 17:30:08 GMT

On Feb 7, 2005, at 12:10 PM, Aaron Mulder wrote:

> 	Ah, right.  I guess we need to start every conversation by
> clarifying the terminology.  :)

Cool!

>  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?

Sure.

>
> 	I think JSR-88 envisioned that the code + deployment plan was the
> abstract instance-independent module that you could later deploy,
> undeploy, move, etc.

The problem I have is that JSR-88 is J2EE specific, so what do we do 
for people who don't care about J2EE and want to use Geronimo The 
Container for other purposes?


>  You seem to be envisioning a processed
> instance-specific module that you could later deploy, undeploy, move,
> etc.

Not sure about undeploy and move, but certainly move around and deploy 
to any server that could meet it's dependency and resource needs.


>   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
> pre-packaging?

That makes sense if we are just trying to do a generic JSR-88 tool - 
which I think would be nice to have around - but if we then can't take 
advantage of Geronimo features that aren't part of J2EE or JSR-88, then 
we have a problem.

> 	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.

I'll do that.  First one that comes to mind is what triggered this, 
namely "undistribute". :)

geir

>
> Aaron
>
> 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
>>>> geirm@apache.org
>>>>
>>>>
>>>
>>>
>> -- 
>> Geir Magnusson Jr                                  +1-203-665-6437
>> geirm@apache.org
>>
>>
>
>
-- 
Geir Magnusson Jr                                  +1-203-665-6437
geir@gluecode.com


Mime
View raw message