Draft ramblings.

Currently we have two ways to create a node:

• create-node-config
• create-node-ssh

The original idea was that create-node-config would be used for non-ssh scenarios where the user runs "create-node-config mynode" on the DAS and then "create-local-instance --node mynode" on the instance machine, and then not manage the nodes via SSH.

The problem is this distinction is somewhat artificial. If I have SSH set up how we want users to set it up (ie the DAS is running as the SSH user and they are using key file authentication) then a populated "config" node has everything we need to connect to the remote system (hostname, glassfish installdir, nodedir). So to prevent users from using SSH with that node we must do an artificial check. Also having two sets of commands adds complexity if one set would do.

The proposal is to do away with this distinction. A node is a node, and we try to use SSH with all nodes. Bascially all nodes are "ssh nodes". In this proposal the commands look like:

create-node
    [--nodehost remote_host_name]
    [--installdir glassfish_home_path]
    [--nodedir path_to_node_directory_on_nodehost]
    [--sshnodehost ssh_host_name]
    [--sshport port_number_for_ssh_on_nodehost]
    [--sshuser ssh_username ]
    [--sshkeyfile ssh_key_file_path]
    [--sshpassphrase passphrase_alias ]
    [--sshpassword password_alias ]
    [--force={true|false}]
    node_name

update-node
    [--nodehost remote_host_name]
    [--installdir glassfish_home_path]
    [--nodedir path_to_node_directory_on_nodehost]
    [--sshnodehost ssh_host_name]
    [--sshport port_number_for_ssh_on_nodehost]
    [--sshuser ssh_username ]
    [--sshkeyfile ssh_key_file_path]
    [--sshpassphrase passphrase_alias ]
    [--sshpassword password_alias ]
    [--force={true|false}]
    node_name

delete-node node_name

list-nodes [--verbose] target

So what are the drawbacks of this? The general drawback is that we loose the ability for the user to clearly state their intention. We assume they want to use SSH instead of knowing for sure. Trouble areas:

Validation

create-node-ssh currently validates all parameters because we know the user plans on using SSH. If a user runs "create-node-ssh --nodehost foobar.com mynode" we do SSH validations – if the user does "create-node-config --nodehost foobar.com mynode" we do not. What do we do for "create-node --nodehost foobar.com mynode".

Proposal

We assume the user will be using SSH nodes and we generally do validation. Whether things are warnings or errors depend on the option. Examples:

create-node mynode
Validate nothing

create-node --nodehost foobar.com mynode
Validate foobar.com is a valid host (Error). 
Validate it can be contacted via SSH (Warning).

create-node --nodehost foobar.com --installdir /export/gf mynode
Validate foobar.com is a valid host (Error). 
Validate it can be contacted via SSH (Warning).
If can connect validate that /export/gf exists (Error).

create-node --nodehost foobar.com --installdir /export/gf --sshkeyfile /foo/bar mynode
Also validate keyfile exists, isreadable, etc (Error).

Basically if an option is provided and we can validate it then we do. If the option is bad then it's an Error. If we can't contact the host via SSH it's a warning.

Handling errors clearly for start-instance, create-instance, delete-instance

Today (in theory – it's not implemented well) if somebody does start-instance on an instance associated with a config node we can tell them that start-instance needs an SSH node. With one node type we don't know for sure if we should try SSH on a node or not.

Proposal

Try to use SSH and be clear if it doesn't work.

• If the node has no nodehost then create-instance should fail.
• If we can't contact the remote instance using SSH then we give an error stating so

Future support for nodagents

In the future we may add support for nodeagents. Now we can't assume every node is an SSH node.

Proposal

We add nodeagent specific versions if that makes sense (create-node-agent).