You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Geir Magnusson Jr." <ge...@apache.org> on 2005/02/07 16:34:46 UTC
deployment (oh, how I hate to go here...)
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
Re: deployment (oh, how I hate to go here...)
Posted by Jeremy Boynes <jb...@apache.org>.
sissonj@insession.com wrote:
>
> IMHO, if partially starting the server means that a EAR/WAR/CAR can't be
> deployed remotely then I don't think that is practical as a user may want
> to build and deploy the CAR from a GUI PC/workstation (possibly using a
> GUI deployment tool) to a remote headless server.
>
> Does anyone have a link to some more info about CAR files? I could only
> find
> http://java.sun.com/j2ee/1.4/docs/api/javax/enterprise/deploy/shared/ModuleType.html
>
The CAR Aaron is referring to is a Configuration Archive which is a
Geronimo concept and not a J2EE Application Client Archive as described
by ModuleType. Sorry for the confusion.
I wrote a long mail summarizing my views on online vs. offline
deployment back in Nov that goes into Geronimo packaging:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=dev@geronimo.apache.org&msgNo=9851
The intent behind a (Geronimo) CAR file is that it is a versioned,
sealable artifact containing both code and configuration state that can
be transported between Geronimo installations. It is the external form
of a Configuration, which is a package of services that can be hosted by
a Kernel.
A Configuration is startable if its codebase dependencies can be
resolved (using the installation's Repository services) and all of the
GBeans it contains (defined as a collection of GBeanInfo + GBeanState
objects) can be instantiated and brought online in the STOPPED state.
Individual GBean inside the Configuration may or may not be startable
depending on whether their (service) references are resolvable.
The Kernel only knows about Configuration packages - it has no knowledge
of user-land packaging artifacts such as J2EE WARs or EARs. The job of
converting user-land artifacts into Configurations is done by a
ConfigurationBuilder working in conjunction with a set of ModuleBuilders
- the process of doing this is loosely called deployment. The
ConfigurationBuilder can be as complex as needed to get this job done -
it might be fairly simple like the one for service.xml files, it might
be quite complex like the J2EE one.
To build a Configuration, a builder may need access to other
Configurations on which the one being build has /code/ level
dependencies. For example, to introspect an EJB class the EJB builder
would require the javax.ejb.* classes to be available, just like the EJB
itself would need them at runtime. Thus during the build process, the
builder needs to resolve code dependencies declared by the target
Configuration; however, it does not need to resolve /service/
dependencies such as the availability of other GBeans.
This allows "offline" deployment, for example from a PC/Workstation. The
intention is that a user can build a (Geronimo) CAR file in that
environment, sign, seal and deliver it, handing off to an enterprise
configuration management/provisioning process. That same (sealed) CAR
file can be sent to any Geronimo server running anywhere in the
enterprise (or outside) with confidence that, assuming the necessary
code and services are available at that site, it will run as intended.
This is aimed purely and simply at enterprise users who have to deal
with a lot of configurations and installations; it is not a model aimed
at supporting iterative build/test cycles on a single desktop.
For that we have "online" deployment where a running server actually
hosts its own deployment framework. A developer can hand a user-land
module and a plan to the server using some mechanism such as Maven or a
JSR-88 client, have it build the Configuration in-situ and bring online
autoamtically in that local server ready for testing. This, of course,
relies on the server being running.
To me this is a fairly simple solution that addresses the different
needs of the two communities. However, at this time only online mode
really works; although offline mode can generate CAR files, we are
missing a way to easily import them into the target server.
--
Jeremy
Re: deployment (oh, how I hate to go here...)
Posted by si...@insession.com.
Aaron Mulder <am...@alumni.princeton.edu> wrote on 08/02/2005 06:36:39
AM:
> On Mon, 7 Feb 2005, Geir Magnusson Jr wrote:
> > "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.
>
> My interpretation was "will probably be thrown", but if the spec
> says "must be thrown" then there's not too much to be done. The idea
was
> that if you're connected you can do anything, but if you're not
connected,
> you should still be able to configure and save a deployment plan and so
> on, you just might not (or in this case, must not) be able to actually
try
> to send your application and plan to the server.
>
> In any case, I agree that the offline behavior you're looking for
> is not implemented. And if you're looking to do it for arbitrary GBean
> configurations (not just J2EE modules), it would be tough to shoehorn it
> fully into JSR-88. So we can either go with two tools (which no one
much
> likes) or one tool that's "JSR-88 plus", using JSR-88 where appropriate
> but offering additional Geronimo-specific features too.
>
> Still, I think we have more work to do on the requirements. For
> example, when we create a "CAR" (the archive of stuff that you can just
> drop in to a server), what should go in it? What processing gets done
> when creating the CAR and what when deploying the CAR? Should the
server
> need to be online to distribute the CAR, or should we implement the
logic
> David described to partially start the server in order to do stuff, or
> should there be some "todo" directory where you dump stuff that you
want
> the server to execute when it starts? If the latter, how do you handle
> conflicting commands or code in there? Should a CAR be "sealed" or
should
> there be some way to update it (for example, if QA and Prod environments
> have different users that you want to include in the role mapping)?
>
> Aaron
IMHO, if partially starting the server means that a EAR/WAR/CAR can't be
deployed remotely then I don't think that is practical as a user may want
to build and deploy the CAR from a GUI PC/workstation (possibly using a
GUI deployment tool) to a remote headless server.
Does anyone have a link to some more info about CAR files? I could only
find
http://java.sun.com/j2ee/1.4/docs/api/javax/enterprise/deploy/shared/ModuleType.html
Thanks,
John
Re: deployment (oh, how I hate to go here...)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Mon, 7 Feb 2005, Geir Magnusson Jr wrote:
> "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.
My interpretation was "will probably be thrown", but if the spec
says "must be thrown" then there's not too much to be done. The idea was
that if you're connected you can do anything, but if you're not connected,
you should still be able to configure and save a deployment plan and so
on, you just might not (or in this case, must not) be able to actually try
to send your application and plan to the server.
In any case, I agree that the offline behavior you're looking for
is not implemented. And if you're looking to do it for arbitrary GBean
configurations (not just J2EE modules), it would be tough to shoehorn it
fully into JSR-88. So we can either go with two tools (which no one much
likes) or one tool that's "JSR-88 plus", using JSR-88 where appropriate
but offering additional Geronimo-specific features too.
Still, I think we have more work to do on the requirements. For
example, when we create a "CAR" (the archive of stuff that you can just
drop in to a server), what should go in it? What processing gets done
when creating the CAR and what when deploying the CAR? Should the server
need to be online to distribute the CAR, or should we implement the logic
David described to partially start the server in order to do stuff, or
should there be some "todo" directory where you dump stuff that you want
the server to execute when it starts? If the latter, how do you handle
conflicting commands or code in there? Should a CAR be "sealed" or should
there be some way to update it (for example, if QA and Prod environments
have different users that you want to include in the role mapping)?
Aaron
Re: deployment (oh, how I hate to go here...)
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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
Re: deployment (oh, how I hate to go here...)
Posted by David Jencks <da...@yahoo.com>.
On Feb 7, 2005, at 10:04 AM, 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 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.
>
>> 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. 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.
>
>
> 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.
The idea is to basically:
1. have a micro-pre-deployer-thingy that looks at what you are trying
to deploy and determines its parentId. This probably requires little
bits of each builder to recognize the package and give back a default
parentId if its missing.
2. the main part of the builders is in a special configuration. The
predeployer sets it's parentId to the parentId of the package you are
trying to deploy, and loads and starts it, then calls the deployer in
it to build stuff.
The point is to only have one "deployer" plan, and to get all possible
usable classes into its parent classloader and to try to avoid all
duplicate class loading problems. I'm not sure how it relates to this
discussion.
thanks
david jencks
>
> 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
>
Re: deployment (oh, how I hate to go here...)
Posted by Dain Sundstrom <ds...@gluecode.com>.
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 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.
> 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. 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.
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
Re: deployment (oh, how I hate to go here...)
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
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
Re: deployment (oh, how I hate to go here...)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
pre-packaging?
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.
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
>
>
Re: deployment (oh, how I hate to go here...)
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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
Re: deployment (oh, how I hate to go here...)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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?)
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.
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.
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.
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
>
>