...

• The yellow modules represent the core VCL modules
• The blue and green modules represent auxiliary modules
• Core modules that should not need to be changed regardless of the auxiliary modules being used
• The core modules provide many functions to the auxiliary modules including:
  • default constructors
  • data access
  • module initialization
  • access to other auxiliary modules where appropriate

Explain:

• abstract and concrete classes - abstract are not instantiated
• classes can be empty, contain no subs, but act as a placeholder in case it's decided later on that a sub would be useful 

Advantages

• Modules make it easier for developers to implement new technologies to be used with VCL easily
• Core VCL code does not need to be altered in order to support additional technologies or functionality
• Increased flexibility for different configurations
• Consistent methods to access data stored in the database
• Code maintainability is increased because each module focuses on a distinct task and the core code does not need to check for numerous different conditions based on the technology being used

Explain: 

• more about benefits of inheritance
• give OS example and include diagram
  • Windows - Desktop - XP - Vista
  • implement subs as high up as possible so child classes inherit them
  • child classes can override an inherited sub if it doesn't fit its needs
  • use example of firewalls in Windows.  Windows.pm implements a firewall sub which works for everything but Vista.  Vista.pm can implement a sub with the same name and it will override the one in Windows.pm, yet Vista.pm still enjoys everthing else Windows.pm offers.

Core Modules

  Explain:

• only core modules should ever change the request state/laststate/computer state
• only core modules should change anything in the request and rsvp tables
• provide state flow
• provide data access
• provide utility functions 
• database and data structure are abstracted from auxiliary modules
• ongoing - should not contain code specific to something that can be modularized such as "if windows... else linux..."

vcld (VCL::vcld)

Explain:

• main exe
• loops every 12 seconds by default
• doesn't inherit
• creates DataStructure object
• forks
• sets some $ENV variables
• reaps dead processes

DataStructure.pm (VCL::DataStructure)

Explain:

• abstracts database and data structure
• aux modules shouldn't know about the DB or data structure
• should be able to change db or data structure and still have aux modules work
• uses "Inside Out" technique to accessing modules can't get to the underlying data
• data is encapsulated, can only be accessed using accessor functions
  • encapsulation is good, explain what it is
• usage: $self->data->get_image_name()
• need to list methods somewhere (not here), there are tons of them
• gets created by vcld when it finds a reservation
• passed to module constructor
• Module.pm sets up access via data()
• Result: any class that inherits from VCL::Module gets access

utils.pm (VCL::utils)

Explain:

• contains several utility subs
• doesn't inherit from Module.pm (might be a good idea to look into this)
• contains some legacy stuff - some subs will be removed and moved to OS or provisioing modules
• should probably make a page describing utility subs such as notify, run_ssh_command...
  • This should really get sucked out of POD comments in the actual code
• have to 'use VCL::utils' in order to use it

Module.pm (VCL::Module)

• Provides a constructor for all derived objects to use
  • Objects which inherit from VCL::Module do not need to implement their own new() subroutines
  • Objects which inherit from VCL::Module do not need to deal with "blessing" themselves
• Provides access to the database data for the reservation via the data() subroutine implemented by Module.pm
  • Wiki MarkupAny module derived from VCL::Module can call $self->data->\[get_something\] or $self->data->\[set_something\]

State.pm (VCL::Module::State)

• Supports the core VCL state modules such as new.pm, image.pm, reclaim.pm, and others
• Provides an initialize() subroutine which performs common tasks whenever a state object is created
  • initialize() creates the provisioning and OS objects
• Wiki MarkupProvides an os() subroutine which allows the state objects to interact with the resource's operating system by calling $self->os->\[subroutine\] Wiki Markup
• Provides a provisioner() subroutine which allows the state objects to interact with the provisioning engine that has been configured for the resource by calling the resource by calling $self->provisioner->\[subroutine\]
• Provides other subroutines such as reservation_failed() which performs a consistent set of tasks when a reservation fails

...

Implementation Details

Working with Inheritance

Explain:

• code to set up inheritance
• using $self->
• when to use $self-> (object method) and when to call a sub directly (class method)
• how to check if sub was called as an object method or not

Including Non-Inherited Modules

 Explain:

• use file::bin to include the lib directory
• use warnings, strict, diagnostics are a good practice
• use 'VCL::utils' is the only VCL module you should need to include, all else should be handled by inheritance/objects

Module Initialization

Explain how modules can implement initialize() subs which are automatically called

Database Configuration for Modules

Explain module table, computer.moduleid, managementnode.predictivemoduleid

Cross-Module Access

Explain why some modules shouldn't have access to others, which is why Module.pm doesn't make os() and provisioner() available

Required & Optional Module Subroutines

Explain:

• Perl's can() function
• core modules use can() to check if module implements a subroutine
• some subs should be required such as OS::load(), most should not
• if you can think of an exception why a sub wouldn't be needed it shouldn't be required

Package Organization

Explain:

• how directories under lib/VCL should be organized
• the 'package' line in the modules should match the location of the file
  • Example: "package VCL::Module::OS::Windows" resides in "lib/VCL/Module/OS/Windows.pm"
• some core modules don't follow this - the state modules reside directly under lib/VCL, should eventually reside under lib/VCL/Module/State