Has there been any thought about the installation procedure of the perl code
for VCL?
The current approach is to manually rename the management node directory to
/usr/local/vcl
Wouldn't it be better to use a standard Makefile.PL for this? This would allow
the modules to avoid the 'use lib "$FindBin::Bin/..."' constructs, because the
modules would be in perl's @INC path. Furthermore, there are a number of places
where the installation directory is hard-coded (VCL::Module::OS::Windows) --
that could all be pushed to a configuration file, written by the Makefile.PL
script.
It would also allow the vcld script to be installed in a more standard location
(e.g. /usr/local/bin)
Plus, this would make the code consistent with other CPAN modules. If there was
interest (some time in the future) to make these libraries available on CPAN,
these changes would all be necessary.
Furthermore, this would make it much easier to build and run a test suite for
the perl code -- ExtUtils already has a structure for supporting this. I have
attached a sample Makefile.PL
use warnings;
use strict;
use ExtUtils::MakeMaker;
my @prog = qw/vcld gen-node-key.sh/;
WriteMakefile(
NAME => 'VCL',
ABSTRACT => 'Virtual Computing Lab',
LICENSE => 'Apache',
EXE_FILES => [ map "bin/$_", @prog ],
VERSION_FROM => 'lib/VCL/utils.pm',
PREREQ_PM => { 'Digest::SHA1' => 0,
'DBI' => 0,
'File::Temp' => 0,
'Getopt::Long' => 0,
'HTTP::Headers' => 0,
'IO::File' => 0,
'List::Util' => 0,
'Mail::Mailer' => 0,
'Net::Ping' => 0,
'Object::InsideOut' => 0,
'RPC::XML::Client' => 0,
'Shell' => 0,
'Storable' => 0,
'Text::Wrap' => 0,
'Time::Local' => 0,
'YAML' => 0 },
MIN_PERL_VERSION => 5.008000,
META_MERGE => {
recommends => { 'VMware' => 0 },
resources => {
repository => 'https://svn.apache.org/repos/asf/incubator/vcl',
MailingList => 'mailto:vcl-dev@incubator.apache.org'
}
},
AUTHOR => 'Virtual Computing Lab',
clean => { FILES => join(" ", map "bin/$_", grep /^[A-Z\.]+$/, @prog) }
);
This is just a stub, but with a little more work, it could be used to configure
/etc/vcl/vcld.conf and run the various tests that have been listed below.
Aaron
--
Aaron Coburn
Systems Administrator and Programmer
Academic Technology Services, Amherst College
(413) 542-5451 acob...@amherst.edu
On Jan 13, 2012, at 11:41 AM, Andy Kurth wrote:
> I like the idea. Other tests which would be useful:
>
> -check VM host license expiration dates
> -check if the network names defined in the VM profile are available on
> the VM hosts
> -check amount of space available for VM host datastores, management
> node repository, and management node volume where vcld.log is being
> written
> -make sure required attributes are defined for VMs such as MAC
> addresses if they are not auto-generated
> -check if time is sychronized on VM hosts, management node, and the
> database server
> -send a test sysadmin email message
>
> The architecture of 'vcld -setup' hasn't been discussed on this list
> so now is a good time to begin. The idea is for vcld to handle all of
> the details so that any module just needs to implement a subroutine
> named 'setup' and it automatically gets added to the menu. This
> allows any module to contain options specific to itself but results in
> a somewhat clunky menu system.
>
> It would be good to have a single menu option where all of the tests
> appear yet still allow each module to implement it's own test code.
> In order to do this, the setup_management_node sub in vcld will need
> to be extended. I had thought about adding something like this in the
> past but never completed it. I was thinking of adding code to vcld to
> look for modules which implement a 'setup_check' subroutine (the same
> way it looks for 'setup') and then put all of these under a single
> menu option.
>
> There are a few bits and pieces to look at in the current code. There
> is a setup_check subroutine in Windows.pm. It simply gets called by
> Windows.pm::setup every time it is run. It only checks if product
> keys have been configured. The Module.pm::setup_test_rpc_xml
> subroutine would be another one that would be part of this.
>
> -Andy
>
>
> On Thu, Jan 12, 2012 at 9:45 AM, Aaron Coburn <acob...@amherst.edu> wrote:
>> Hi, Guys,
>>
>> The web front-end to the VCL has a "testsetup.php" script that tests a
>> variety of server settings so that the web code is easier to install.
>>
>> I am wondering if there might be interest in building a similar facility
>> into the vcld -setup script. It seems that many of the questions posed on
>> this (and the users') list relate to misconfigured networks and/or
>> provisioning module components. Clearly, the vcld logfile captures all of
>> this, but even that is often turned over to the list for interpretation.
>> This could be a sort of 'dry run' image capture.
>>
>> So here is a stab at what might be useful for such a script to check. My
>> list will be biased heavily in favor of the VMware provisioning modules,
>> because that's what we use in our installation. And I am assuming that the
>> output would be something easy to understand.
>>
>> Network:
>> 1. can vcld get an IP address from a vmhost 'short name'
>> 2. can vcld get an IP address from a given computer 'short name'
>> 3. can vcld reach to the running VM(s)
>> 4. can vcld reach to the VM host
>> 5. can vcld transfer a file to/from the vm host
>> 6. if the image library is enabled, is that accessible
>>
>> Computer:
>> 1. is cygwin installed and sshd running (for Windows)
>> 2. can vcld login successfully
>> 3. does the computer have network access
>> 4. do the computer's MAC addresses match what is expected in the database
>>
>> VM Host:
>> 1. can vcld login to the vm host
>> 2. are the paths listed in vmprofile available in the vmhost infrastructure
>> 3. are certain utilities and/or commands available to vcld from inside the
>> vmhost (i.e. copy virtual disk, create a vm, etc.)
>>
>> etc, etc.
>>
>> Thoughts?
>>
>>
>> Aaron
>>
>>
>>
>>
>> --
>> Aaron Coburn
>> Systems Administrator and Programmer
>> Academic Technology Services, Amherst College
>> (413) 542-5451 acob...@amherst.edu
>>
>>
>>
>>
>>
