Hello Carla,
Thank you very much for the detail response.
In general, I think that a conception of SSH nodes, CONFIG nodes and
third type of nodes, localhost node, that neither CONFIG no SSH,
could be very confusion for the customers.
Thank you,
Elena
Carla Mott wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>