some basic info about create-local-instance vs create-instance.
create-instance creates an instance on a machine that is described by
the node that is associated with it. The instance will be local to the
machine if the node is localhost or a remote node if it is an ssh node.
If create-local-host is used then the instance (the directories) are
always created on that machine.
It may be that the user doesn't want to use SSH and that is the scenario
where he is using create-local-instance. The way the SSH design docs
and the scenarios have been written the user can use SSH (and there fore
use create-instance on either the DAS machine or the instance machine).
If the user doesn't want to use SSH then the users calls
create-local-instance on the instance machine.
The node element is either an SSH or a CONFIG node. If the node is
created using create-node-ssh then it is automatically marked as an SSH
node. Well that is the change I'm working on now. If the node element
is created using create-node-config then the node is not setup to use
SSH and the instance must be started on the machine where it was created.
Bill Shannon wrote:
> Carla Mott wrote on 08/04/2010 05:22 PM:
>> Hi,
>>
>> I created an instance using create-local-instance and found
>> unexpected behavior. In the case where create-local-instance is
>> running on a machine other than the DAS, create-local-instance should
>> implicitly create a node whose name is the name of the host the
>> command is running on. So if the command is running on host bar then
>> the node element on the DAS machine should have the name bar and the
>> node-host should also be bar.
>> The wrong behavior happens if I have created a node say node1 which
>> points to bar. This means that on machine bar there is a nodeagents
>> dir with a directory node1. create-local-instance will use the node
>> 'node1' when it creates instances instead of creating a new node
>> called bar and a corresponding directory bar under nodeagents. This
>> is wrong.
>
> Why?
because depending on which command you run first you get different
results. create-local-instance should always point to a node that
describes a non SSH connection. the user can run a command to update
the node but that is a specific action that he needs to take.
>
> In general, if one of the thing you need already exists, we just use it.
> Why shouldn't it default to using the existing node1 node?
because if he doesn't want to use SSH he is forced to and there is no
way around it.
>
>> create-local-instance seems to look for a node and use that if
>> available otherwise it creates a node using the host name.
>
> That's what I would expect.
>
>> Now if I reverse the sequence of the commands I can create a node
>> with host name using create-local-instance if there are no nodes
>> already created. I can also create a node using create-node-ssh and
>> then the instance using create-instance using that node and all looks
>> right on the remote host.
>
> A single domain should probably be limited to a single node on a given
> host (name? IP address?). The reason to have multiple nodes on a
> machine is to support instances from multiple domains on that machine.
I need to understand this better but it seems that the commands the user
can use is not related to the number of domains on the machine. If
there are instances on a machine that can be started using SSH does that
mean there can not be instances that can be started locally?
>
>> With 3.1 users have the option to run commands on remote machines
>> using SSH. It is not required however. When a user creates an
>> instance using create-local-instance it should be assumed that he
>> does *not* want to use SSH. Under the current scenario if only one
>> node exists on a host create-local-instance will default to using
>> that node regardless of how the node was created or if it specifies
>> that SSH should be used. Once there are 2 nodes
>> create-local-instance will prompt the user to specify the node he
>> wants to use.
>
> That's what I would expect. Why is that confusing?
the multi node case is not confusing.
>
>> I'm not sure why the current implementation looks for a node and uses
>> that if found. It should look for a node that is the same name as
>> the host it is running on and if exists use that (underlying code
>> will verify that the node is correct). If a node by that name is not
>> found it should create it.
>
> For a domain, there should be only one node on a given machine. If that
> node has already been created and given a name the administrator likes,
> why create a different node with a different name?
we use node to determine how to connect to the machine. I guess that
the question is are the scenarios described on this page correct? Is
scenario 5 a valid use case?
http://wiki.glassfish.java.net/Wiki.jsp?page=3.1SSHScenarios
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>