On Wed, Feb 1, 2012 at 10:54 AM, Aaron Coburn <acob...@amherst.edu> wrote:
> 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
> 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.
Is there something in the Windows.pm module or are you referring to
the package structure in general? I did find /usr/local/vcl being
hard-coded in the S99vcld.linux file. This should probably be
> 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.
I thought about adding the VCL backend code to CPAN long ago before it
was donated to the ASF. I don't know if this would be possible or
I'm very used to developing and running vcld and the Perl modules from
a single directory but I can see how using standard locations may make
it more straightforward -- especially for Linux pros. Either way, I
think an installation mechanism should allow the person installing it
to override default locations and also provide additional information.
I think a model similar to VMware's standard method of installing
things under Linux would work best:
-untar the installation files (doesn't matter where)
-answer questions (or press enter to accept defaults)
-when the script is done, vcld is up and running
> 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
I like the idea of anything that makes installation easier (and
managing the installation scripts). I'll give your Makefile.PL a try.
> 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
> 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
>> -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.
>> 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.
>>> 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
>>> 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.
>>> Aaron Coburn
>>> Systems Administrator and Programmer
>>> Academic Technology Services, Amherst College
>>> (413) 542-5451 acob...@amherst.edu