geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Please Vote: 1 deployment tool or 2?
Date Thu, 28 Oct 2004 22:54:53 GMT
On Oct 28, 2004, at 11:35 AM, Aaron Mulder wrote:

> On Thu, 28 Oct 2004, Dain Sundstrom wrote:
>> These are the main commands.  I like hiram's idea of dropping the --
>> from them like svn and cvs do.  I don't see why you have extra
>> restrictions on install.  Actually, why not just drop install since it
>> is just deploy?
>
> 	Sure, we can restructure the syntax.  The difference
> between install and deploy would be clearer if we called them 
> "distribute"
> and "deploy" to match the JSR-88 terms -- I only used "install" 
> because I
> thought we wanted to preserve the existing syntax.  So long as we're 
> going
> to change it anyway...
> 	But the difference is that "distribute" does not start a module,
> so "deploy == distribute + start".  In concept, you could distribute an
> app, make sure it gets processed and loaded on to all the servers, and
> then bang! issue a start command to start them all at once.  I guess.  
> I
> don't really plan to use that much myself, but since the API 
> capability is
> there, why not allow it from the tool?  We can just list that under
> "rarely used".

+ 1

> 	Also, "start" is not meaningful for the current deployer -- not
> only can it not start because the server is not running, it does not 
> alter
> the configuration in such a way that the module should be started next
> time the server is started.  So "install" in the current tool really is
> equivalent to "distribute" not "deploy".  If we want the default 
> command
> to be "deploy", then when the tool runs in "server is offline" mode 
> (like
> the current tool), it should update var/config/config.list to add the
> module to that.

+1

>>> --modulelist    a list of TargetModuleID names to start, stop, or
>>>                    undeploy
>>>
>>> --list-modules  gives you a list of modules available from the
>>>                    management server you connected to.  defaults
>>>                    to all targets, or use --targets
>
>> What is the difference between these two?
>
> 	Well, when starting, stopping, or undeploying, you must give the
> server a list of TargetModuleIDs to start, stop, or undeploy.  Where a
> TargetModuleID is some product-specific amalgamation of a unique 
> server or
> cluster ("Target") ID and a module ID.  So if the same EAR is deployed 
> on
> 3 servers, you could stop it on 2 of them with 2 TargetModuleID's.  
> We'll
> have to think about what our Target IDs should look like, but they'll
> likely be ugly (host name and installation path, perhaps?) or else a
> unique name that a user configures somewhere, and the Target Module 
> ID's
> will presumably be that plus either a ConfigId or ObjectName 
> identifying
> the module.  I need to look at what the current TargetModuleID
> implementation does.
>
> 	Anyway, one of these arguments gives the list of TargetModuleIDs
> that you want to start, stop, etc.  The other is an inquiry command, 
> where
> you give it a list of targets, and it gives you back a list of
> TargetModuleIDs available on those targets.  So if you don't know what
> you're dealing with, it might go like this:
>
>>>> deployer list-targets
>    server1
>    server2
>    cluster
>>>> deployer list-modules --targets cluster
>    cluster/app1.ear
>    cluster/webapp2.war
>    cluster/dbpool.rar
>>>> deployer stop --modules cluster/webapp2.war,cluster/app1.ear
>    cluster/app1.ear stopped
>    cluster/webapp2.war stopped
>
> Perhaps we could omit the --modules argument and just assume 
> everything at
> the end of the command without a -- prefix is a module to operate on.

+1

>>> --list-targets  gives you a list of targets available from the
>>>                    management server you connected to
>>>
>>>  --targets       a list of targets to get modules for, or to install
>>>                    or deploy to.  defaults to all targets available
>>>                    from the current management server if a URL is
>>>                    specified or defaulted to.  defaults to the 
>>> current
>>>                    server environment only if the URL is null.
>>
>> These are almost never going to be used, so should be documented as 
>> such
>
> 	Well, until we implement clusters, or a single administration
> point for multiple servers (similar to WebLogic admin server + many
> managed servers).

Ya, but until we implement clusters, I doubt they will be used, and 
then we won't need them :)

