I think part of the confusion stems from the fact that some commands
have been only partially implemented. Once I put in my latest changes
things should work as specified.
I still have a question about the number of nodes that can/should be
created. Hopefully we can tackle that when Joe gets back next week.
See below for more info.
Bill Shannon wrote:
> Elena Asarina wrote on 08/05/2010 10:17 AM:
>> Hello Bill,
>>
>> Thank you very much for the reply. Regarding your comments:
>> "Why wouldn't create-instance be usable to create additional instances
>> on that node?"
>> "Right, that shouldn't be the case. If that's the way it works now,
>> seems like something is wrong. "
>>
>> It doesn't work such way now, but according to Joe it will work such
>> way at the future. Joe wrote in the bug
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=12846
>>
>> "The scenario you described is not supported (using an
>> auto-created-node that was
>> created via create-local-instance with create-instance over SSH). We
>> have a bug
>> (issue 12694) for better detecting this condition. Once that is fixed
>> it will
>> always fail with a better error message.
>> For now please use only nodes created with create-node-ssh (or the
>> localhost
>> node) with create-instance."
>
> I'm not sure I'm following...
>
> If I use create-local-instance to create an instance, and it creates
> the default local node using the host name, that node won't be configured
> for ssh. If you then use create-instance to create another instance on
> that same node, it should update the domain.xml with the instance, but
> it won't be able to use ssh to create the instance on the remote machine
> so you'll need to go to the remote machine and execute
> create-local-instance
> again to complete the creation. I hope that's what Joe's saying above.
That is what Joe is saying. create-local-instance will create a node
(and the confusing thing may be that the node element is created
remotely if the DAS is a different machine) which does not have the SSH
information. And it should not. That instance is local to the instance
machine even if it's config information is on another machine. We don't
access the config information via SSH. The user can create numerous
instances using create-local-instance and they all have the same node
reference. That node element will be on the DAS machine which may be a
different machine than the instance machine. What is local is the
instance directory and not necessarily the node config information.
The bug that is there now is that if you have SSH setup and all the
defaults work then the start-instance command will start an instance
that was created by create-local-instance. The fix I'm working on now
will prevent that from happening. That means that each node will be
marked as either SSH or CONFIG and the commands will check that to
determine how they will operate.
>
> If you want to use create-local-instance followed by create-instance for
> the same node, you should use create-node-ssh first to configure the ssh
> information and specify that node with create-local-instance. Or of
> course
> at that point you could've just used create-instance.
that is correct. We also have the command update-node-ssh which will
convert a non-SSH node to an SSH node. That way the user is explicitly
saying the node is an SSH node.
>
>> Also I forgot to mention that localhost node can not be deleted, i.e.
>> we have one more difference.
>
> That's more of a safety feature, to prevent you form getting into trouble
> later. I suppose we could make any command that needs it put it back
> later
> if it's missing.
Since we required all instances to have a node element we added a
'localhost' element for the developer case where all instances are
running on the local machine. We thought it would be easier than
telling developer they have to create a node element pointing to the
local machine in order to do their testing. It is simply for
convenience. We don't expect this to be used in production but rather
by developers.
>
>> Personally, I would prefer that all nodes will be equal,
>> independently how they were created, like it was in v2. for nodeagent.
>
> Define "equal".
>
> They're not all equal because some will be configured for ssh and some
> won't.
>
> In v2 you could create a node without providing all the node agent
> configuration information, but that information would be added later
> when the node agent was created.
In v3 that is why we have create-node-config. It is a place holder that
will be filled in later. In our case it is filled in by
create-local-instance which does not require SSH. Note that the
commands that have the word 'local' in them still may access another
(remote) machine to update the config. They don't use SSH in doing so.
In fact, none of the remote commands use SSH to talk to other machines
to update the config information.
>
>> And the last, I don't understand why to the names of some remote
>> commands was add "ssh" and for other not, they all use ssh.
>
> The issue isn't whether the commands *use* ssh, it's whether they're
> manipulating the ssh configuration information.
>
> You might imagine that in the future we would bring node agents back,
> so in addition to create-node-ssh we would have create-node-agent,
> which would configure a different way to execute commands on the remote
> machine. We could even have create-node-rsh and create-node-telnet if
> we wanted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>