The 2.1 goals on the page you referenced were a bit vague. It was created when
the ASF VCL community was just beginning and hadn't yet fully adopted Jira and
its roadmap features. As a result, that page is outdated and its intent has
been replaced by the Jira issues tagged for 2.1:
https://issues.apache.org/jira/browse/VCL?report=com.atlassian.jira.plugin.system.project:roadmap-panel
There is still some OS code scattered in the various modules, mostly Linux code.
For 2.1, the main goal was to create the OS modularization architecture. The
Windows code modularization is complete (except for a tiny bit of cleanup to
do). The Linux code is probably 75% complete. I think completing Linux
modularization should be a 2.2 goal.
Regarding SSH keys for each OS... I think you are referring to the IDENTITY_*
properties in the vcld.conf file which wind up as global variables created in
utils.pm (ex: $IDENTITY_wxp). These global variables are being phased out and I
would like them to be completely removed for 2.2. $IDENTITY_wxp isn't used at
all in any of the Windows modules.
Identity key paths are now stored in the database as managementnode.keys. This
value can be a comma-separated list of paths. When utils.pm::run_ssh_command()
is called, it gets passed an identity keys argument which may be a single path
or a list. It assembles the SSH call with multiple "-i <path>" arguments as
necessary.
I really like your idea about an alternate Windows module that doesn't use SSH.
This wouldn't be too difficult to implement if all the SSH calls in the
Windows modules are routed through a single Windows.pm::run_command() subroutine
instead of calling utils.pm::run_ssh_command(). Windows.pm::run_command() would
call run_ssh_command(). I had actually thought about doing this to reduce
duplicated code. Many of the Windows subroutines perform the same steps:
-get the computer name: $self->data->get_computer_node_name()
-get the identity keys: $self->data->get_management_node_keys()
-call utils.pm::run_ssh_command()
-check the exit status and output
Windows.pm::run_command() would make the alternate Windows module easy to
implement. All you would have to do is implement a run_command() subroutine in
the alternate module, inheriting from Windows.pm.
I wouldn't move all of the SSH code into the individual OS modules because
run_ssh_command() is a little nasty and should be shared. It would, however, be
beneficial to move run_ssh_command() to OS.pm. This would allow it to use
$self->data rather than passing it the same arguments over and over again such
as the computer name and keys. It could also be overridden in inheriting
modules if necessary.
-Andy
Sean Dilda wrote:
I noticed on
http://cwiki.apache.org/confluence/display/VCL/VCL+2.1+goals that one of
the goals is 'Modularize OS code'. Is there a timeline for when (or
what revision) that goal is to be met by?
The way the OS code is modularized out today has greatly improved from
when I first started looking at the VCL code. However, I did a quick
search for 'linux' and found the following subroutines with
linux-specific code (I may have missed a few):
utils.pm:
setstaticaddress()
getdynamicaddress()
check_connect()
isconnected()
add_user()
del_user()
inuse.pm:
_notify_user_disconnect()
new.pm:
reserve_computer()
reclaim.pm:
process()
reserved.pm:
process()
As well as some code in the provisioning modules.
In addition, I think moving away from having a predefined windows,
blade, lab, etc identity key and instead have determining which key to
use being part of the OS module go go a long ways towards this
modularization. Or better yet, move all the ssh calls into OS-specific
modules so that someone can add support for an OS that doesn't require
ssh (ie an alternate windows module).