>>> --classPath     classpath to set for an executable module
>>>
>>> --mainClass     main class for an executable module
>>>
>>> --outfile       build a CAR instead of deploying into the server
>>>                    environment
>>
>> Options of creating an output Jar... these are rarely used and should
>> be documented as such.
>
> 	I don't like them at all because they can't be done via JSR-88.
> So this introduces not only an additional implementation path, but also
> incompatibility with many of the other options that require JSR-88.

What do we care about 88 purity?  We can add what ever we want to our 
own tool.  If someone wants to use a limited cross platform tool, the 
can still use our raw driver.

> If nothing else, can we please please have another tool just to build
> output JARs?  This mode of operation has no relation to the normal
> deployer operation.

I agree, but that is another tool for another day.

>   (Though in truth, deploying while the server is not
> running has the same disadvantage.)

And it has some advantages... like if you mess up you server so it 
won't start, you can start over by redeploying the server plan.

>>> --driver        JAR of the server driver, if not already on 
>>> classpath.
>>>                    only necessary when non-Geronimo server targeted
>>
>> I don't think there is any reason for us to support other app servers
>> drivers.  This is a tool by geronimo for geronimo.  Let the ide 
>> vendors
>> come up with the universal adapter.
>
> 	If we implement it using JSR-88, which is the most straightforward
> way for all normal operations (so long as the server is running), then 
> we
> get support for other app servers for free.

Who cares?  I don't think we should limit our selves to pure 88 just so 
we can have support for other servers.  Frankly, I would be shocked if 
anyone used our command line tool for anther server, when every server 
ships with a tool custom to the server (with enhancements).

> 	Deployment while the server is not running is the tricky case.
> We can shoehorn it into JSR-88 by having a URL mode that requires that 
> a
> local Kernel be started before JSR-88 is invoked (like the way the
> deployer tool runs now), but Jeremy seemed to be strongly opposed to 
> this.
> I don't really like having 2 different code paths for standard 
> operation,
> though, so if we go with one tool I might favor this, hacky as it is.

I was totally with you, up to this section.  I don't think we shoe horn 
it at all.  If you are running offline, you simply execute the exiting 
code, which isn't 88 at all.  Use 88 when it is nice fit and something 
custom when it isn't.

>> So I see the following as being the most common usage:
>>
>> deployer deploy funk.war
>> deployer undeploy funk
>
> 	Unfortunately, both of these are illegal according to JSR-88.  You
> need to specify a deployment plan for the module, and to undeploy you
> need to specify a target module ID including the target name and the
> module name.

Again, I frankly don't care what 88 says is legal.  Geronimo lets you 
deploy most application without plans.  David Jencks just committed a 
big change to resource adapter naming so most ears don't need a plan at 
all.  If we followed this logic, we would have to have the following 
plan most of the time:

<?xml>
<plan/>

> 	We could build a workaround for the first -- if no plan is
> specified we load the driver, assume the driver loads the plan or
> creates a default one from deployment information in the archives, save
> the plan to a temp file, and then send the module and plan together as
> required and delete the temp file.

No just pass a null plan to our driver, and it will happily continue 
without one.

> 	For the second one, we'd assume you want to operate on all
> targets.  Then we'd get the list of all TargetModuleIDs for all 
> targets,
> and for each, check if the name you specified is either equal to
> TargetModuleID.toString, or TargetModuleID.getModuleID.

Sure... what ever we are doing today in the maven plugin

> 	So I guess we could support both usages with a sufficiently
> clever tool.

+1

> 	I'm thinking that the current Commons CLI logic for the arguments
> isn't going to work, since there will be different available arguments
> depending on your primary command.  Perhaps we can read the first 
> argument
> and then construct a different CLI chain accordingly.

I don't know.  There is a new version of the CLI package that may 
support this, but if it doesn't, I would just write some code that can 
parse all arguments and have an external method that does the semantic 
verification.

> 	Also, with all the votes for 1 tool, I'm assuming that you're OK
> with the basic Geronimo deployment tool depending on JSR-88.

Yes

-dain


Mime
View raw message