Andy Kurth wrote:
Hi Sean,
Welcome! As Aaron mentioned, here is the provisioning module specification:
http://cwiki.apache.org/confluence/display/VCL/Provisioning+Engine+Module+Interface+Specification
If you haven't done so already, browse the pages under the following URL to
familiarize yourself with the backend modularization and inheritance architecture:
http://cwiki.apache.org/confluence/display/VCL/Backend
Thanks those are really useful.
(Note: the purple text on these pages are just notes of additional things which
should be documented)
These pages along with going through existing modules are probably your best
bet. The xCAT.pm and vmware.pm modules are the most current. I would work off
of them.
The VCL ASF community really hasn't discussed coding guidelines so this would be
a good exercise as this is developed.
We (NCSU) mainly use VMware Server 1.x at the current time. I'm hoping to work
with the community to rework the vmware.pm module to use the VMware Perl API,
possibly for a 2.2 release. This is necessary in order for us to be able to use
VMware Server 2.x, which I believe is going to be necessary to support Windows 7
VMware environments.
Ideally, vmware.pm would contain all of the general functions common to the
different VMware products. esx.pm module would inherit from vmware.pm and would
implement functions specific to ESX. Some work needs to be done to get these
aligned. Your module would then inherit from esx.pm and would only need to
implement the special linked cloning functions.
That said, you don't have to wait for other modules to be updated you don't
really have to deal with VMware/ESX inheritance in order to get started. All
the functions you need could be implemented in your .pm file for now. As you
identify or write subroutines which could be used across the VMware product
lines, bring them up on the list and we can decide where in the hierarchy they
should go.
I like the idea of using the inheritance. I'm hoping some of the
code/ideas from my new module will be able to be pushed up the
inheritance tree to the other modules. In particular, some of the
changes from the current esx.pm module I'm looking to make include:
1. Use API calls instead of provided perl scripts - My experience
writing cacti and nagios checks with the VIPerl Toolkit has shown that
there's a heavy CPU hit for a few seconds while perl processes all of
the VIPerl libraries. Calling those scripts several times in the
loading can cause problems with larger VCL deployements. Rewriting it
to use the API calls should reduce that CPU hit to once per reservation.
2. Base the new vmx on the image's vmx. This allows the image creator
to customize the VM hardware and we will carry those settings along.
3. Remove dependency on ssh/scp to ESX host. This will make it easier
to setup for ESXi, as well as allowing deployments to use vCenter and
deploy to a cluster instead of to an individual host.
I also looked through the vmware.pm and had a question that I'm hoping
someone can answer. In the load() subroutine, the module checks through
/var/log/messages for dhcpd responses before checking on ssh. What is
gained by doing this? It seems this could be cleaned up by just
checking with pings and ssh attempts. This would simply the code, as
well as removing the dependency of running dhcpd on your management
node. We're planning on using our campus DHCP servers for our VCL
environment, so avoiding that dependency would be a big plus for us.
Thanks,
Sean
