Andy Kurth wrote:
Hi Sean,
Welcome!  As Aaron mentioned, here is the provisioning module 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:

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 and 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 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, would contain all of the general functions common to the different VMware products. module would inherit from and would implement functions specific to ESX. Some work needs to be done to get these aligned. Your module would then inherit from 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 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 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.



Reply via email to