The more I think about this the more I think that maybe we SHOULD have a
node-agent. E.g. when we call ssh -- where is the GF installation located?
Will it really save time and money to not have a node agent?
How will authentication/authorization work with ssh?
We could create a nodeagent that just runs as an asadmin command.
Something to think about now -- thinking is cheap!
On 3/12/2010 11:05 AM, Bill Shannon wrote:
> I've been discussing this with Nazrul, but I'd like to get input from
> more people...
>
> If you look at what create-instance does in v2, there are two parts:
>
> 1. Create the entries in domain.xml to represent the new instance.
> 2. Create the entries in the filesystem on the instance node
> for the new instance.
>
> In v2, the asadmin command "create-instance" asks the DAS
> to do #1. The DAS then asks the node agent to do #2. In
> the v3 design of asadmin, this command would be a completely
> remote command, with no special local knowledge.
>
> What we need in v3, until we have a node agent, is a local
> asadmin command that runs on the node that will host the
> new instance. This command needs to ask the DAS to do
> #1, then do #2 locally.
>
> This is subtly different from what the existing "create-instance"
> command does. I'm torn as to whether this should be an
> option to the create-instance command, or a new command.
>
>
> If we support ssh as a replacement for the node agent, it
> would be good to have an asadmin command that just
> does #2. The DAS implementation of create-instance could
> do #1, then use ssh to run a command that does #2 on the
> remote node. create-instance-filesystem seems like a good
> name for that command.
>
> One way to think of this is that we need a couple of primitive
> commands to do #1 and #2, and then we need some "macro commands"
> or "scripts" that combine them for the two different use cases.
>
> The primitives could be "_" commands - _create-instance
> and _create-instance-filesystem, for instance. This will
> cause them to not show up in asadmin list-commands.
>
> Here's one way to do it...
>
> "create-instance" is an asadmin remote command.
> On the server (DAS) the create-instance command
> calls the _create-instance command, then (if possible)
> executes the _create-instance-filesystem command on
> the remote node.
>
> "_create-instance-filesystem" is an asadmin local command
> that does #2 above, and nothing else.
>
> "create-local-instance" is an asadmin local command that
> executes the remote command _create-instance, then
> executes the other local command _create-instance-filesystem.
>
>
> Here's another way to do it...
>
> "create-instance" is an asadmin local command. Its behavior
> depends on some option, which I'll call --createfilesystem for
> now, but which needs a better name. If --createfilesystem is
> not specified, the local create-instance command simply
> calls the remote create-instance command.
>
> On the server (DAS) the create-instance command
> calls the _create-instance command, then (if possible)
> executes the _create-instance-filesystem command on
> the remote node. (Just like above.)
>
> If --createfilesystem is specified, the local create-instance
> command executes the remote _create-instance command, then
> executes the other local command _create-instance-filesystem.
>
> "_create-instance-filesystem" is an asadmin local command
> that does #2 above, and nothing else.
>
>
> Either approach works. And the same primitive commands
> are needed on both cases.
>
> The question is, which will users find more natural and understandable?
> A single command with an option to control the different behavior?
> Or two different commands for the different use cases?
>
> Comments? Which would *you* prefer?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
--
Byron Nevins - Sun Microsystems, Inc.
Home: 650-359-1290
Cell: 650-784-4123
Sierra: 209-295-2188