Carla Mott wrote on 08/04/2010 10:50 PM:
> 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.
I don't believe that was our intent.
I should be able to create an ssh node while the remote instance is down,
then bring up the remote instance and use create-local-instance to
rendezvous with the DAS and associate myself with the node that was
previously configured.
>> 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.
I'm not sure what this has to do with ssh.
Implicitly creating the node in create-local-instance is just a convenience.
You should be able to create the node manually before running
create-local-instance, and you should be able to name it whatever you want.
Whether that node is an ssh node or not should be a separate decision.
>>> 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.
Thinking about this some more, I guess there's no reason to limit this,
but having more than one node for a domain on an instance isn't likely
to be a common case, and in my opinion is more likely to be a mistake.
> 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?
You can always start an instance locally.
But if you want instances on a machine that can be started using ssh,
and other instances on the same machine from the same domain that
*are not allowed to be* started using ssh, that doesn't seem like an
important use case, but I suppose it should be allowed by having two
nodes for instances on that machine.
>>> 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
Rather than "should be", I would say "only needs to be", at least for
the common cases.
>> 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
Yes, I believe scenario 5 is valid. It simply allows you to give the node
a name you like, instead of defaulting to the host name. In this case, you
haven't configured ssh for that node.