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 [EMAIL PROTECTED]
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
